See below > On 28 Sep 2024, at 04:05, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > > 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 > 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 -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
