Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-18.txt

From: [email-masked]
Date: Sat, 26 Mar 2022 10:00:57 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.

        Title           : Transport Options for UDP
        Author          : Joe Touch
	Filename        : draft-ietf-tsvwg-udp-options-18.txt
	Pages           : 41
	Date            : 2022-03-26

Abstract:
   Transport protocols are extended through the use of transport header
   options. This document extends UDP by indicating the location,
   syntax, and semantics for UDP transport layer options.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-18

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 26 Mar 2022 10:03:18 -0700

Minor update to sync-up the Kind numbers and unify how they’re indicated for each option. Also noted that RESERVED values are neither SAFE nor UNSAFE until defined.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Mar 26, 2022, at 10:00 AM, [email-masked] wrote:
> 
>

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 26 Mar 2022 12:02:44 -0700

On Sat, Mar 26, 2022 at 10:03 AM [email-masked] wrote:

> Minor update to sync-up the Kind numbers and unify how they’re indicated
> for each option. Also noted that RESERVED values are neither SAFE nor
> UNSAFE until defined.
>

Hi Joe,

I think that the following language needs to be backed out:

   >> RESERVED Kind values MUST NOT be assumed to be either SAFE nor
   UNSAFE until defined.

I appreciate that the intent is to defer a final, irrevocable decision on
where the safe/unsafe range is divided until we have more implementation
experience, but the problem is that implementations of the current spec
need to know what to do when receiving one of the RESERVED values -- ignore
and skip over the option or discard the whole option area. If we leave it
up to the implementation, which the language in -18 would do, we risk (or,
more likely, guarantee) inconsistent behavior that would preclude any
standardized uses of the RESERVED values. So even though our ability to
predict the future is imperfect, we do have to make a decision now on how
these values are treated. My recommendation is to say that the values 0-191
are treated as SAFE and that the values 192-255 are treated as UNSAFE.

If we reserve at least one value for each range (e.g., 191 for SAFE, and
255 for UNSAFE) to allow for an extended KIND code (somewhat like the uld
UNSAFE option did), then IMO we have more than adequate future proofing.

Thanks,

Mike Heard

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 26 Mar 2022 13:07:49 -0700

—

> On Mar 26, 2022, at 12:02 PM, C. M. Heard <[email-masked]> wrote:
> 
> On Sat, Mar 26, 2022 at 10:03 AM [email-masked] <mailto:[email-masked]> wrote:
> I appreciate that the intent is to defer a final, irrevocable decision on where the safe/unsafe range is divided until we have more implementation experience, but the problem is that implementations of the current spec need to know what to do when receiving one of the RESERVED values -- ignore and skip over the option or discard the whole option area. If we leave it up to the implementation, which the language in -18 would do, we risk (or, more likely, guarantee) inconsistent behavior that would preclude any standardized uses of the RESERVED values. So even though our ability to predict the future is imperfect, we do have to make a decision now on how these values are treated. My recommendation is to say that the values 0-191 are treated as SAFE and that the values 192-255 are treated as UNSAFE.
> 
> If we reserve at least one value for each range (e.g., 191 for SAFE, and 255 for UNSAFE) to allow for an extended KIND code (somewhat like the uld UNSAFE option did), then IMO we have more than adequate future proofing.

Given it’s binary, that’s probably OK. I’ll revert that in -19.

Joe