Re: [tcpm] Secdir last call review of draft-ietf-tcpm-rfc793bis-24

[Gorry Fairhurst <[e-mail]>]

> On 5 Sep 2021, at 18:34, Kyle Rose <[e-mail]> wrote:
> 
> 
>> On Sun, Sep 5, 2021 at 12:51 PM Gorry Fairhurst <[e-mail]> wrote:
>> To me, this has a much more complicated history, and I think TCP has been extended many times - albeit not sucessfully in the ways mentioned above, but in other watys. It seems like a discussion of whether ossification has been good or bad. I'd also really quite concerned to see words like "often" used without clarifying further -  there are legitimate cases where filtering can be useful for managing the security of TCP connections: A firewall in one context might do many things, and that might actually be a good security model; in another context that might be different. 
>> 
> I'm not in favor of making a value judgment or discussing the wisdom of approaches to addressing ossification in this document, but I do think, given the rare opportunity of publishing a 793bis, that it's worth putting the implications of TCP ossification in writing so we don't have to relitigate these issues or explain in detail why such-and-such won't work whenever they come up in future attempts to extend TCP. I guess I'm arguing that we shouldn't need Joe Touch to explain multiple times to multiple groups why a given proposal won't work when we can explain it once and mic-drop a one-line reference to that.
> 
>> I'd also question the importance of https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it, in relation to the core TCP spec, even though the message is clear for MPTCP.
>  
> This is why I put it in a parenthetical. It's not directly relevant to TCP, but it does indicate to the interested reader an approach that newer protocol designs have taken to avoid one of the causes of ossification. I agree it's not essential.
> 
> Kyle
> 
Thanks for the reply. Seems like you and Wes converged on something slimmer. You could cite RFC 9065, if you wanted another ref. 

Best wishes,
Gorry