[Idr] I-D Action: draft-ietf-idr-large-community-00.txt

[t.petch <[e-mail]>]

Changing the Subject to reflect the adoption.

In section 7, I would like to give IANA a more specific instruction,
such as

'... in the IANA BGP Path Attributes registry in the Border Gateway
Protocol (BGP) Parameters group '

The less we ask them to do, the more accurate they are likely to be.

And the Abstract should not contain citations.

Which draft-heitz got right (otherwise I would have commented on it:-).
More generally, and perhaps being picky,
draft-ietf-idr-large-community-00.txt
is not the I-D which the WG agreed to adopt!  The convention I like is
that when a WG adopts an I-D, then the only change is to the title
because that is the text which has been adopted.  Maybe all the changes
you have made do have the consensus of the WG, I do not know (except, as
I said above, I would have commented on the addition of citations to the
Abstract had you done that beforehand).

Tom Petch


----- Original Message -----
From: "Job Snijders" <[e-mail]>
To: "I Don't Remember" <[e-mail]>
Sent: Saturday, September 24, 2016 10:26 AM
Subject: Re: [Idr] WG adoption of draft-heitz-idr-large-community; one
week to comment on early code point allocation


> Dear Working Group,
>
> On Wed, Sep 21, 2016 at 02:27:27PM -0400, John G. Scudder wrote:
> > Authors, please remove the code point from the draft and resubmit as
> > draft-ietf-idr-large-community.
>
> https://tools.ietf.org/html/draft-ietf-idr-large-community-00 has been
> posted!
>
> Notable changes:
>
>     o substantial rewording (thanks Heasley)
>     o added BNF to replace the incorrect regex (thanks Peter van Dijk)
>     o added security section (copy+pasted from RFC 4360)
>     o added error handling (thanks Bush, Haas, Keyur)
>     o remove squated IANA codepoint (squatting is a dutch tradition
;-))
>     o updated currently known implementations (section 6)
>     o updated the acknowledgements
>
> I have some questions for the working group:
>
> 1) Is the BNF in section 3 helpful or should it be removed for
>    document compactness?
>
> 2) Does the section 3 'textual representation' wording allow
sufficient
>    flexibility to accomodate BIRD- or JunOS-style syntax?
>
> 3) Should values in the range "65535:0:0 -
65535:4294967295:4294967295" be
>    reserved to accomodate any future well known communities? 65535 is
>    used in RFC1997 so i see merit in continuing to use that number.
>
> 4) is it sufficiently clear how to encode multiple Large BGP
Communities?
>    We all "know" what is meant because of rfc1997, but is the text
actually
>    documenting this good enough?
>
> Thanks!
>
> The full diff can be viewed here:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-00.tx
t
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr