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

[<[e-mail]>]

Deal!

Cheers,
Med

> -----Message d'origine-----
> De : Joe Touch [mailto:[e-mail]]
> Envoyé : jeudi 18 juillet 2019 16:28
> À : 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)
> 
> Oh - catching up, using LEN as a flag seems a lot simpler (I thought the
> proposal was to reuse one of the KIND values).
> 
> I personally like the use of LEN=255 for this purpose rather than LEN=0;
> it seems more meaningful (the highest value means “go longer”)…
> 
> Joe
> 
> > On Jul 18, 2019, at 7:03 AM, Joe Touch <[e-mail]> wrote:
> >
> > 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
> >>
> >