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.