BGP Communities for Data Collection
draft-ietf-grow-collection-communities-08
Yes
No Objection
(Alex Zinin)
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(Jon Peterson)
(Scott Hollenbeck)
(Steven Bellovin)
Note: This ballot was opened for revision 08 and is now closed.
David Kessens Former IESG member
Yes
Yes
(2004-09-15)
Unknown
Comment from Pekka Savola from the ops directorate: However, what this document implicitly aims to do (whether knowingly or not) is describe a BCP for *internal* communities, not just for exporting to data collectors. Who would bother to just munge their communities to exactly these values just for data collection?
Alex Zinin Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
(was Discuss)
No Objection
No Objection
(2004-10-21)
Unknown
Reviewed by Michael Patton, Gen-ART Still one spelling mistake (refered rather than referred), but -06 is good to go.
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2004-09-14)
Unknown
After the table in section 3.1, the legend includes: : : <R> is the 5-bit Region : However, <R> is not used in the table. Rather, the possible values of <R> are enumerated. The legend entry should be replaced with an explanation.
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Steven Bellovin Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2004-09-14)
Unknown
Nit: In Definitions, "referred to coloring"--> "referred to as coloring" In 2.1. A and B are defined to be peers when (i). A and B exchange routes via BGP, and (ii). traffic exchange between A and B is settlement-free. I found it odd that this section did not define the term "transit". It is mentioned in the introduction and touched on 2.9. As a term of art, it is hard to discuss "peering" without discussing "transit", since so many of the operational discussions revolve around when one is used versus the other. I am not suggesting that "transit" should be its own category (the more specific categories given look fine), but it does seem like it would be useful to include a definition and possibly indicate which categories fall under that grouping. As a purely individual preference, I think it would be interesting to pull anycast routes out of the other special purpose routes, because I suspect the growth in that particular special purpose. But this reflects my own research interest, and possibly not the best design.
Thomas Narten Former IESG member
No Objection
No Objection
(2004-09-16)
Unknown
> BGP, and (ii). traffic exchange between A and B is settlement-free. Defn. of settlement-free? > Internal more specific routes are those routes which are frequently s/more specific/more-specific/ section 2.5. which vs. that > Service providers often have settlement free interconnections with an s/settlement free/settlement-free/ > this community as 10876:4338 (0x1F2 == 4338 decimal). s/0x1F2/0x10f2/?