Elwyn and Jon: This is an IETF consensus about the draft range. As such, it should be put in the draft as Jon indicated. As a shepherd and a co-chair, my comment to the IANA team is that perhaps they should consider handling out a portion of the whole space.
Once it is out, no one ever says "less" but someone always says "more". I will try to respond to the IANA or have a conversation about this draft with them if possible. I will note this in my status to Stewart Bryant (AD) today. Sue -----Original Message----- From: Elwyn Davies [mailto:[email protected]] Sent: Monday, February 18, 2013 8:12 PM To: Jon Mitchell (GNS) Cc: General Area Review Team; [email protected] Subject: RE: Gen-art last call review of draft-ietf-idr-as-private-reservation-03 On Mon, 2013-02-18 at 15:26 +0000, Jon Mitchell (GNS) wrote: > Elwyn - > > Thanks for your review. :-) > The suggestion is being made to IANA who owns the assignment and was > discussed at length in the working group with rough consensus. As specified in the registry, allocations in this registry are either by IETF Concensus (i.e. a suitable RFC such as this draft is intended to be) or request from a RIR. Thus it isn't a matter of suggesting to IANA but telling them what the IETF want done - so this draft should be definitive - and what you said about WG concensus constitutes the values to be used unless somebody else in the IETF manages to alter the concensus which seems unlikely. > IANA will replace the suggested values into TBDX values below that > text if IESG approves. This text will not be in the RFC, it's to be > stricken from the final document by RFC Editor (I was attempting to > write this text in alignment with Section 5.1 of RFC 5226) . Yes, that's fine and as expected. > > On the final ASN in the range, this is in accordance with like > reservation of the existing 2 byte Private ASN reservations, where the > final ASN in that space is not utilized either (except for well-known > community values). Also, a case was made that code implementations > tend to have issues with final number usage if using incorrect > variable types for storage. That said, the small discussion on and > off list about this resolved that if we wanted to formalize the > reservation of the last ASN of both the 2 byte space 65535 and the 4 > byte space 4294967295, probably a separate draft should be constructed > detailing the logic behind these as they have nothing to do with > Private ASN's per se and have already been marked as Reserved by IANA > as you noted. I'm open to IESG direction if we want to take a > different approach on this... Publishing a separate draft seems a bit overkill but clearly that's not my decision. ;-) Regards, Elwyn > > Cheers, > > Jon > > -----Original Message----- > From: Elwyn Davies [mailto:[email protected]] > Sent: Friday, February 15, 2013 4:15 AM > To: General Area Review Team > Cc: [email protected] > Subject: Gen-art last call review of > draft-ietf-idr-as-private-reservation-03 > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments you may receive. > > Document: draft-ietf-idr-as-private-reservation-03.txt > Reviewer: Elwyn Davies > Review Date: 15 February 2013 > IETF LC End Date: 22 February 2013 > IESG Telechat date: (if known) - > > Summary: Ready for the IESG. > > Nits/editorial comments: The draft is not actually definitive about range of values to be allocated - the range in s10 is just a 'suggestion'. Who is actually making the decision about the range? > > Aside: I noted that the highest possible 32 bit number (4294967295 = > 0xFFFFFFFF) is excluded from the proposed range. This is marked as > reserved in the IANA table but AFAICS this reserved item does not have > a specification associated with the reservation. This document would > be an opportunity to explicitly mention that the topmost value is > reserved (for future expansion? :-) ) > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
