BGP Large Communities Attribute

Note: This ballot was opened for revision 11 and is now closed.

(Jari Arkko) Yes

Comment (2017-01-05 for -11)
No email
send info
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)".

(Alia Atlas) Yes

(Joel Jaeggli) Yes

Comment (2016-12-18 for -11)
No email
send info
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) Yes

Comment (2017-01-03 for -11)
No email
send info
Brilliant. Thank you!

Alvaro Retana Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2017-01-04 for -11)
No email
send info
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) (was Discuss) No Objection

Comment (2017-01-05 for -11)
No email
send info
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

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.

       The attribute is suitable for use with four-octet
       Autonomous System Numbers

       The attribute is suitable for use with all Autonomous System Numbers including four-octet
       Autonomous System Numbers

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Comment (2017-01-02 for -11)
No email
send info
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...)?

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection