This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] Re: 2010-06 is going to Last Call
- Previous message (by thread): [ipv6-wg] Re: 2010-06 is going to Last Call
- Next message (by thread): [ipv6-wg] Re: 2010-06 is going to Last Call
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marco Hogewoning
marcoh at marcoh.net
Wed Jan 26 11:33:01 CET 2011
Responding in my role as one of the proposers and authors of this document. Please see my comments inline: On Jan 26, 2011, at 10:17 AM, Gunter Van de Velde (gvandeve) wrote: > Some feedback: > > <> > As an example, one would create <provider-tla>::/36 with an assignment > size of /56. A simple MRTG graph over time showing the actual number of > assignments or customers can then be generated from the OSS/BSS system > or maybe even directly from the DHCPv6 servers involved. This would then > satisfy the need to verify the addresses are used efficiently enough and > the LIR meets the HD ratio required. It does so in a way to which most > LIRs are already familiar and without the need to disclose to any > specific information on individual End Users or the resource they hold. > <> > > GV> Not sure why this is here in the intro... it's a valid and usefull > anticipation, but I would place it somewhere else in the document as a > motivation example. Forgive me for asking, are you commenting on the policy proposal itself or on one of the draft documents which will be the result of this ? > <>start<> > 1.0 Motivation > ... > keep records of IPv6 address assignments > ... > <>end<> > > GV> What about using 'IPv6 subnet address assignments'? > (I don't care about individual addresses in v6, but care about subnet > addresses being used and the HD is calculated on that variable, not?) I think the rest of the policy also simply talks about address assignments and allocations and not 'subnet assignments' > <>start<> > 4.0 Functionality > ... > object may contain > ... > <>end<> > > GV>Is there a reason why it's a 'may' instead of a 'should' or 'must'? Long story. The original text had a must there, it has something todo in the way the text of the document is converted into technical requirements for the RIPE NCC database group. The formal rule is that the attribute is optional so it has to be a may as you describe it. The 'must' will be the result of a business rule at another level. This came up during the impact analysis done by the NCC so Remco and I agreed in changing it. > <>start<> > 5.5 Registration > ... > End Site assignments > ... > <>end<> > > GV> What is an End-site assignment? If it's a SP doing this then I > assume it is enterprise > customer, however if it's an enterprise getting PI space, then what is > end-site assignment? > Maybe a loaded/naive question, but why not suggest anything larger then > a /xx should be placed in the database? PI is not relevant here as you are not allowed to make any sub assignments within a PI assignment. The definition of an end site is given elsewhere in the document (sec 2.9, current RIPE-481) and this will not be changed. Grtx, MarcoH (proposer)
- Previous message (by thread): [ipv6-wg] Re: 2010-06 is going to Last Call
- Next message (by thread): [ipv6-wg] Re: 2010-06 is going to Last Call
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]