Subject: [tsvwg] draft-ietf-tsvwg-udp-options-13: Spec wording

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 31 Aug 2021 11:17:06 +0100

As a part of preparing for the TSVWG Interim this week, I reviewed the 
latest revision of this draft.

I found the following issues relating to the spec wording in rev 13.

Best wishes,

Gorry

(as WG document shepherd)

===

In section 4: Out-of-band:

 >> All other options (without a "*") MAY be implemented, and their
    use SHOULD be determined either out-of-band or negotiated.

- Just to clarify: This text seems to imply a sender might need some 
sort of negotiation before it can send the req/res option. Whereas, my 
thought was that it was fine to generate a “req” and see if the remote 
responded with a “”res”.

e.g. I wasn’t expecting any other signalling than just to try it for 
dplpmtud. With the obvious outcome that if it a res is not recieved, 
then it can’t be used. Is this what was expected?

===

In section 5: Standard UDP?
  >> The UDP length MUST be at least as large as the UDP header (8)
    and no larger than the IP transport payload. Datagrams with length
    values outside this range MUST be silently dropped as invalid and
    logged where rate-limiting permits.
- True, isn’t this normal UDP processing? If so, I think we can refer to 
the UDP RFC.

===
In Section 7: RFC2119 defintion or cross reference?

Section 7 appears to recap some requirements with a second use of 
RFC2119 keywords. I don’t think this is a problem, but I do expect this 
to be a citation of the earlier requirement, and hence I would expect to 
see a cross-reference to each section where the original requirement was 
made. e.g.
“   >> All options MUST be processed by receivers in the order
    encountered in the options list (see section xxx).”

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 31 Aug 2021 10:55:51 -0700

Notes below.

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Aug 31, 2021, at 3:17 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> As a part of preparing for the TSVWG Interim this week, I reviewed the latest revision of this draft.
> 
> - Just to clarify: This text seems to imply a sender might need some sort of negotiation before it can send the req/res option.

Yes, unless silently ignoring it is desired. Remember that unknown options (except UNSAFE) are silently ignored.

> Whereas, my thought was that it was fine to generate a “req” and see if the remote responded with a “”res”.

It is, but not if you don’t know what to do if you don’t get a response.

> e.g. I wasn’t expecting any other signalling than just to try it for dplpmtud. With the obvious outcome that if it a res is not recieved, then it can’t be used. Is this what was expected?

Yes - see above.

>  >> The UDP length MUST be at least as large as the UDP header (8)
> - True, isn’t this normal UDP processing? If so, I think we can refer to the UDP RFC.

It isn’t actually stated in that RFC. There’s a weird variant associated with TEREDO that appears to depend on this case for some sort of signaling. See Sec 15.

> Section 7 appears to recap some requirements with a second use of RFC2119 keywords. I don’t think this is a problem, but I do expect this to be a citation of the earlier requirement, and hence I would expect to see a cross-reference to each section where the original requirement was made. e.g.

Yeah - I’ll do that during the more final passes.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 31 Aug 2021 20:31:09 +0100

See in-line as "GF".

On 31/08/2021 18:55, [email-masked] wrote:
> www.strayalpha.com <http://www.strayalpha.com>
>
>> On Aug 31, 2021, at 3:17 AM, Gorry Fairhurst <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> sort of negotiation before it can send the req/res option.
>
> Yes, unless silently ignoring it is desired. Remember that unknown 
> options (except UNSAFE) are silently ignored.
>
GF: Sounds like one sentence can say that.
> It isn’t actually stated in that RFC. There’s a weird variant 
> associated with TEREDO that appears to depend on this case for some 
> sort of signaling. See Sec 15.
>
GF: :-(.
>> RFC2119 keywords. I don’t think this is a problem, but I do expect 
>> this to be a citation of the earlier requirement, and hence I would 
>> expect to see a cross-reference to each section where the original 
>> requirement was made. e.g.

Sounds like you plan to do the correct thing.

Gorry