BGP Large Communities Attribute
draft-ietf-idr-large-community-12

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.)

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

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...)?