Re: [Last-Call] Genart last call review of draft-ietf-idr-ext-opt-param-11

[John Scudder <jgs=40juniper.net@xxxxxxxxxxxxxx>]

Hi Christer,

I chose to leave the abstract alone, however I updated the introduction for -13, similar to your suggestion:

   This document updates [RFC4271] by extending, in a backward-
   compatible manner, the length of the Optional Parameters in BGP OPEN.
   This is done by using Optional Parameter Type 255 as a distinguished
   value, that indicates an extended Optional Parameters Length field
   follows and that the parsing of the BGP OPEN should be modified
   according to these procedures.  In this case the Parameter Length
   field of the individual Optional Parameters in the BGP OPEN message
   is also extended.

Thanks again for your feedback,

—John

On Apr 22, 2021, at 10:36 AM, Christer Holmberg <christer.holmberg=40ericsson.com@xxxxxxxxxxxxxx> wrote:

[External Email. Be cautious of content]

Hi John,

>> Q1: As far as I understand, the document only defines a new BGP OPEN Optional

>> Parameter Type, but does not modify/add procedures in RFC 4271. So, is the
>> document really an update to RFC 4271? And, when reading RFC 5429, I cannot
>> find any text saying that new parameter types would require an update to RFC
>> 4271. I also looked at a few other RFCs that add new values to the BGP IANA
>> registry, and they were not updating any RFC.
>
> The document modifies the way a router parses the OPEN. It doesn’t just add a new type, indeed the new type is only added as a special token to tell the router to use the new procedures.

Would it be good to explicitly indicate that?

Something like:

   "This document updates RFC 4271 by extending, in a backward-compatible
   manner, the length of the Optional Parameters in the BGP OPEN, and by
   modifying the way a router parses the OPEN."

Regards,

Christer

> Nits/editorial comments:
> 
> Q2: I suggest that Section 2 is renamed to  "New Optional Parameter Type code",
> or something like that. OR, if the document really is updating RFC 4271,
> perhaps "Update to RFC 4271".

I’ve adopted your second suggestion.

> Q3: I suggest that Section 3 is renamed to "Backward Compatibility", or
> something like that.

Done.

—John

-- 
last-call mailing list
last-call@xxxxxxxx
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!VekRXfZ40ytJtNm-1zuv9KJuAV1ydVIzwKvejYNnzo0ti0AsnFotbZxEvgsYrg$

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call