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. 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) .
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... 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
