+1 — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Sep 29, 2024, at 3:51 PM, C. M. Heard <he...@pobox.com> wrote: > > Fred, > > I currently hold the editing pen for the changes to the UDP Options draft > that have been requested prior to the shepherd report, and my intention is to > remain silent about how, if at all, IP Parcels and Advanced Jumbos (AJs) will > support UDP Options. > > I'll provide comments on the IP Parcels and Advanced Jumbos work at a later > date, when I have spare intellectual cycles to fully comprehend the contents > of draft-templin-6man-parcels2. At this point I must confess that, like > Brian, I do not understand how a receiver will locate the options trailer in > the case of an IP Payload Length exceeding 65535. Like Joe, I think it would > be better to put the options just after the UDP header and make a new UNSAFE > option to delimit the position where the options end and the user data > begins.. But that discussion (and the corresponding update to the UDP options > draft) can occur when it is ripe; IMO that is not the case at this time. > > Respectfully, > > Mike Heard > > On Sun, Sep 29, 2024 at 3:07 PM Templin (US), Fred L > <Fred.L.Templin=40boeing....@dmarc.ietf.org > <mailto:40boeing....@dmarc.ietf.org>> wrote: >> IP parcels and Advanced Jumbos (AJs) of all sizes ranging from 1 to 2^32 are >> now eligible >> >> for using UDP options. This is just one way in which they offer a better >> service than RFC2675 >> >> Jumbograms, but there are also many others. >> >> >> >> Joe, you can either note this in your draft or just leave it be and let my >> draft do an >> >> “updates UDP options”. >> >> >> >> Thank you - Fred >> >> >> >> From: Brian Carpenter <brian.e.carpen...@gmail.com >> <mailto:brian.e.carpen...@gmail.com>> >> Sent: Saturday, September 28, 2024 2:20 AM >> To: Gorry (erg) <go...@erg.abdn.ac.uk <mailto:go...@erg.abdn.ac.uk>> >> Cc: Joe Touch <to...@strayalpha.com <mailto:to...@strayalpha.com>>; Templin >> (US), Fred L <fred.l.temp...@boeing.com <mailto:fred.l.temp...@boeing.com>>; >> Tim Chown <tim.ch...@jisc.ac.uk <mailto:tim.ch...@jisc.ac.uk>>; Internet >> Area <Int-area@ietf.org <mailto:Int-area@ietf.org>>; IPv6 List >> <i...@ietf.org <mailto:i...@ietf.org>>; tsvwg IETF list <ts...@ietf.org >> <mailto:ts...@ietf.org>> >> Subject: [EXTERNAL] Re: [tsvwg] Re: UDP options [was IP Parcels and Advanced >> Jumbos (AJs)] >> >> >> >> EXT email: be mindful of links/attachments. >> >> >> >> That works for me.. >> >> >> >> (via tiny screen & keyboard) >> Regards, >> Brian Carpenter >> >> >> >> On Sat, 28 Sept 2024, 19:08 Gorry (erg), <go...@erg.abdn.ac.uk >> <mailto:go...@erg.abdn.ac.uk>> wrote: >> >> See below >> >> > On 28 Sep 2024, at 04:05, Brian E Carpenter <brian.e.carpen...@gmail.com >> > <mailto:brian.e.carpen...@gmail.com>> wrote: >> > >> > Joe, >> > On 28-Sep-24 03:13, to...@strayalpha.com <mailto:to...@strayalpha.com> >> > wrote: >> >>>> On Sep 27, 2024, at 7:58 AM, Templin (US), Fred L >> >>>> <Fred.L.Templin=40boeing....@dmarc.ietf.org >> >>>> <mailto: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
