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

["[e-mail]" <[e-mail]>]

Hi, Mirja,

I thought the purpose of IESG and area reviews was to provide input that might actually have an impact.

If that’s not the case - if WG approval is the end of the debate - please do let me know. I have at least one doc right now that we can take off the agenda and skip all those reviews and votes.

Otherwise, and actually regardless, my feedback stands. I don’t care if the WG as a whole had consensus on this matter. I would hope the IESG has a better perspective on burning multiple codepoints for a single protocol.

But that too, please let me know. Because if that’s the case, we could even consider standing down the IANA ports team. I know a few people - myself included - who have better things to do with our time if it’s going to be dismissed based on the argument below.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Mar 6, 2025, at 10:43 AM, Mirja Kuehlewind <[e-mail]> wrote:
> 
> Hi Joe,
> 
> thanks for your review. As you might know the question about use of two options was extensively discussed in the wg and I believe the current approach has consensus.
> 
> About the use of code points. This is a good point, however, there is not really a requirement to use consecutive code points. 172 and 174 where initially selected as they translate to 0xAC and 0xAE. While it doesn't really matter which code points to use though, it is unfortunately too late now to change as things are already implemented and getting deployed.
> 
> Mirja
> 
> 
> 
> On 30.08.24, 17:09, "Joseph Touch via Datatracker" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> 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).
> 
> 
> 
> 
> _______________________________________________
> tcpm mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> 
>