search

tsvwg / draft-ietf-tsvwg-udp-options

0 stars 0 forks source link

Med: WGLC Comments on Magic Number? #32

Open gorryfair opened 2 months ago

gorryfair commented 2 months ago

(Added by GF during WGLC)

Mike-Heard commented 2 months ago

Given the complete lack of evidence for any existing non-standard uses of the surplus area, I am not convinced that this is necessary, but I would not object if it would once and for all put to that issue to bed (see Tom Herbert's review https://mailarchive.ietf.org/arch/msg/tsvwg/qbc3I4qHDHj43vBrJWJFKoI-Byk/ and Issue #38).

gorryfair commented 2 months ago

I also am not aware if any existing specifications using this area. I am assuming that from the perspective of UDP Options, the OCS provides the required function, so is another magic number needed?

boucadair commented 1 month ago

The risk is actually not with existing but:

OCS is not intended to prevent future non-standard uses of the surplus area, nor does it enable shared use with mechanisms that do not comply with UDP options.

I still think we need some explicit indicator.

gorryfair commented 1 month ago

The kind field is providing the extension point. Couldn't future extensibility be allowed by defining a new UDP Option? Another field would seem to add overhead, but I'm not yet sure that I understand problem needs this in future.

Mike-Heard commented 1 month ago

Couldn't future extensibility be allowed by defining a new UDP Option?

Indeed it could. A new option that is placed after OCS (possibly with a NOP for alignment) that consumes the remainder of the surplus area will accomplish this objective. If that option does not affect the interpretation of the preceding UDP data area if it is ignored, it can be assigned a SAFE option codepoint; in that case an extended length field might be needed . If the option can't be safely ignored, then then it would need to be assigned an UNSAFE codepoint. In that case, it could be defined to consume the remainder of the surplus area (much like FRAG) and thereby not need an extended length field.

gorryfair commented 3 days ago

Looking at this thread, I suggest we close it by adding a description above to explicitly show one way this can be extended. I concur, this does not require a specific magic number.

boucadair commented 3 days ago

Looks like a good plan. Thanks.