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

From: Christer Holmberg via Datatracker <[email-masked]>
Date: Thu, 15 Apr 2021 12:34:06 -0700

Reviewer: Christer Holmberg
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-idr-ext-opt-param-11
Reviewer: Christer Holmberg
Review Date: 2021-04-15
IETF LC End Date: 2021-04-09
IESG Telechat date: 2021-04-22

Summary: The document is easy to read, and I have no technical issues. However,
I do have a minor question, and a couple of editorial suggestions, that I'd
like the authors to address.

Major issues: N/A

Minor issues:

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.

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".

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

---

From: John Scudder <[email-masked]>
Date: Wed, 21 Apr 2021 21:24:30 +0000

Hi Christer,

Thanks for your review.

> On Apr 15, 2021, at 3:34 PM, Christer Holmberg via Datatracker <[email-masked]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> <https://urldefense.com/v3/__https://trac.ietf.org/trac/gen/wiki/GenArtfaq__;!!NEt6yMaO-gk!SpXM0yYhkqFsTZDByFUPco5EutovKUYeL5VoR2Wb7DUHLrZxG7pdNLoL2KrhyA$ >.
> 

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.

> perhaps "Update to RFC 4271".

I’ve adopted your second suggestion.

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

Done.

—John

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Apr 2021 16:35:49 +0300

Christer, thank you for your review . I have entered a No Objection ballot for this document.

Lars

> On 2021-4-15, at 22:34, Christer Holmberg via Datatracker <[email-masked]> wrote:
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Apr 2021 14:36:55 +0000

Hi John,

> 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

Done.

—John

---

From: John Scudder <[email-masked]>
Date: Thu, 22 Apr 2021 19:22:45 +0000

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=[email-masked]<mailto:christer.holmberg=[email-masked]>> wrote:

Hi John,

Something like:

Regards,

Christer

Done.

—John

--
last-call mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/last-call__;!!NEt6yMaO-gk!VekRXfZ40ytJtNm-1zuv9KJuAV1ydVIzwKvejYNnzo0ti0AsnFotbZxEvgsYrg$

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Apr 2021 07:03:47 +0000

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 <[email-masked]> On Behalf Of John Scudder
Sent: torstai 22. huhtikuuta 2021 22.23
To: Christer Holmberg <christer.holmberg=[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-idr-ext-opt-param-11

Hi Christer,

   is also extended.

—John

Hi John,

Something like:

Regards,

Christer

Done.

—John
--
last-call mailing list
[email-masked]<mailto:[email-masked]>
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>