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

"Susan Hares" <shares@ndzh.com> Thu, 21 February 2013 15:43 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F1E21F8E69 for <gen-art@ietfa.amsl.com>; Thu, 21 Feb 2013 07:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.947
X-Spam-Level:
X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bwk5yWbKxVa for <gen-art@ietfa.amsl.com>; Thu, 21 Feb 2013 07:43:50 -0800 (PST)
Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4D44B21F8703 for <gen-art@ietf.org>; Thu, 21 Feb 2013 07:43:50 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202;
From: Susan Hares <shares@ndzh.com>
To: "'Jon Mitchell (GNS)'" <Jon.Mitchell@microsoft.com>, 'Elwyn Davies' <elwynd@dial.pipex.com>
References: <511DFCAD.6020509@dial.pipex.com> <f1195a2f3468441d85edaf0b8b843bba@DFM-DB3MBX15-08.exchange.corp.microsoft.com> <1361236326.4494.891.camel@mightyatom> <4f5ed402038544d0b1da25226424e60b@DFM-DB3MBX15-08.exchange.corp.microsoft.com>
In-Reply-To: <4f5ed402038544d0b1da25226424e60b@DFM-DB3MBX15-08.exchange.corp.microsoft.com>
Date: Thu, 21 Feb 2013 10:43:33 -0500
Message-ID: <00e401ce104a$3512ec60$9f38c520$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJn+X55OJNmPAsTdqI4/oT78g4/vQHs9lBBAjjRiW4Cb1V6p5cb9tBA
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Cc: draft-ietf-idr-as-private-reservation.all@tools.ietf.org, 'General Area Review Team' <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-art last call review of draft-ietf-idr-as-private-reservation-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2013 15:43:51 -0000

Jon and Elwyn:

These drafts are working toward a larger goal - the eventual update of the
RFC 4271 with current practices.   Getting consensus on these items except
in very small pieces have been extremely difficult. 

Eventually, these will be all rolled up into larger documents that refer to
these smaller documents. 

The reason behind this is tactical. The smaller drafts allow people to stop
doing bad things to BGP immediately.  We have new implementation coming due
to the explosion in the Data center market.  Therefore, vague pieces in
RFC4271 must be plugged now. 

It seems that I really should get around to writing up the process on the
IDR web page and an internet draft. 

Thanks for your hard work, 

Sue 

-----Original Message-----
From: Jon Mitchell (GNS) [mailto:Jon.Mitchell@microsoft.com] 
Sent: Tuesday, February 19, 2013 3:27 PM
To: Elwyn Davies
Cc: General Area Review Team;
draft-ietf-idr-as-private-reservation.all@tools.ietf.org
Subject: RE: Gen-art last call review of
draft-ietf-idr-as-private-reservation-03


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:elwynd@dial.pipex.com]
Sent: Monday, February 18, 2013 8:12 PM
To: Jon Mitchell (GNS)
Cc: General Area Review Team;
draft-ietf-idr-as-private-reservation.all@tools.ietf.org
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:elwynd@dial.pipex.com]
> Sent: Friday, February 15, 2013 4:15 AM
> To: General Area Review Team
> Cc: draft-ietf-idr-as-private-reservation.all@tools.ietf.org
> 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? :-) )
> 
>