Re: [tcpm] draft-ietf-tcpm-rfc793bis-14: options

[Joe Touch <[e-mail]>]

Hi, Med, 

See below…

Joe

> On Jul 31, 2019, at 10:38 PM, [e-mail] wrote:
> 
> ...
>  
> [Med] What I had in mind is to import the option layout and key information into 793bis.

I don’t think it’s particularly useful to duplicate information this way - esp. for experimental options.

> What I’m hoping with this change is to avoid having discussion similar to https://mailarchive.ietf.org/arch/msg/tcpinc/fVCnrvMouTdeIuwTytoBRNmztHU <https://mailarchive.ietf.org/arch/msg/tcpinc/fVCnrvMouTdeIuwTytoBRNmztHU> (end of the message) each time a new option is discussed.    

We’re going to have that discussion every time anyway - that is about 
a) whether a new option under development should be treated as experimental or standards-track from the start
b) whether to endorse squatting on assigned code points

Defiance is not ignorance. No amount of text avoids the former.

>  
> - these are not details needed for standards-compliant operation
>  
> [Med] I’m not sure to parse this comment. RFC6994 is a standard track RFC.
>  
> (esp. because they shouldn't be used for final standards-track options).

The sentence is explained in the note I put below it - although the method is standards-track (as is congestion control, FWIW), the details are not critical to a minimal, standards-compliant implementation for a few reasons:

- standards-compliant implementations shouldn’t be deployed publicly with use of experimental options at all (at best, disabled by default)
- 6994 explains how others will interpret the fields of those code points anyway, so if you ignore them you’re just risking overlapping use with others. the length of the EdIDs (esp longer values) makes that sufficiently unlikely anyway

----