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

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

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:[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? :-) )
> 
>