> On Sep 27, 2024, at 8:02 PM, Brian E Carpenter <brian.e.carpen...@gmail.com>
> wrote:
>
>> We COULD have a new option with a longer length, but that’s not in our
>> baseline draft.
>
> Wouldn't that be tricky, because the options follow the whole payload as I
> understand it? So a JumboUDPgram has to be received in full, however big it
> is, before the option saying that it's a jumbo can be received and
> interpreted.
I was assuming use of the atomic FRAG approach, in which the UDP length is 8
(not zero) and the options then appear immediately after the UDP header.
> Where the udp-options draft says:
>
>>> The technique has been proposed for deprecation [Jo19].
>
> I think you'd better change it to something like:
>
> The technique is known to be in active use in special situations, so cannot
> reasonably be deprecated. However, users of this technique cannot
> simultaneously use UDP options.
Yes - we’ve already got that queued up as part of Gorry’s shepherd review.
Joe
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
