Autonomous-System-Wide Unique BGP Identifier for BGP-4
draft-ietf-idr-bgp-identifier-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
14 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2011-05-31
|
14 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-05-31
|
14 | (System) | IANA Action state changed to No IC from In Progress |
2011-05-31
|
14 | (System) | IANA Action state changed to In Progress |
2011-05-31
|
14 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-05-31
|
14 | Amy Vezza | IESG has approved the document |
2011-05-31
|
14 | Amy Vezza | Closed "Approve" ballot |
2011-05-31
|
14 | Amy Vezza | Approval announcement text regenerated |
2011-05-31
|
14 | Amy Vezza | Ballot writeup text changed |
2011-05-12
|
14 | Amy Vezza | Removed from agenda for telechat |
2011-05-12
|
14 | Amy Vezza | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation. |
2011-05-12
|
14 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-12
|
14 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-12
|
14 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-12
|
14 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-11
|
14 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-11
|
14 | Pete Resnick | [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 … [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. |
2011-05-11
|
14 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-11
|
14 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded |
2011-05-11
|
14 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-11
|
14 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-10
|
14 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-09
|
14 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-07
|
14 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded |
2011-05-06
|
14 | Russ Housley | [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 … [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]. |
2011-05-06
|
14 | Russ Housley | [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 … [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. |
2011-05-06
|
14 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss |
2011-05-06
|
14 | Stewart Bryant | Ballot writeup text changed |
2011-05-06
|
14 | Russ Housley | [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 … [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]. |
2011-05-06
|
14 | Russ Housley | [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 … [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]. |
2011-05-06
|
14 | Russ Housley | [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 … [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]. |
2011-05-06
|
14 | Russ Housley | [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 … [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]. |
2011-05-06
|
14 | Russ Housley | [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 … [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]. |
2011-05-06
|
14 | Russ Housley | [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 … [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. |
2011-05-06
|
14 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded |
2011-05-06
|
14 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-05
|
14 | Stewart Bryant | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup. |
2011-05-05
|
14 | Stewart Bryant | Placed on agenda for telechat - 2011-05-12 |
2011-05-05
|
14 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2011-05-05
|
14 | Stewart Bryant | Ballot has been issued |
2011-05-05
|
14 | Stewart Bryant | Created "Approve" ballot |
2011-05-04
|
14 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-05-04
|
14 | (System) | New version available: draft-ietf-idr-bgp-identifier-14.txt |
2011-05-04
|
14 | Stewart Bryant | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead. |
2011-04-18
|
14 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-04-13
|
14 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
2011-04-06
|
14 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Uri Blumenthal |
2011-04-06
|
14 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Uri Blumenthal |
2011-04-04
|
14 | Amy Vezza | Last call sent |
2011-04-04
|
14 | Amy Vezza | 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: … 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/ |
2011-04-04
|
14 | Stewart Bryant | Last Call was requested |
2011-04-04
|
14 | Stewart Bryant | State changed to Last Call Requested from Publication Requested. |
2011-04-04
|
14 | Stewart Bryant | Last Call text changed |
2011-04-04
|
14 | (System) | Ballot writeup text was added |
2011-04-04
|
14 | (System) | Last call text was added |
2011-04-04
|
14 | (System) | Ballot approval text was added |
2011-04-04
|
14 | Stewart Bryant | Ballot writeup text changed |
2011-03-30
|
14 | Cindy Morgan | (1.a) Shepherd: John Scudder. I have reviewed it and believe it is ready (indeed, overdue) for forwarding to the IESG. (1.b) … (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. |
2011-03-30
|
14 | Cindy Morgan | Draft added in state Publication Requested |
2011-03-30
|
14 | Cindy Morgan | [Note]: 'John Scudder (jgs@juniper.net) is the document shepherd.' added |
2011-01-18
|
13 | (System) | New version available: draft-ietf-idr-bgp-identifier-13.txt |
2010-07-27
|
12 | (System) | New version available: draft-ietf-idr-bgp-identifier-12.txt |
2010-02-04
|
11 | (System) | New version available: draft-ietf-idr-bgp-identifier-11.txt |
2010-02-04
|
14 | (System) | Document has expired |
2009-08-03
|
10 | (System) | New version available: draft-ietf-idr-bgp-identifier-10.txt |
2008-05-13
|
09 | (System) | New version available: draft-ietf-idr-bgp-identifier-09.txt |
2006-11-22
|
08 | (System) | New version available: draft-ietf-idr-bgp-identifier-08.txt |
2006-05-16
|
07 | (System) | New version available: draft-ietf-idr-bgp-identifier-07.txt |
2005-11-11
|
06 | (System) | New version available: draft-ietf-idr-bgp-identifier-06.txt |
2005-04-05
|
05 | (System) | New version available: draft-ietf-idr-bgp-identifier-05.txt |
2004-09-21
|
04 | (System) | New version available: draft-ietf-idr-bgp-identifier-04.txt |
2003-12-03
|
03 | (System) | New version available: draft-ietf-idr-bgp-identifier-03.txt |
2003-04-04
|
02 | (System) | New version available: draft-ietf-idr-bgp-identifier-02.txt |
2002-09-13
|
01 | (System) | New version available: draft-ietf-idr-bgp-identifier-01.txt |
2002-02-12
|
00 | (System) | New version available: draft-ietf-idr-bgp-identifier-00.txt |