[tcpm] Intdir early review of draft-ietf-tcpm-accurate-ecn-30

[Joseph Touch via Datatracker <[e-mail]>]

Reviewer: Joseph Touch
Review result: Ready with Issues

>From an INTAREA perspective, this document has no concerns.

However, viewed from a transport perspective, the document has one key concern
- the use of two TCP code points. Information expressed in TCP options should
occur inside the option payload, not be encoded indirectly in code points. The
variants desired in Table 5 can easily be differentiated using a single bit of
the first counter indicated. There's no good reason to consume two TCP code
points for this optimization.

Additionally and somewhat less significantly, it is nonsensical to assign
non-adjacent code points, again as this unnecessarily breaks up the TCP code
point space for use by other future assignments (e.g., were there to be a
legitimate need for a range of code points). Frankly, see no good reason why
this mechanism should not use code points in order of availability, e.g., 80
(and, with GREAT hesitation, 81 if warranted).