Shepherd writeup
rfc6996-05

1) What type of RFC is being requested: BCP

 Why is this the proper type of RFC? Set IANA registry issue, private AS. 

 Is this type of RFC indicated in the title page header? yes


2) technical summary
 
  
Technical Summary:
   This document describes the reservation of Autonomous System numbers
   (ASNs) that are for Private Use only and MUST NOT be advertised to
   the Internet, known as Private Use ASNs.  This document enlarges the
   total space available for Private Use ASNs by documenting the
   reservation of a second, larger range and updates RFC 1930 by
   replacing Section 10.

 Working Group Summary:
   Working group: WG list had 2 rounds of WG LC - one for approval of
   draft and one for actual range size.  The majority view in the
   WG is that it fixes a clear operational problem in the reasonable
   use of private AS numbers. The minority view is that all AS numbers
   should be registered. It is expected this opeational debate will
   continue during IETF last call. 

   The current limited size of the current private AS range has
   led to the re-use of same AS within an 
   organization (DC, Cloud, Inter-cloud, others) in ways that (as the
   draft says: 
   
   "require the use of a number of implementation specific features that
   manipulate the AS_PATH or remove AS_PATH based loop prevention
   described in Section 9 of [RFC4271]" (per draft).  

   These workarounds have increased the operational complexity
   of the networks and failures since implementations of these
   functions vary and are not defined in existing BGP standards.

Document Quality:
   Are there existing implementations of the protocol? This is a AS
   range check for BCP. The range checks of current protocol in 
   implementations can be turned off and allow.

   Large DC providers (Microsoft (author)) and cloud providers
   have requested to aid ral operational usage. 
   
   This is range BCP. IANA registry need to be informed. 
   Careful review by both WG chairs (one serving as Shepherd). 

Personnel 
   Document shepherd: Susan Hares 
   AD: Stewart Bryant. 

3) Review of the document: 
    Editorial review: line by line word review and revising (Sue hares).
    Technical review: Line by line technical comments by WG & chairs.
    Nits: Nits are clean except for IETF copyright notice.
           Requested author respin with current IETF boiler plate.

4) Depth of review: Exhaustive
5) Portions: 
   IANA Review of registry changes. 
   Security directorate review of Private AS concept

6) Concerns for AD/IESG
    WG chair: This draft addresses operational issues, and 
    chooses to continue private AS assignment. 
              
    It is the BCP for majority of carriers, ISP, and
    vendors is this correct. Some of people proposes 
    SIDR work disagree. The WG chairs and wG have recommended this.
    SIDR/Grow cross posting was done.

    The consensus process has not reached a unanmious vote, 
    but a consensus. The consensus process will continue during
    WG last call.

7) & 8) IPR disclosoures
    Not applicable for registry, but asked anyway.

9) WG Consensus - see #6. This draft clearly represents
   a majority position with opposition in minority position. 
   

10) Threaten an appeal
    WG LC caused Randy Bush to indicate he would continue the
   consensus process during IETF LC. This is a reasonable 
   approach as the consideration of continuation of private 
   AS in AS 4-byte is an IETF concern.,

11) NITs - needs to have 2013 boiler plate. Author will
    spin draft for this.

12) Formal Review - BCP, no MIB, no media, no URI.
13 -15)  
  All Normative are RFC. All informative pass NITs
  and are appropriate. No down level RFCs.

16) No change to state. Will update RFC1930. 

17) IANA considerations
    IANA section has specific comments for review by IANA and then removal.
    These are clearly marked. 
    IANA section has clear commetns for release as publication. 


Final comment: Shepherds question is 1/2 size of draft. 
Back