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

["Jon Mitchell (GNS)" <[e-mail]>]

Elwyn -

Yes, I agree this is a reasonable change to remove all of the "suggestion" text in the IANA considerations area and will make sure it is in the next draft if one is required, either way all of that text will be removed by IANA, who has also just sent back their review of the actions required.

On your second comment, currently being published as an RFC is a draft reserving as0 in a similar fashion, so I do think it's most appropriate as a second doc.. and I really have trouble tying these reservations to a RFC about Private ASN's.   If no doc is published, the good news is that IANA has already reserved the last number (with no justification).  Again, if IESG or others feel strongly it should be in this draft, I will try to work out some text to justify their reservations...

Thanks!

Jon

-----Original Message-----
From: Elwyn Davies [mailto:[e-mail]] 
Sent: Monday, February 18, 2013 8:12 PM
To: Jon Mitchell (GNS)
Cc: General Area Review Team; [e-mail]
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:[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? :-) )
> 
>