BGP Large Communities Attribute
draft-ietf-idr-large-community-12
Yes
(Alia Atlas)
(Alvaro Retana)
No Objection
(Alexey Melnikov)
(Alissa Cooper)
(Deborah Brungard)
(Kathleen Moriarty)
(Spencer Dawkins)
(Stephen Farrell)
(Suresh Krishnan)
Note: This ballot was opened for revision 11 and is now closed.
Alia Atlas Former IESG member
Yes
Yes
(for -11)
Unknown
Alvaro Retana Former IESG member
Yes
Yes
(for -11)
Unknown
Jari Arkko Former IESG member
Yes
Yes
(2017-01-05 for -11)
Unknown
Of course we shall approve this document and make it an RFC! Thanks for the work. However, I do agree with Robert Spark's Gen-ART comments re: the first sentence of the Security Considerations section. I'd either remove the sentence, add pointers to other RFCs with actual security implications content, or reformulate to ".... has similar security properties as RFC 1997 (even if those were not documented in that RFC)".
Joel Jaeggli Former IESG member
Yes
Yes
(2016-12-18 for -11)
Unknown
High-time we did this thanks. I think the network reviewers suggestion to leave in the implmentation status is a fine one. it does naturally capture only a moment in time. but since it points to useful examples of implmentation that's good.
Terry Manderson Former IESG member
Yes
Yes
(2017-01-03 for -11)
Unknown
Brilliant. Thank you!
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -11)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -11)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2017-01-04 for -11)
Unknown
The first sentence of section 6 seems to delegate at least some security considerations to RFC 1997. That RFC's security considerations entirely comprises the statement that the RFC does not discuss security. (This would have been a DISCUSS, but I gather from discussion of the genart review that the authors intend to remove the sentence.)
Benoît Claise Former IESG member
(was Discuss)
No Objection
No Objection
(2017-01-05 for -11)
Unknown
Thanks John for an excellent shepherd writeup. I see from the abstract: "The attribute is suitable for use with four-octet ASNs." I also see this text, which doesn't mention four-octet ASNs The Global Administrator field is intended to allow different Autonomous Systems to define BGP Large Communities without collision. This field SHOULD be an Autonomous System Number (ASN), in which case the Local Data Parts are to be interpreted as defined by the owner of the ASN. The use of Reserved ASNs (0 [RFC7607], 65535 and 4294967295 [RFC7300]) is NOT RECOMMENDED. What if the ASN is two bytes, we use padding? How? Even if we would say: "This field SHOULD be an four-octet Autonomous System Number (ASN)", it doesn't preclude inserting a two-octet ASN in the Global Administrator field. Isn't it better to specify how? From RFC 6793: Currently assigned two-octet AS numbers are converted into four-octet AS numbers by setting the two high-order octets of the four-octet field to zero. Such a four-octet AS number is said to be mappable to a two-octet AS number. =============================== After some discussion on the idr list. My reasoning has been: either you mention that two-octet ASN can be represented in four-octets (RFC6793) or you mention: suitable for all ASNs (2 or 4) It's so obvious to you guys in your community. Ok, it seems that we're going in circle here. You guys understood my issue. It was DISCUSSed. I believe the draft should be clearer, but this is not DISCUSS-level point any longer. Moving to a COMMENT, and trusting the responsible shepherd and AD. For the record, John's proposal solveds my issue. OLD: The attribute is suitable for use with four-octet Autonomous System Numbers NEW: The attribute is suitable for use with all Autonomous System Numbers including four-octet Autonomous System Numbers
Deborah Brungard Former IESG member
No Objection
No Objection
(for -11)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -11)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2017-01-02 for -11)
Unknown
One question: Since the Global Administrator field could also be not an ASN, would it be useful to say something about what should be done if an unknow value is received (ignore, remove, log an error...)?
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -11)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -11)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -11)
Unknown