Re: [Idr] Review of draft-ietf-large-community-06.txt

[David Farmer <[e-mail]>]

On Fri, Nov 4, 2016 at 12:18 PM, Job Snijders <[e-mail]> wrote:

> On Fri, Nov 04, 2016 at 08:04:47PM +1100, Geoff Huston wrote:
> > >> 4.  Canonical Representation
> > >>
> > >> I am confused here - this section used an example with TWO
> > >> canonical representations:
> > >>
> > >>   "For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222)."
> > >> Conventionally, it's better to use a single canonical
> > >> representation, so the authors should pick either a colon-delimited
> > >> list, or a bracketed comma+space separated object.
> >
> > > On 4 Nov. 2016, at 3:05 pm, Jakob Heitz (jheitz) <[e-mail]>
> wrote:
> > >
> > > To explain this one, it was originally "Textual Representation" and
> > > it was with colons only. Then we discovered that Bird uses commas as
> > > a separator. Since that does not degrade the utility, we allowed it.
> > > The real point is that it has to be exactly 3 positive decimal
> > > integers. If some implementations only offered hexadecimal or used 6
> > > int16's then it would become very difficult for ISPs to communicate
> > > community settings to customers.  I can change it to a single
> > > representation and detail the allowed deviations from it.
> >
> > if you make a canonical a SHOULD not a MUST then you can permit
> > variation without breaking the standard.
> >
> > So what you are saying is that the canonical representation of a
> > single Large Community value is three unsigned decimal integer values,
> > separated by a ‘:’ (colon) character, representing the value as a
> > triplet of unsigned 32-bit integer values. Implementations SHOULD
> > accept this representation as a valid form of representation of the
> > value of a Large Community.
>
> It appears the word "canonical" is maybe triggering something. The key
> element is that its three separate values. Nobody cares whether it is a
> colon, comma or a hypen.
>
> Does removing the word "canonical" address the raised remark?
>
> """
> 4.  Representation
>
>    Large BGP Communities MUST be represented as three separate unsigned
>    integers in decimal notation in the following order: Global
>    Administrator, Local Data 1, Local Data 2.  Numbers MUST NOT contain
>    leading zeros; a zero value MUST be represented with a single zero.
>    For example: 64496:4294967295:2, 64496:0:0, or (64496, 111, 222).
> """
>

I won't try to speak for Geoff, but it doesn't do it for me.

I think we should just say what you've said previously as a summary of the
intent, but use normative language.

I'd propose something like the following.

4.  Canonical Representation

   The canonical representation for Large BGP Communities is three separate
unsigned
   integers in decimal notation separated by colons in the following order:
Global
   Administrator, Local Data 1, Local Data 2.  For example:
64496:4294967295:2,
   64496:0:0,  or 64496:111:222

   Implementations SHOULD use the above canonical representation,
especially when
   representing a Large BGP Community for output.   Implementations MAY use
other
   delimiters than colons, especially for compatibility with a
configuration syntax.  However,
   Large BGP Communities MUST be represented as three separate unsigned
integers
   in decimal notation, regardless of the delimiters used. Further, the
numbers MUST NOT contain
   leading zeros, and a zero value MUST be represented with a single zero.







-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================