Autonomous-System-Wide Unique BGP Identifier for BGP-4
draft-ietf-idr-bgp-identifier-14

[Ballot comment]
It is probably worth mentioning that the 4-octet unsigned integer is in network byte order so that someone doesn't assign it somewhere that doesn't use internal network byte order and gets an unexpected result.

[Ballot comment]
Please consider the editorial comments from the Gen-ART Review by
  David Black on 19-Apr-2011:

  At the end of Section 3, please remove the word "proposed" from the
  quoted text below.  These changes will no longer be "proposed" when
  published as an RFC.
  >
  > Therefore it is concluded that the revisions proposed in this
  > document do not introduce any backward compatibility issue with the
  > current usage of the BGP Identifier.

  Please consider replacing the Security Considerations (Section 4) with
  the following two sentences:
  >
  > This extension to BGP does not introduce new security
  > considerations. BGP security considerations are discussed
  > in [RFC4271].

[Ballot discuss]
In the Gen-ART Review by David Black on 19-Apr-2011, a few issues are
  raised that need resolution prior to approval.  They appear to be very
  straightforward, so I expect they will be resolved very quickly.

  This draft is missing an "Updates:" header on the title page to that
  tell the reader the RFCs that are updated by this document.  Also, the
  Abstract ought to indicate the RFCs that are updated by this document.
  I believe this document updates at least RFC 4271.

  The Acknowledgements section says that IPv6-only networks are a reason
  for these changes to BGP.  Please add a couple of sentences to the
  Introduction (Section 1) to include this motivation for these changes.

[Ballot comment]
Please consider the editorial comments from the Gen-ART Review by
  David Black on 19-Apr-2011:

  At the end of Section 3, please remove the word "proposed" from the
  quoted text below.  These changes will no longer be "proposed" when
  published as an RFC.
  >
  > Therefore it is concluded that the revisions proposed in this
  > document do not introduce any backward compatibility issue with the
  > current usage of the BGP Identifier.

  Please consider replacing the Security Considerations (Section 4) with
  the following two sentences:
  >
  > This extension to BGP does not introduce new security
  > considerations. BGP security considerations are discussed
  > in [RFC4271].

[Ballot comment]
Please consider the editorial comments from the Gen-ART Review by
  David Black on 19-Apr-2011:

  At the end of Section 3, please remove the word "proposed" from the
  quoted text below.  These changes will no longer be "proposed" when
  published as an RFC.
  >
  > Therefore it is concluded that the revisions proposed in this
  > document do not introduce any backward compatibility issue with the
  > current usage of the BGP Identifier.

  Please consider replacing the Security Considerations (Section 4) with
  the following two sentences:
  >
  > This extension to BGP does not introduce new security considerations.
  > BGP security considerations are discussed in [RFC4271].

[Ballot comment]
Please consider the editorial comments from the Gen-ART Review by
  David Black on 19-Apr-2011:

  At the end of Section 3, please remove the word "proposed" from the
  quoted text below.  These changes will no longer be "proposed" when
  published as an RFC.
  >
  > Therefore it is concluded that the revisions proposed in this
  > document do not introduce any backward compatibility issue with the
  > current usage of the BGP Identifier.

  In Section 4, Security Considerations, the document says:
  >
  > This extension to BGP does not change the underlying security issues.
  >
  David Black suggests changing that sentence to the following two sentences:
  >
  > This extension to BGP does not introduce new security considerations.
  > BGP security considerations are discussed in [RFC4271].

[Ballot comment]
Please consider the editorial comments from the Gen-ART Review by
  David Black on 19-Apr-2011:

  At the end of Section 3, please remove the word "proposed" from the
  quoted text below.  These changes will no longer be "proposed" when
  published as an RFC.
  >
  > Therefore it is concluded that the revisions proposed in this
  > document do not introduce any backward compatibility issue with the
  > current usage of the BGP Identifier.

  In Section 4, Security Considerations, the document says:
  >
  > This extension to BGP does not change the underlying security issues.

  David Black suggests changing that sentence to the following two sentences:
  >
  > This extension to BGP does not introduce new security considerations.
  > BGP security considerations are discussed in [RFC4271].

[Ballot comment]
Please consider the editorial comments from the Gen-ART Review by
  David Black on 19-Apr-2011:

  At the end of Section 3, please remove the word "proposed" from the
  quoted text below.  These changes will no longer be "proposed" when
  published as an RFC.
  >
  > Therefore it is concluded that the revisions proposed in this
  > document do not introduce any backward compatibility issue with the
  > current usage of the BGP Identifier.

  In Section 4, Security Considerations, the document says:
  >
  > This extension to BGP does not change the underlying security issues.
  >
  David Black suggests changing that sentence to the following two
  sentences:
  >
  > This extension to BGP does not introduce new security considerations.
  > BGP security considerations are discussed in [RFC4271].

[Ballot discuss]
In the Gen-ART Review by David Black on 19-Apr-2011, a few issues are
  raised that need resolution prior to approval.  They appear to be very
  straightforward, so I expect they will be resolved very quickly.

  This draft is missing an "Updates:" header on the title page to that
  tell the reader the RFCs that are updated by this document.  Also, the
  Abstract ought to indicate the RFCs that are updated by this document.
  I believe this document updates at least RFC 4271.

  The Acknowledgements section says that IPv6-only networks are a reason
  for these changes to BGP.  Please add a couple of sentences to the
  Introduction (Section 1) to include this motivation for these changes.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (AS-wide Unique BGP Identifier for BGP-4) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'AS-wide Unique BGP Identifier for BGP-4'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-04-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-identifier/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-identifier/

(1.a)

  Shepherd: John Scudder.  I have reviewed it and believe it is ready
  (indeed, overdue) for forwarding to the IESG.
 
(1.b)
 
  Extensive review and comment from the WG has been incorporated into
  the doc.
 
  (1.c)
 
  No.
 
  (1.d)
 
  No concerns.
 
  (1.e)
 
  I think the WG consensus amounts to "duh, please publish."
 
  (1.f)
 
  No.
 
  (1.g)
 
  IDNits throws complaints about page length; I don't think this should
  hold up publication since the RFC Editor will reformat it anyway.
 
  IDNits also throws a complaint about RFC 5378 related boilerplate.  I
  have asked the authors to confirm they are happy with the state of
  the disclaimer.  Again, I don't think this needs to hold up progress.
 
  (1.h)
 
  References are fine.

  (1.i)
 
  IANA section is fine.  (There are no requests for IANA.)

  (1.j)
 
  n/a
 
  (1.k)
 
    Technical Summary
      The base BGP specification defined the BGP Identifier as "a valid
      IPv4 host address".  This is problematic in some contexts
      including IPv6-only networks.  This document relaxes the
      definition to be a 4-octet unsigned, non-zero integer, and relaxes
      the "uniqueness" requirement so that only AS-wide uniqueness of
      the BGP Identifiers is required. These revisions to the base BGP
      specification do not introduce any backward compatibility issue.
   
    Working Group Summary
      The document has received extensive WG review and is generally
      non-controversial and clearly needed.
     
    Document Quality
      There are several existing implementations, and furthermore the
      document makes no on-the-wire protocol changes and is backward
      compatible.  The document does not use RFC 2119 language but I
      don't view this as a problem.