[tsvwg] Re: Erik Kline's Yes on draft-ietf-tsvwg-udp-options-dplpmtud-14: (with COMMENT)

[Gorry Fairhurst <[e-mail]>]

On 17/02/2025 16:13, [e-mail] wrote:
> FWIW, regarding zero-length indicators per RFC8085, the udp-options 
> draft says:
>
>
>     Zero-length UDP packets have
>     been used as "liveness" indicators seeSection 5 of [RFC8085] <https://datatracker.ietf.org/doc/html/rfc8085#section-5>), but
>     such use is dangerous because they lack unique identifiers (the IPv6
>     base header has none, the IPv4 ID field is deprecated for such use
>     [RFC6994 <https://datatracker.ietf.org/doc/html/rfc6994>]).
>
> I would suggest that this doc should align with udp-options and try to 
> avoid such indicators.
>
> Joe
>
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com

The editor's copy for this currently says:

                 <t>At the receiver, a received probe packet that does 
not carry application data
                 does not form a part of the end-to-end
                 transport data and is not delivered to the Upper Layer 
protocol
                 (i.e., application or protocol layered above UDP). A 
zero-length payload
                 notification could still be delivered to the application,
                 see Section 5 of <xref target="RFC8085"></xref>, although
                 Section 18 of <xref 
target="I-D.ietf-tsvwg-udp-options"></xref>
                 discusses the implications when using UDP Options.</t>
             </section> <!-- End of Procedures for UDP Options: Increase -->

Do you think this ought to be updated further?

Gorry

>
>> On Feb 15, 2025, at 2:45 PM, Erik Kline via Datatracker 
>> <[e-mail]> wrote:
>>
>> Erik Kline has entered the following ballot position for
>> draft-ietf-tsvwg-udp-options-dplpmtud-14: Yes
>>
>> 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/about/groups/iesg/statements/handling-ballot-positions/ 
>>
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options-dplpmtud/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> # Internet AD comments for draft-ietf-tsvwg-udp-options-dplpmtud-14
>> CC @ekline
>>
>> * comment syntax:
>>  - https://github.com/mnot/ietf-comments/blob/main/format.md
>>
>> * "Handling Ballot Positions":
>>  - 
>> https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>
>> ## Comments
>>
>> ### S4.2
>>
>> * "At the receiver, a received probe packet that does not carry
>>   application data does not form a part of the end-to-end transport
>>   data and is not delivered to the Upper Layer protocol (i.e.,
>>   application or protocol layered above UDP)."
>>
>>  It is theoretically possible, however, that a UDP-Options-aware
>>  implementation could "deliver" a zero-length payload notification to
>>  the application, I presume (a la RFC 8085 S5)?
>>
>>  I suppose a similar question applies to S4.4.
>>
>> ## Nits
>>
>> ### S3
>>
>> * "less than of equal to" ->
>>  "less than or equal to"
>>
>> ### S3.1
>>
>> * "Reception of a RES Option by the sender" ->
>>  "Reception of a RES Option by the REQ sender"
>>
>>  or something, as there are two "senders" involved.
>>
>>
>>
>