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

Hi John,

Would it be better to say “and how the parsing of the BFP OPEN is modified”?  Because, the document is not only saying that one should do something, but HOW it is done :)

Regards,

Christer

From: Gen-art <gen-art-bounces@ietf.org> On Behalf Of John Scudder
Sent: torstai 22. huhtikuuta 2021 22.23
To: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>
Cc: draft-ietf-idr-ext-opt-param.all@ietf.org; idr@ietf.org; gen-art@ietf.org; last-call@ietf.org
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-idr-ext-opt-param-11

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@dmarc.ietf.org<mailto:christer.holmberg=40ericsson.com@dmarc.ietf.org>> 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@ietf.org<mailto:last-call@ietf.org>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!VekRXfZ40ytJtNm-1zuv9KJuAV1ydVIzwKvejYNnzo0ti0AsnFotbZxEvgsYrg$<https://protect2.fireeye.com/v1/url?k=d42fed95-8bb4d4d8-d42fad0e-86b568293eb5-db9bb5f1f8c980ab&q=1&e=e63753a2-3e0d-413f-a66e-06d68918c5dd&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flast-call__%3B%21%21NEt6yMaO-gk%21VekRXfZ40ytJtNm-1zuv9KJuAV1ydVIzwKvejYNnzo0ti0AsnFotbZxEvgsYrg%24>