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

[Geoff Huston <[e-mail]>]

> On 4 Nov. 2016, at 6:56 pm, Job Snijders <[e-mail]> wrote:
> 
> Dear Geoff,
> 
> Thank you for your time and review.
> 
> On Fri, Nov 04, 2016 at 12:25:08PM +1100, Geoff Huston wrote:
>>> On 4 Nov. 2016, at 11:47 am, heasley <[e-mail]> wrote:
>>> 
>>>> 7. ----------------
>>>> 
>>>> 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.
>>> 
>>> Are you sure; a separator is not defined in the text.
>> 
>> If the “Canonical Representation” is to represent the Large
>> Communities Attributes value as a sequence of triplets, where the
>> triplet is three unsigned decimal values, but not to define the
>> representation of the delimiter between the elements of the triplet,
>> nor the delineator between successive triplets, then I think that this
>> is an incomplete canonical representation.
> 
> The working group has debated long and furiously on this element of the
> text. In the end we ended up with the text without specifying a
> separator because the separator isn't what is important at all.
> 
> The 'Canonical Representation' section came to be because we want to
> prevent a 'asdot vs asplain'-style time waste. It should be clear that
> each Large Community is composed of three fields, separated by
> something. If you read network documentation from another party and they
> reference "111:333:555" it should be clear it is a Large community; even
> if your router makes you type in "(111, 333, 555)". Or maybe your router
> solely consumes XML or JSON as configuration: [111, 333, 555].
> 
> It was a conscious choice to make the representation liberal enough that
> all implementors currently at the table felt comfortable with it, and
> that the operators at the table also have guidance on what the large
> community will look like in communication.
> 
> Given the above context, do you have a suggestion other then "pick eiher
> a colon-delimited or bracketed"? My personal preference would be to
> keep the original text.
> 

I think you make a clear SHOULD support for a particular representation of the
triplet, which makes other representations still ok, but there is a clear preference
for interoperability that says “clearly state a preferred format for representating
these values".

My previous response to Jakob proposes some candidate text.

regards,

   Geoff