Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Joe Touch <[e-mail]>]

> On Jul 12, 2019, at 7:09 AM, Black, David <[e-mail]> wrote:
> 
> I think I’m over on the “FORCE” side of that dichotomy (i.e., I don’t agree with “easily optional”), although we can split hairs on what degree of “FORCE” is appropriate.   My underlying reasons are these two:
>                 1) strong "running code" evidence of what breaks when the OCS is omitted,
>                 2) helps defend against … possibility [of] … other uses of surplus space
>  
> IMHO, OCS being the “default” is a good starting point, but … my current view is that on its own, item 1) justifies “MUST implement/SHOULD use” language for OCS (and “SHOULD use” is complementary to and stronger than “default”) and setting the space aside for OCS, at least when LITE is not present.  That view is reinforced by item 2), and I note neither of those two items are within the control of the endpoint implementer or application that uses the endpoint’s UDP option support.

Also note that the “running code” evidence is based on an error. That’s why I worry about designing overhead we live with forever only to overcome a bug that may be ephemeral.

That said, again, is there some reason you think we CANNOT allow the user to turn off OCS (in this case, set to zero)? Again, this is UDP. The risk - and the decision - is up to the user, IMO.

Joe