Re: [Gen-art] Gen-art last call review of draft-ietf-idr-as-private-reservation-03

["Susan Hares" <[e-mail]>]

Jon and Elwyn:

I would like to make a correction here. The WG as a body of experts
suggested to the author via the Author to IANA.  Perhaps as a body of
experts, this WG is sufficient to begin this range.  Second, the suggestion
from the chairs is that IANA might want to allocate a portion of this total
range for initial usage. 

Finally, the Private Address space in the IPV4 space and this IPv6 range are
logically connected, but the numbers are not connected.

Please let me know if this challenges any of your review. 

Sue Hares
(Shepherd and co-chair) 

-----Original Message-----
From: Jon Mitchell (GNS) [mailto:[e-mail]] 
Sent: Monday, February 18, 2013 10:26 AM
To: Elwyn Davies; General Area Review Team
Cc: [e-mail]
Subject: RE: Gen-art last call review of
draft-ietf-idr-as-private-reservation-03


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:[e-mail]] 
Sent: Friday, February 15, 2013 4:15 AM
To: General Area Review Team
Cc: [e-mail]
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? :-) )