Re: [tsvwg] Options larger than 255 (was RE: draft-ietf-udp-options issues from IETF 104)

[<[e-mail]>]

Joe, 

Kind extension is a distinct issue from length extension. I would dissociate how this is provided.

We don't need to extend the kind space to allow for larger options!

Cheers,
Med

> -----Message d'origine-----
> De : Joe Touch [mailto:[e-mail]]
> Envoyé : jeudi 18 juillet 2019 16:04
> À : Gorry (erg)
> Cc : BOUCADAIR Mohamed TGI/OLN; [e-mail]
> Objet : Re: [tsvwg] Options larger than 255 (was RE: draft-ietf-udp-
> options issues from IETF 104)
> 
> We can - there are a few ways to do this:
> - pick one KIND and let it say that the next 3 bytes indicate the next
> KIND and 2-byte length
> - use a subset of the range of KINDs, reserved in advance, for this
> purpose
> 
> Note that code points are already assigned to mimic TCP:
> 0 is already in use
> 254 is already reserved for experiments
> 255 is already reserved, likely to extend the KIND space itself
> 
> It might be reasonable to use 255 for this purpose because it inherently
> extends the KIND space anyway.
> 
> Joe
> 
> > On Jul 18, 2019, at 5:45 AM, Gorry Fairhurst <[e-mail]>
> wrote:
> >
> > Ah so, I guess the document editors canm work out what is best to do.
> >
> > My wish was to systematically allow larger options to be possible.
> >
> > Gorry
> >
> > On 18/07/2019, 13:41, [e-mail] wrote:
> >> Re-,
> >>
> >> 0/1 are illegal values. These values MUST NOT be used. A receiver will
> discard them systematically.
> >>
> >> With the proposed approach: 254/255 are legal values... but with a
> special meaning.
> >>
> >> Cheers,
> >> Med
> >>
> >>> -----Message d'origine-----
> >>> De : Gorry Fairhurst [mailto:[e-mail]]
> >>> Envoyé : jeudi 18 juillet 2019 14:26
> >>> À : BOUCADAIR Mohamed TGI/OLN
> >>> Objet : Re: Options larger than 255 (was RE: [tsvwg] draft-ietf-udp-
> >>> options issues from IETF 104)
> >>>
> >>> I don't mind the choice of codepoint, my understaning was zero was an
> >>> invalid length, and an easy thing to test in code. Choosing 254 or 255
> >>> seems less obvious to me, but if there are good reasons, just say...
> >>>
> >>> Gorry
> >>>
> >>> On 18/07/2019, 12:48, [e-mail] wrote:
> >>>> Re-,
> >>>>
> >>>> Associating a meaning with Len=0 as proposed by Joe may not be
> >>> intuitive. An alternate approach would be:
> >>>> * 'Len' only covers the option data field (that is, 'kind' and 'Len'
> >>> fields are not covered. The overall option length can be easily
> inferred).
> >>>> * Associate a meaning with one of the two values we grabbed:
> >>>>   - 254 or 255: a 16-bit extended length field follows
> >>>>
> >>>> Cheers,
> >>>> Med
> >>>>
> >>>>> -----Message d'origine-----
> >>>>> De : tsvwg [mailto:[e-mail]] De la part de Gorry
> >>> Fairhurst
> >>>>> Envoyé : jeudi 18 juillet 2019 12:22
> >>>>> À : [e-mail]
> >>>>> Cc : tsvwg
> >>>>> Objet : Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
> >>>>>
> >>>>>> Gorry
> >>>>> P.S. I like the idea to explicitly allow options longer than 255
> bytes?
> >>>>> - This seems useful for fragmentation and would be an easy addition,
> >>>>> someone suggested using 0 option length to indicate a 16b length
> field,
> >>>>> which could make total sense. As in:
> >>>>>
> >>>>>
> https://mailarchive.ietf.org/arch/msg/tsvwg/B4oeZkpagdl4gkAMDCFW7F1A7_8
> >>>>>
> >>>>> Gorry
> >