Telechat Review of draft-ietf-scone-protocol-08
review-ietf-scone-protocol-08-intdir-telechat-yourtchenko-2026-09-15-00

I am the assigned int-dir reviewer for this draft. These comments were written
with the intent of improving the Internet area aspects of the IETF drafts.
Please wait for direction from your document shepherd or AD before posting a
new version of the draft. For background on int-dir, please see the
[FAQ](https://wiki.ietf.org/en/group/intdir).

I found the document clearly written and easy to read.

This draft is basically ready for publication, but has
a few nits that should be fixed before publication.

section 5.2: nit

The document motivates the choice of 67 seconds partly by avoiding
synchronization with NAT timers. Section 8.1 & 7.1.2 specifies a separate
cadence of 20-30 seconds - and that is the interval which will have more impact
on the NAT behaviors, because it will reset the NAT idle timers well before 67
seconds. Also, often the clean up of the expired connections in CGN scenarios
has its own implementation-related jitter. An example here would be very
helpful, if possible. (this is a non-blocking comment)

section 6.2 & 6.4: nit

Section 6.2 says "...the indication alone is not sufficient to indicate that a
flow is QUIC with the potential for SCONE support", at the same time the first
sentence of 6.4 states "A network element could classify all 5-tuples where the
first observed UDP datagram ends in the indicator bytes as potential SCONE."

If the goal is to discourage using this indicator, 6.4 could restate
the 6.2 caveat explicitly (e.g., append to the first
sentence 'as noted in 6.2, this alone is a weak signal')
to remove any risk a reader takes 6.4 as a suggestion to treat the indicator as
reliable.

As written, an implementer who wants to further minimize the 2^-32 probability
of packet corruption in an easy way, might be tempted to mark the 5-tuple flows
that have marker bytes in the first packet as SCONE-eligible.

section 7.1: minor

The incremental checksum adjustment refers to RFC1141, which is updated by
RFC1624. Also, both RFC768 / RFC8200 specify the "checksum of 0 must become
0xffff". Also, IPv4 UDP can ignore checksum when it is zero - in which case a
blind update will corrupt it. It would be beneficial to mention all of this
explicitly.

Other than this, there is no IPv4/IPv6 specific comments that I could spot.

section 8.1: nit

This section could probably mention that datagrams with RFC8899 DPLPMTUD probe
packets should not have SCONE, if possible. Probes are deliberately sized
so they can be dropped during the probing, and having the infrequent SCONE
packet coalesced together will waste that opportunity for signal.
This does not alter the "MUST coalesce" in the document, but more a potential
implementation corner case.
(so is a non-blocking comment)

section 9.1: nit

"Section 8.1 states that endpoints only accept signals .."  => section 8.1
discusses sending the packets, this reference should read "Section 5.3".