IETF Last Call Review of draft-ietf-tsvwg-udp-ecn-05
review-ietf-tsvwg-udp-ecn-05-opsdir-lc-pignataro-2026-04-07-00

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: draft-ietf-tsvwg-udp-ecn-05
- Reviewer: Carlos Pignataro
- Intended Status: Informational

---

## Summary

Choose one:

- Has Issues: I have some minor concerns about this document that I think
should be resolved before publication.

---

This document is well-scoped, clearly written, and grounded in real
implementation experience. Four issues below.

1. Is this really about "Configuration", or is it about API invocation?

The title "Configuring UDP Sockets for ECN" implies persistent,
operator-manageable configuration, parameters, defaults, deployment state. What
the document describes is calling the correct system call on a socket for a
session. Is there something to configure, store, or manage in the operational
sense?

2. Missing "Operational Considerations" section

Per draft-ietf-opsawg-rfc5706bis, an Operational Considerations section is
required, or explicit boilerplate explaining why none is needed. Potentially
suggested text, before Security Considerations:

"There are no new operations or manageability requirements introduced by this
document. This document records existing platform API behavior for enabling ECN
on UDP sockets. It does not define a new protocol or protocol extension and
introduces no new configuration parameters, management interfaces, or
monitoring surfaces."

3. DSCP clobbering risk understated

Current text (Section 4.1):

"Except for Apple platforms, this setsockopt() call also sets the
Differentiated Services Code Point (DSCP) that make up the rest of the header
byte. Applications making this call will generally want to preserve any
existing DSCP setting, which might require an additional getsockopt() call."

This understates the risk in two ways. (1) First, the consequence of not
preserving DSCP (silently disrupting QoS policy in networks where DSCP-based
classification is in use) is not stated. (2) Second, the
getsockopt()/setsockopt() sequence is not atomic; in multi-threaded servers
another thread can modify the TOS byte concurrently between the two calls.
Applications in that context might prefer the per-packet approach in Section
4.2, which sets ECN without touching DSCP and avoids the race entirely.

Suggested replacement:

4. Scope clarification relative to UDP Options / RFC 9868

RFC 9868 defines UDP transport-layer options in the surplus area after UDP user
data. This document is orthogonal: it addresses the IP-header ECN field via
socket APIs only. One sentence in the Introduction would make this explicit
preventing potential confusion:

"This document addresses access to the ECN field in the IP header via socket
APIs. It does not address UDP transport-layer options [RFC9868], which are a
separate extension mechanism operating at a different layer."

Might not be needed, but thought of bringing it up, since potential uses of
options for congestion.

I hope these are useful and clear!

Carlos Pignataro.