[Int-area] Re: [tsvwg] Re: UDP options [was IP Parce ls and Advanced Jumbos (AJs)]

See below

> On 28 Sep 2024, at 04:05, Brian E Carpenter <[email protected]> wrote:
> 
> Joe,
> On 28-Sep-24 03:13, [email protected] wrote:
>>>> On Sep 27, 2024, at 7:58 AM, Templin (US), Fred L <[email protected]> wrote:
>>> 
>>>> Indeed. But if sendmsg() and recvmsg() can and do generate RFC2675 packets, it means that any discussion of obsoleting RFC2675 should be
>>>> off the table.
>>> 
>>> No one that I know of has suggested obsoleting RFC2675 - my documents do not say "obsoletes" (nor even "updates”).
>> That approach to UDP jumbo grams is incompatible with UDP options.
>> And yes, there was a proposal to move that RFC to historic:
>> Jones, T., G. Fairhurst, "Change Status of RFC 2675 to Historic," draft-jones-6man-historic-rfc2675, May 2019.
>> 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.
> 
> 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.
> 
>    Brian
> 
I do not think the I-D needs to say anything about the deployment status of jumbograms, that another topic.

I suggest if people wish, we just say that  users of this technique can or cannot simultaneously use UDP options.

Gorry 
> 
> 

_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]