Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-03.txt

Greetings, Ron asked me to take a look at this document and comment to the INTAREA mailing list. Since I'm not a GRE subject matter expert, I'm not in a position to judge whether the document accurately represents current practice. My comments will therefore necessarily be limited to issues of d

Re: [Int-area] [OPSEC] [v6ops] I-D Action: draft-gont-opsec-ipv6-eh-filtering-00.txt

On Wed, 16 Jul 2014, Joe Touch wrote: JT> I'm including INTAREA in the discussion because this doc seems to be an JT> end-run around intending to deprecate IPv6 HBH options, or at least to JT> redefine the option behavior bits defined in RFC 2460. IMO, that ought to be JT> addressed in INTAREA, not

[Int-area] draft-bonica-intarea-frag-fragile-01

Draft authors, Thanks for putting this draft together. *Major comments*: In Section 5.1, Transport Layer Solutions, please note that there is work in progress on fragmentation at the UDP layer and cite draft-ietf-tsvwg-udp-options . In S

Re: [Int-area] draft-bonica-intarea-frag-fragile-01

On Thu, May 31, 2018 at 12:39 PM, Ron Bonica wrote: > > In Section 6.1, *DNS*, please note that draft-ietf-tsvwg-udp-options >

Re: [Int-area] IPv4 ID update draft

> On Wed, 22 Jun 2011, Julien Laganier wrote: Julien> Because we' re talking about updating a venerable protocol I Julien> want to make sure that we get the necessary level of review Julien> for this draft before we forward it to IESG for publication Julien> as proposed standard. I've asked

Re: [Int-area] IPv4 ID update draft

ortly to address the issues as described. Joe, Many for the reply and for posting draft-ietf-intarea-ipv4-id-update-03. The following comments address one editorial issue that remains in -03 and some other things. > On 6/27/2011 9:00 PM, C. M. Heard wrote: > > - The proposed ban on over

Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05

On Sat, 2 Jun 2012, Joe Touch wrote: > Hi, Eliot, > > On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote: > > > > > Document: draft-ietf-intarea-ipv4-id-update-05 > > Title: Updated Specification of the IPv4 ID Field > > Reviewer: Eliot Lear > > Review Date: 2 June 2012 > > IETF Last Call Date: 31 May

Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05

On Sun, 3 Jun 2012, Glen Zorn wrote: > On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote: > > ... > > > > > In Section 6.1: > > > > > > > > > > > >>Datagram de-duplication can be accomplished using hash-based > &g

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

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

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

and why parcels are fiddling with UDP option > space - which may already be used by the UDP endpoints. > > Joe > > > — > Dr. Joe Touch, temporal epistemologist > www.strayalpha.com > > > > On Nov 14, 2024, at 4:54 PM, C. M. Heard wrote: > > > > Fred

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

eard On Fri, Nov 15, 2024 at 11:25 AM Templin (US), Fred L < fred.l.temp...@boeing.com> wrote: > Mike, your statement about not respecting datagram boundaries is incorrect > and under-informed – that is not what is happening. If you want documentary > evidence for GSO/GRO, it is found

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

need to > a new IP protocol number. > > Thank you - Fred > > > -Original Message- > > From: lloyd.w...@yahoo.co.uk > > Sent: Tuesday, November 19, 2024 3:58 PM > > To: C. M. Heard ; to...@strayalpha.com > > Cc: Gorry Fairhurst ; int-area ; > 6m

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

.e., GRO) the performance > optimization will be lost at that end. So, I don’t think there is any > problem to worry about. > > > > Fred Templin > > > > *From:* C. M. Heard > *Sent:* Thursday, November 14, 2024 4:55 PM > *To:* Templin (US), Fred L > *Cc

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

68 <https://datatracker.ietf.org/doc/html/rfc768>. Similar concerns apply to TCP. If this draft foes forward, it should note that it updates the UDP and TCP specifications, and it should get buy-in from TSVWG and TCPM. Thanks and regards, Mike Heard On Sun, Sep 29, 2024 at 3:51 PM C. M. Hea

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

ice. So, the > “reference” would be the source code of the popular implementations. > > > > Fred > > > > *From:* C. M. Heard > *Sent:* Friday, November 15, 2024 10:20 AM > *To:* Templin (US), Fred L > *Cc:* Gorry Fairhurst ; Joe Touch < > to...@strayalph

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

upper layer. Each > individual IP packet is an atomic unit that will be understood by upper > layers even if it is not restored into the original multi-segment buffer > originally prepared by GSO. This is the way GSO/GRO work today, and IP > parcels does not change that. > > >

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

On Thu, Nov 21, 2024 at 7:39 AM Tom Herbert wrote: > That is an interesting use case, but I think packing multiple acks > into a single packet is more of a transport layer issue than a network > layer issue and is independent of using larger MTUs. I suggest that > this can be solved by changing LTP