BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
RFC 4456
Note: This ballot was opened for revision 02 and is now closed.
(Bill Fenner) Yes
(Brian Carpenter) (was Discuss) No Objection
Comment (2005-09-29)
No email
send info
send info
From Gen-ART review by Lakshimnath Dondeti: ... 2. ROUTER_ID is now referred to as BGP Identifier. Both terms have been around for a long while now. Perhaps the authors should explain what they have in mind in changing that term. ... 4. Editorial Nit: Replace "With the existing BGP model," in Page 3 with something like "In BGP-4"
(Margaret Cullen) No Objection
(Ted Hardie) No Objection
(Sam Hartman) (was Discuss) No Objection
Comment (2006-01-24)
No email
send info
send info
I originally entered the following discuss. There is question within the IESG about whether this is actually the requirement or not. I don't want to block this document indefinitely while we answer general questions. All the implementations that sent in implementation report forms claimed to test against Cisco and Juniper. However as far as I can see reading the document Cisco and Juniper did not actually fill out the form. I think you need to have two implementations who both participate in the implementation report interoperate. I'm willing to be convinced that this is not a requirement, but it does significantly concern me that none of the implementations in the implementation report tested against each other.
(Scott Hollenbeck) No Objection
(Russ Housley) (was Discuss) No Objection
Comment (2005-09-26)
No email
send info
send info
A Table of Contents would have helped me review this document.
(David Kessens) No Objection
(Allison Mankin) No Objection
Comment (2005-09-29 for -)
No email
send info
send info
This comment replies to the document only citing RFC2385 in the Security Considerations. That section should now also cite the BGPbis spec, because that has expanded the security considerations for BGP - although there's still a lot of emphasis on 2385, it is able as well to point to draft-ietf-bgp-vuln. Discussing the risks well is a big step forward. If noone in the IESG objects to the DS of RFC2796 making a textual departure (I don't), then RFC2796 should directly cite draft-ietf-bgp-vuln. Sometimes there's a formalistic requirement to change very few words from PS to DS.
(Jon Peterson) No Objection
(Mark Townsley) No Objection
(Bert Wijnen) No Objection
Comment (2005-09-29 for -)
No email
send info
send info
First, I share Sam's DISCUSS concern. No need to hold 2 discusses on that. Citation/Reference [7] (i.e. RFC2119) must be a Normative Reference. $ idnits draft-ietf-idr-rfc2796bis-01.txt idnits 1.77 (21 Aug 2005) draft-ietf-idr-rfc2796bis-01.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: * The document seems to lack an IANA Considerations section. * Looks like you're using RFC 2026 boilerplate. Better change to RFC 3978/3979.