Subject: [Idr] Benoit Claise's No Objection on draft-ietf-idr-large-community-11: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 05 Jan 2017 00:25:55 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-idr-large-community-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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