Subject: [Idr] Warren Kumari's Discuss on draft-ietf-idr-ext-opt-param-11: (with DISCUSS and COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Tue, 20 Apr 2021 15:32:07 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-idr-ext-opt-param-11: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be a trivial to clear DISCUSS.
This text terrifies me:
"It is not considered a fatal error to receive an OPEN message whose
(non-extended) Optional Parameters Length value is not 255, and whose first
Optional Parameter type code is 255 -- in this case the encoding of this
specification MUST be used for decoding the message. A warning MAY be logged."
It smacks of trying to be too clever, and that the correct response (IMO) when
trying to set up a session with something obviously broken is to abort and
throw an error.

However, I'm sure that there was some discussion, and that the WG decided that
this was a good idea; unfortunately I was unable to find anything discussion on
this, so all I'm asking for is some reassurance that this was discussed and
that this behavior was chosen as a good idea...

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

Thank you for this document. It is clear, and solves a real problem.

Also, thanks to Al Morton for his OpsDir review - as always, it is much appreciated.

---

From: John Scudder <[email-masked]>
Date: Wed, 21 Apr 2021 15:04:11 +0000

Hi Warren,

Thanks for your comment. 

I understand the “too clever by half” reaction. As I recall the motivation for this was that in the future we might want to migrate to using only this encoding. The "encode the short stuff the short way" is the obviously right thing to do for the immediate future, because the extension isn't (can't be) signaled. But in ten years or something, it potentially starts to feel annoying to have to drag the old encoding along even though everyone already adopted the new one a decade back. So this leaves the door open to us making that transition painlessly and without drama.

Regards,

—John

> On Apr 20, 2021, at 6:32 PM, Warren Kumari via Datatracker <[email-masked]> wrote:
> 
> 
> Please refer to https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!RwBGRElSG71MB-4xuoZ_K7AsJh9Ov1reQdYmsqJiiijBgUzS0Q__vFRx6cpoZA$
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-ext-opt-param/__;!!NEt6yMaO-gk!RwBGRElSG71MB-4xuoZ_K7AsJh9Ov1reQdYmsqJiiijBgUzS0Q__vFQWHO5WBg$
> 
> 
>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Apr 2021 11:14:22 -0400

On Wed, Apr 21, 2021 at 11:04 AM John Scudder <[email-masked]> wrote:

> Hi Warren,
>
> Thanks for your comment.
>
> I understand the “too clever by half” reaction. As I recall the motivation
> for this was that in the future we might want to migrate to using only this
> encoding. The "encode the short stuff the short way" is the obviously right
> thing to do for the immediate future, because the extension isn't (can't
> be) signaled. But in ten years or something, it potentially starts to feel
> annoying to have to drag the old encoding along even though everyone
> already adopted the new one a decade back. So this leaves the door open to
> us making that transition painlessly and without drama.
>

Ah, thanks.

Makes sense / good enough for me -- I'll clear my DISCUSS position.

W

> > Please refer to
> https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!RwBGRElSG71MB-4xuoZ_K7AsJh9Ov1reQdYmsqJiiijBgUzS0Q__vFRx6cpoZA$

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra