Subject: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-ext-opt-param-11: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 21 Apr 2021 13:15:44 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-idr-ext-opt-param-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this short and sweet document; I have very little to say.

Section 2

And we're sure that a two-byte length is going to be enough "for ever",
right?

Section 3

   MUST NOT be used other than as described above.  If encountered as an
   actual Optional Parameter Type code, it MUST be treated as an

Is "actual Option Parameter Type code" synonymous with "in any position
other than the first option parameter type"?  In some sense "actual
Option Parameter" seems slightly under-specified.

---

From: John Scudder <[email-masked]>
Date: Wed, 21 Apr 2021 22:17:27 +0000

Hi Ben,

Thanks for your comments.

On Apr 21, 2021, at 4:15 PM, Benjamin Kaduk via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
...
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2

Yep! Well, for small values of “forever” anyway, as your quotation marks imply. The length field in the fixed BGP message header is only two bytes long, so if we need more than that, we’ll be doing BGP-5, and then everything will be up for grabs and we won’t need this spec any more.

Section 3

Thank you, your wording is better. It now says:

   Although the Optional Parameter Type code 255 is used in this
   specification as the indication that the extended encoding is in use,
   it is not a bona fide Optional Parameter Type in the usual sense, and
   MUST NOT be used other than as described above.  If encountered in
   any position other than the first Optional Parameter Type, it MUST be
   treated as an unrecognized Optional Parameter and handled according
   to [RFC4271] Section 6.2.

—John

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 21 Apr 2021 19:05:39 -0700

> On Apr 21, 2021, at 4:15 PM, Benjamin Kaduk via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

Ah, a very good reason; my apologies for missing that fact.

>    to [RFC4271] Section 6.2.

Excellent; thanks!

-Ben