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

[Geoff Huston <[e-mail]>]

> On 5 Nov. 2016, at 4:18 am, 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).
> “”
> 


change the MUST to a SHOULD and drop the example that contains two different delimiters (as the text is fully functional and the example provides no further information, but adds confusion).

I suspect that the second sentence is overly normative (!!)

If you simply said that: “The decimal notation does not use leading zeros, and a zero value is represented as a single ‘0’.” then I suspect that you are consistent with a SHOULD, and adequately convey the minimal intent you are aiming at here

 

regards,

  Geoff