Joe,
On 28-Sep-24 03:13, to...@strayalpha.com wrote:
On Sep 27, 2024, at 7:58 AM, Templin (US), Fred L
<Fred.L.Templin=40boeing....@dmarc.ietf.org> 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
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
