Hi Bob, Authors, Gorry*, * Gorry, please review the asterisk marked items below (search *).
Authors, please note that we have cleared your earlier approvals on the AUTH48 page, as there are a couple of questions below that require your input (search for your names). In addition, we that you send your approvals after the possible technical updates are resolved. Bob, thank you for your very thorough review! We have updated the document as requested. Note that there are some comments in the text below. We have snipped resolved items. > This email was based on just looking at the highlighted diffs. Once I've sent > it, I will try to read through the whole doc one last time (in parallel to > discussion of the two outstanding discussion items noted below). The current files are available here: https://www.rfc-editor.org/authors/rfc9768.xml https://www.rfc-editor.org/authors/rfc9768.txt https://www.rfc-editor.org/authors/rfc9768.pdf https://www.rfc-editor.org/authors/rfc9768.html Diffs highlighting the most recent updates only: https://www.rfc-editor.org/authors/rfc9768-lastdiff.html https://www.rfc-editor.org/authors/rfc9768-lastrfcdiff.html (side by side) AUTH48 diffs: https://www.rfc-editor.org/authors/rfc9768-auth48diff.html https://www.rfc-editor.org/authors/rfc9768-auth48rfcdiff.html (side by side) Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9768-diff.html https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html (side by side) If you already started your full review, the previous version of the text is available here: https://www.rfc-editor.org/authors/rfc9768v6.txt If you prefer a different format, please let us know. > CURRENT: > an AccECN Server using large receive offload (LRO) might prefer to > disable LRO until > the ACK of the SYN/ACK was sent and it has transitioned out of SYN-RCVD > state. > PROPOSED: > an AccECN Server using large receive offload (LRO) might prefer to > disable LRO until > it transitions out of SYN-RCVD state (when it first receives an ACK that > covers the SYN/ACK). > REASON: > Having caught this technical bug in the spec, in side-discussion with > Richard I pointed out that we need to specify which of the two events would > cause LRO to start, because the ACK of the SYN/ACK can be lost or delayed, > then a later ACK would trigger the transition out of SYN-RCVD state. Richard > replied that it would be best to use the transition. > Incidentally, the text could not be kept as it was anyway, because > the Server doesn't know when (or whether) the ACK was sent (by the > Client); The Server only knows when it receives the ACK. > I've also avoided the passive (and 'was' should have been 'has been' > anyway) > > CURRENT: > For example, it will not disable ECN (at least not just because ACE is > 0b000) and it will not set s.cep. > PROPOSED: > That is, it will not disable ECN (at least not just because ACE is 0b000) > and it will not set s.cep. > REASON: > When I wrote this sentence, it was not intended as an example, but > rather, a more specific statement of the previous sentence (it was changed > from 'i.e.' at draft-33, but I can't find a reason given for changing it). * Gorry, please review the above two items and let us know if the updates are approved. > §3.2.2.4. Testing for Zeroing of the ACE Field > > [@Sandy, please wait for a decision from an ongoing parallel discussion about > whether this test should now be removed completely from the draft. > In that case, both changes below to this section might become redundant - > they merely improve clarity/grammar/consistency. ] > > CURRENT: (related to Sandy's item #11) > might depend on the likelihood to experience these scenarios, > PROPOSED: > might depend on the likelihood of experiencing these scenarios, > REASON: > The Current text is grammatically possible (just), but the Proposed text > is the more common and universally accepted construction. See > https://forum.wordreference.com/threads/likelihood-to.3114359/ or search > > CURRENT: > If reordering occurs, the first feedback packet that arrives will not > necessarily be the same > PROPOSED: > If reordering occurs, the first feedback packet that arrives after the > three-way handshake will not necessarily be the same > REASON: > This refers back to an earlier sentence that is now a long way back due > to extra reasoning and notes having been added. "The first packet that > arrives" was originally in quotes to make it clear this was a reference back, > but if the quotes are to be removed, we have to repeat the full definition of > which packet is being talked about. > Personally, I think it would be clearer and briefer to reintroduce the > quotes and just say "The first packet that arrives". As noted, we will wait for further guidance on the suggested updates above. > §3.2.2.5.1. Packet Receiver Safety Procedures > > CURRENT: > Active Queue Management (AQM) packet schedulers > PROPOSED: > Active Queue Management (AQM) algorithms > REASON: > IMHO, an AQM algorithm isn't typically a scheduler (because it doesn't > typically or necessarily alter the order of packets, which is what > 'scheduling' implies). * Gorry, please confirm that this update is okay. > §4. Updates to RFC 3168 (Sandy's item #17) > > I'm afraid I disagree with Mirja's agreement with you. > In all cases, where section headings from RFC3168 have been removed, I would > prefer them to be reinstated (in whatever style is the norm). This follows > the general rule that references should be briefly described inline. Each > quoted heading gave just enough context.Removing them would turn this section > into an incomprehensible list of mappings between numbers, which would then > require the reader to follow each reference to understand the implications of > each change. We have updated the text to use the form “Section X (title) of [RFC3168].” We also added section titles to the last bullet item. Please let us know if any updates are needed. > §8. Security and Privacy Considerations > Last two para's: > [@Sandy, please wait for a decision from parallel discussion about the last > two para's > "As Accurate ECN exposes ... > ... for that matter." > ] Ack - we are leaving this here as a reminder that this is an open issue. > §9.2. Informative References (Sandy's item #26) > CURRENT: > InfiniBand Trade Association, "InfiniBand Architecture Specification", > <https://www.infinibandta.org/ibta-specification/>. > PROPOSED: > InfiniBand Trade Association, "InfiniBand Architecture Specification" > Volume 1, since Release 1.4 (2020), > <https://www.infinibandta.org/ibta-specification/>. > REASONING: > Pls check with Richard, who added this ref a month after I took a step > back. Given he added it to AccECN draft-31 in Dec 2024, I assume he was > referring back to the release when precise ECN feedback had been added to > RoCEv2. The specs are only available to members, so it's hard for me to check > now. > I notice Richard has put the following URL in as an XML comment: > https://cw.infinibandta.org/document/dl/7781 but it's Permission Denied for > me. The entry currently appears as follows: [RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture Specification", Volume 1, Release 1.4, 2020, <https://www.infinibandta.org/ibta-specification/>. Richard, please let us know if any updates are desired. > s/A.2.2. Safety Algorithm with the AccECN Option/ > /A.2.2. Safety Algorithm With the AccECN Option/ > REASON: > Consistent with previous section heading. We capped it as requested for consistency. Note that the different handling stems from CMOS 18 (released September 2024), which indicates that prepositions of five or more characters should be capitalized in titles. Prior to that, all prepositions were lowercased. > Throughout: > I actually disagree with Mirja and think that all should be changed back to > IP-ECN, but I wouldn't fight for this. > Unfortunately, there is no consistency in the RFCs to guide us. However, I > would have thought these ought to follow the general grammar rule about > hyphenation of compound nouns used as adjectives before the noun that they > modify - a rule intended to remove ambiguity. > > There are 9 occurrences TCP-ECN and 7 occurrences of TCP ECN. I suggest they > are all made consistent with IP-ECN/IP ECN. > Even when the words 'TCP ECN' are used for other things than the flags (e.g. > TCP ECN feedback or TCP ECN capability negotiation) IMHO it would still be OK > to hyphenate (or not) as long as they are all consistent. I added the hyphens so TPC-ECN and IP-ECN appear consistently when acting as adjectives before the noun. Usage is mixed in the RFCs - it would be ideal if there is some general agreement that the hyphenated or unhyphenated form is preferred. Then the RPC can help guide authors in that direction in the future. Mirja, please let us know if you feel strongly about not hyphenating these terms. > <aside> tags (Sandy's item #37) > I agree with Mirja for most of the notes, but <aside> could/would be > appropriate in the cases below, however it's not important enough to me to > fight over it: > • §3.2.2.4:Note that a host in AccECN mode MUST continue to provide > Accurate ECN feedback to its peer, even if it is no longer sending ECT itself > over the other half-connection. > • §3.2.2.4: Note that the Data Sender MUST NOT test whether the arriving > counter in the initial ACE field has been initialized to a specific valid > value -- the above check solely tests whether the ACE fields have been > incorrectly zeroed. This allows hosts to use different initial values as an > additional signalling channel in the future. > • §3.2.3.2.4: Note that the Data Sender MUST NOT test whether the > arriving byte counters in an initial AccECN Option have been initialized to > specific valid values -- the above checks... These have been marked as <aside>s. Again, thank you for your thorough review and the helpful explanations! We look forward to your next round of updates. Thanks, Sandy Ginoza RFC Production Center > > > Thank you again, for staying focused and precise throughout such a long spec. > Amazing! > > Cheers > > > > Bob > > > > > On 21/10/2025 16:45, Sandy Ginoza wrote: >> Thanks Mirja! I know Bob usually likes to do a full read through, so we’ll >> be on the lookout for his updates. >> >> Thanks, >> Sandy Ginoza >> RFC Production Center >> >> >> >> >>> On Oct 21, 2025, at 8:35 AM, Mirja Kuehlewind <[email protected]> wrote: >>> >>> Yes I’m in touch with Bob and he promised me to reply so hopefully we‘ll >>> see something soon! >>> >>> >>>> Am 21.10.2025 um 18:24 schrieb Sandy Ginoza <[email protected]>: >>>> >>>> Hi Mirja and Richard, >>>> >>>> Thank you for your quick replies. We have noted your approvals on the >>>> AUTH48 page <https://www.rfc-editor.org/auth48/rfc9768>. >>>> >>>> We do not believe we have received input from Bob yet. Do you know if he >>>> is receiving these mails? >>>> >>>> Thanks, >>>> Sandy Ginoza >>>> RFC Production Center >>>> >>>> >>>> >>>> >>>>> On Oct 21, 2025, at 1:53 AM, Mirja Kuehlewind (IETF) >>>>> <[email protected]> wrote: >>>>> >>>>> Yes, that works for me! Thanks! >>>>> >>>>> >>>>> >>>>>>> On 21. Oct 2025, at 09:53, Scheffenegger, Richard >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>> >>>>>> Sounds perfect! Thanks! >>>>>> >>>>>> Mirja, do you concur? >>>>>> >>>>>> >>>>>> Richard Scheffenegger >>>>>> Senior Solution Architect >>>>>> NAS & Networking >>>>>> >>>>>> NetApp >>>>>> +43 1 3676 811 3157 Direct Phone >>>>>> +43 664 8866 1857 Mobile Phone >>>>>> [email protected] >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Sandy Ginoza <[email protected]> >>>>>> Sent: Montag, 20. Oktober 2025 19:04 >>>>>> To: Scheffenegger, Richard <[email protected]> >>>>>> Cc: Mirja Kuehlewind <[email protected]>; RFC Editor >>>>>> <[email protected]>; Bob Briscoe <[email protected]>; >>>>>> [email protected]; [email protected]; Michael Tuexen >>>>>> <[email protected]>; Zaheduzzaman Sarker >>>>>> <[email protected]>; auth48archive >>>>>> <[email protected]> >>>>>> Subject: Re: AUTH48: RFC-to-be 9768 <draft-ietf-tcpm-accurate-ecn-34> >>>>>> for your review >>>>>> >>>>>> EXTERNAL EMAIL - USE CAUTION when clicking links or attachments >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hi Richard, >>>>>> >>>>>> The following reflects the updated text, and the diffs (only) can be >>>>>> viewed in the following files: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVFbzDLww$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastrfcdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVAfG0B5I$ >>>>>> (side by side) >>>>>> >>>>>> Current Section 1: >>>>>> It >>>>>> is called the more "Accurate ECN feedback" scheme, or AccECN for >>>>>> short. >>>>>> >>>>>> Current Section 1.3: >>>>>> Accurate ECN feedback: The more Accurate ECN feedback scheme is >>>>>> called AccECN for short. >>>>>> >>>>>> Because the text indicates "Accurate ECN feedback” is referred to as >>>>>> AccECN, we do not believe other updates are needed throughout the text. >>>>>> >>>>>> The current files are available here: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.xml__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GV8xZuVnI$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.txt__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVYY2szYY$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.pdf__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVyMl7NGE$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVLG4uHT0$ >>>>>> >>>>>> Diffs of the most recent updates only: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVFbzDLww$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastrfcdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVAfG0B5I$ >>>>>> (side by side) >>>>>> >>>>>> AUTH48 diffs: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-auth48diff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GV71nPedA$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-auth48rfcdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVaNvCWN0$ >>>>>> (side by side) >>>>>> >>>>>> Comprehensive diffs: >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-diff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVzZc6dx4$ >>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVG7QTG4c$ >>>>>> (side by side) >>>>>> >>>>>> Please let us know if this is acceptable and/or if other changes are >>>>>> needed. >>>>>> >>>>>> Thank you, >>>>>> Sandy Ginoza >>>>>> RFC Production Center >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Oct 20, 2025, at 3:47 AM, Scheffenegger, Richard >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Hi Sandy, >>>>>>> >>>>>>> >>>>>>> Can you please go ahead with the proposed changes to include the >>>>>>> "feedback" suffix when referring to the schemes of AccECN feedback and >>>>>>> also Classic ECN feedback? >>>>>>> >>>>>>> Looking at the latest AUTH48 diff, I didn’t really spot on which places >>>>>>> in total that moficiation (addition of "feedback" when talking about >>>>>>> AccECN and Classic ECN) would go, really. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> Richard Scheffenegger >>>>>>> Senior Solution Architect >>>>>>> NAS & Networking >>>>>>> >>>>>>> NetApp >>>>>>> +43 1 3676 811 3157 Direct Phone >>>>>>> +43 664 8866 1857 Mobile Phone >>>>>>> [email protected] >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sandy Ginoza <[email protected]> >>>>>>> Sent: Freitag, 17. Oktober 2025 18:01 >>>>>>> To: Mirja Kuehlewind <[email protected]> >>>>>>> Cc: Scheffenegger, Richard <[email protected]>; RFC >>>>>>> Editor <[email protected]>; Bob Briscoe <[email protected]>; >>>>>>> [email protected]; [email protected]; Michael Tuexen >>>>>>> <[email protected]>; Zaheduzzaman Sarker >>>>>>> <[email protected]>; auth48archive >>>>>>> <[email protected]> >>>>>>> Subject: Re: AUTH48: RFC-to-be 9768 <draft-ietf-tcpm-accurate-ecn-34> >>>>>>> for your review >>>>>>> >>>>>>> EXTERNAL EMAIL - USE CAUTION when clicking links or attachments >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Mirja, >>>>>>> >>>>>>> We updated the text per your preference for item 5. We will wait to >>>>>>> hear further regarding item 1, as we believe this is under discussion >>>>>>> with the authors. >>>>>>> >>>>>>> Thanks, >>>>>>> Sandy Ginoza >>>>>>> RFC Production Center >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Oct 13, 2025, at 7:28 AM, Mirja Kuehlewind (IETF) >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi again, >>>>>>>> >>>>>>>> Sorry, I’m still catching up on emails from my holidays end of >>>>>>>> September and saw just now that the discussion already moved on. >>>>>>>> >>>>>>>> Please see below. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 16. Sep 2025, at 00:06, Sandy Ginoza >>>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi Ricard, >>>>>>>>> >>>>>>>>> Please see notes below. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Sep 15, 2025, at 2:07 AM, Scheffenegger, Richard >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Re 1: >>>>>>>>>> >>>>>>>>>> I opt to have the "feedback" part a suffix, because adding feedback >>>>>>>>>> in "" marks then would necessitate this to be deployed throughout >>>>>>>>>> the documnent and i think it would start reading awkward. >>>>>>>>>> >>>>>>>>>> As the document really only ever touches the TCP based feedback, but >>>>>>>>>> not the overarching concept of ECN as a whole, I think mentioning it >>>>>>>>>> once in the definitions (outside the quotation marks) should suffice >>>>>>>>>> and makes the rest of the document more readable... >>>>>>>>>> >>>>>>>>> We have not made any changes here. While we typically use quotes to >>>>>>>>> specify the terms being introduced (e.g., this action is called >>>>>>>>> “abc”), another option would be to drop the quotes. >>>>>>>>> >>>>>>>> I’m a bit lost now. Where do people want to use or not use quotes? I >>>>>>>> agree that usually the word “feedback” shouldn’t be included in the >>>>>>>> quotes but if so we need to make it consent for both “AccECN feedback” >>>>>>>> and “Classic ECN feedback”. The problem is that “Classic ECN” consists >>>>>>>> of more than just the feedback part, therefore it is correct to define >>>>>>>> both “Classic ECN” and “Classic ECN feedback”. I think to be >>>>>>>> consistent we could then also use the term “AccECN feedback”. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Re 5 >>>>>>>>>> >>>>>>>>>> For me as non-native speaker, this now reads a bit awkward. Maybe: >>>>>>>>>> >>>>>>>>>> Setting the three flags (AE, CWR, ECE) to 1 to indicate AccECN >>>>>>>>>> support on the SYN has been carefully chosen to enable natural >>>>>>>>>> fall-back to prior stages in the evolution of ECN. >>>>>>>>>> >>>>>>>>>> (s/have/has/ -> was plural/ is singular now). >>>>>>>>>> >>>>>>>>> Good catch - the text now reads as follows: >>>>>>>>> >>>>>>>>> The three flags set to 1 indicate AccECN support on the SYN has been >>>>>>>>> carefully chosen to enable natural fall-back to prior stages in the >>>>>>>>> evolution of ECN. >>>>>>>>> >>>>>>>> See my previous mails. I think the sentence is more clear with the >>>>>>>> “to”. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Please note that we await input regarding the author comments in the >>>>>>>>> XML file. >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>>>> 38) <!-- [rfced] Some author comments are present in the XML. >>>>>>>>>>>>>>>> Please confirm >>>>>>>>>>>>>>>> that no updates related to these comments are outstanding. >>>>>>>>>>>>>>>> Note that the >>>>>>>>>>>>>>>> comments will be deleted prior to publication. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Richard and Bob would need to double-check this. >>>>>>>>>>>>>>> >>>>>>>> Richard confirmed to me by chat that we don’t need the comments >>>>>>>> anymore from his point of view. And as I said I just pinged Bob hoping >>>>>>>> we will hear from him soon. >>>>>>>> >>>>>>>> Mirja >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The current files are available here: >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.xml__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NooNo_Mo$ >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.txt__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NnSOHbdM$ >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.pdf__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6Nsw4rcHE$ >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6N4xvmu_U$ >>>>>>>>> >>>>>>>>> Diffs highlighting the last two rounds of updates: >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastdiff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NkHTxV5c$ >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastrfcdiff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NMlwcBmQ$ >>>>>>>>> (side by side) >>>>>>>>> >>>>>>>>> AUTH48 diffs: >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-auth48diff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NFFwjlTg$ >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-auth48rfcdiff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6N9BDUn1U$ >>>>>>>>> (side by side) >>>>>>>>> >>>>>>>>> Comprehensive diffs: >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-diff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NoOH8FJk$ >>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NlIk1ZVc$ >>>>>>>>> (side by side) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Sandy Ginoza >>>>>>>>> RFC Production Center >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Richard Scheffenegger >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Sandy Ginoza <[email protected]> >>>>>>>>>> Sent: Samstag, 13. September 2025 00:02 >>>>>>>>>> To: Mirja Kuehlewind <[email protected]> >>>>>>>>>> Cc: RFC Editor <[email protected]>; Bob Briscoe >>>>>>>>>> <[email protected]>; Scheffenegger, Richard >>>>>>>>>> <[email protected]>; [email protected]; >>>>>>>>>> [email protected]; Michael Tuexen <[email protected]>; >>>>>>>>>> Zaheduzzaman Sarker <[email protected]>; auth48archive >>>>>>>>>> <[email protected]> >>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9768 >>>>>>>>>> <draft-ietf-tcpm-accurate-ecn-34> for your review >>>>>>>>>> >>>>>>>>>> EXTERNAL EMAIL - USE CAUTION when clicking links or attachments >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Mirja, Bob, Richard, >>>>>>>>>> >>>>>>>>>> We made some updates to the document, but we await guidance >>>>>>>>>> regarding items 1 and 5 below. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1) Please review the the info below and let us know how you would >>>>>>>>>> like to proceed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> 1) There is an inconsistency now about these two sentences/terms: >>>>>>>>>>>> >>>>>>>>>>>> “It is called the more "Accurate ECN" feedback scheme, or AccECN >>>>>>>>>>>> for short.” >>>>>>>>>>>> >>>>>>>>>>>> "This document uses the term "Classic ECN feedback" when …” >>>>>>>>>>>> >>>>>>>>>>>> I think you either have to have the word “feedback” as part of >>>>>>>>>>>> both terms or none. >>>>>>>>>>>> >>>>>>>>>>>> So either: >>>>>>>>>>>> >>>>>>>>>>>> “It is called the more "Accurate ECN feedback" scheme, or AccECN >>>>>>>>>>>> feedback for short.” >>>>>>>>>>>> >>>>>>>>>>>> "This document uses the term "Classic ECN feedback" when …” >>>>>>>>>>>> >>>>>>>>>>>> or >>>>>>>>>>>> >>>>>>>>>>>> “It is called the more "Accurate ECN” scheme, or AccECN for short.” >>>>>>>>>>>> >>>>>>>>>>>> "This document uses the term "Classic ECN" when …” >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks for your thorough review. Regarding item 1, the doc defines >>>>>>>>>>> the following in section 1.3: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> AccECN: The more Accurate ECN feedback scheme will be called AccECN >>>>>>>>>>> for short. >>>>>>>>>>> >>>>>>>>>>> Classic ECN: The ECN protocol specified in [RFC3168]. >>>>>>>>>>> >>>>>>>>>>> Classic ECN feedback: The feedback aspect of the ECN protocol >>>>>>>>>>> specified in [RFC3168], including generation, encoding, >>>>>>>>>>> transmission and decoding of feedback, but not the Data Sender's >>>>>>>>>>> subsequent response to that feedback. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So perhaps we should be using “Classic ECN feedback” and “AccECN >>>>>>>>>>> feedback”, and the AccECN definition above should be updated to >>>>>>>>>>> refer to "AccECN feedback”? >>>>>>>>>>> >>>>>>>>>>> That is: >>>>>>>>>>> AccECN feedback: The more Accurate ECN feedback scheme will be >>>>>>>>>>> called AccECN feedback >>>>>>>>>>> for short. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 4) Note that we also made some updates to the lists (regarding >>>>>>>>>> semicolons vs periods). We re-reviewed the lists and think we better >>>>>>>>>> understand the original use of semicolons. We have restored them in >>>>>>>>>> some places. Please review and let us know if any further updates >>>>>>>>>> are needed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 4) Looking at this now I think I would prefer to use ; in list and >>>>>>>>>>> only . for the last list item. >>>>>>>>>>> I feel this was how it was done in most cases already. However, I’m >>>>>>>>>>> fine to go with whatever is most commonly done in RFCs. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 5) We have updated the text to read “set to 1 indicate” (deleted >>>>>>>>>> “to” after "1"). Please let us know if any corrections are needed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 5) I think adding the “are” in the first sentence in Section 3.1.2 >>>>>>>>>>> is wrong: >>>>>>>>>>> >>>>>>>>>>> The three flags are >>>>>>>>>>> set to 1 to indicate AccECN support on the SYN have been carefully >>>>>>>>>>> chosen… >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The current files are available here: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.xml__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsBS67iLA$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.txt__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsNYmlEU4$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.pdf__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsU4CYw3o$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvs4nlU7Ks$ >>>>>>>>>> >>>>>>>>>> Diffs highlighting the most recent updates: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastdiff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsBtrQqVY$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastrfcdiff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvse3nvsQQ$ >>>>>>>>>> (side by side) >>>>>>>>>> >>>>>>>>>> AUTH48 diffs: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-auth48diff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsXtdzoao$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-auth48rfcdiff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsmjLE6U8$ >>>>>>>>>> (side by side) >>>>>>>>>> >>>>>>>>>> Comprehensive diffs: >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-diff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvs6ny6L20$ >>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsEhb8T7I$ >>>>>>>>>> (side by side) >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Sandy Ginoza >>>>>>>>>> RFC Production Center >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Sandy Ginoza >>>>>>>>>>> RFC Production Center >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Sep 2, 2025, at 8:38 AM, Mirja Kuehlewind (IETF) >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Sandy, >>>>>>>>>>>> >>>>>>>>>>>> I now reviewed the whole document and I have a few minor things. >>>>>>>>>>>> >>>>>>>>>>>> 1) There is an inconsistency now about these two sentences/terms: >>>>>>>>>>>> >>>>>>>>>>>> “It is called the more "Accurate ECN" feedback scheme, or AccECN >>>>>>>>>>>> for short.” >>>>>>>>>>>> >>>>>>>>>>>> "This document uses the term "Classic ECN feedback" when …” >>>>>>>>>>>> >>>>>>>>>>>> I think you either have to have the word “feedback” as part of >>>>>>>>>>>> both terms or none. >>>>>>>>>>>> >>>>>>>>>>>> So either: >>>>>>>>>>>> >>>>>>>>>>>> “It is called the more "Accurate ECN feedback" scheme, or AccECN >>>>>>>>>>>> feedback for short.” >>>>>>>>>>>> >>>>>>>>>>>> "This document uses the term "Classic ECN feedback" when …” >>>>>>>>>>>> >>>>>>>>>>>> or >>>>>>>>>>>> >>>>>>>>>>>> “It is called the more "Accurate ECN” scheme, or AccECN for short.” >>>>>>>>>>>> >>>>>>>>>>>> "This document uses the term "Classic ECN" when …” >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2) I think you should use upper case letter here: >>>>>>>>>>>> >>>>>>>>>>>> OLD >>>>>>>>>>>> large receive offload (LRO) or generic receive offload (GRO) >>>>>>>>>>>> >>>>>>>>>>>> NEW >>>>>>>>>>>> Large Receive Offload (LRO) or Generic Receive Offload (GRO) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 3) Congestion Window Reduced (CWR) is introduced a second time in >>>>>>>>>>>> Section 2.3. This can be removed. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 4) Looking at this now I think I would prefer to use ; in list and >>>>>>>>>>>> only . for the last list item. >>>>>>>>>>>> I feel this was how it was done in most cases already. However, >>>>>>>>>>>> I’m fine to go with whatever is most commonly done in RFCs. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 5) I think adding the “are” in the first sentence in Section 3.1.2 >>>>>>>>>>>> is wrong: >>>>>>>>>>>> >>>>>>>>>>>> The three flags are >>>>>>>>>>>> set to 1 to indicate AccECN support on the SYN have been carefully >>>>>>>>>>>> chosen… >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 6) There is also a wrong word is in this sentence in section >>>>>>>>>>>> 3.2.2.1: >>>>>>>>>>>> >>>>>>>>>>>> If the final ACK of the handshake does not arrive before its >>>>>>>>>>>> retransmission timer expires, the TCP Server is follow the >>>>>>>>>>>> procedure given in Section 3.1.4.2. >>>>>>>>>>>> >>>>>>>>>>>> However, this is not meant to be a normative statement at this >>>>>>>>>>>> part of this document, so I would actually prefer a phrasing list >>>>>>>>>>>> this: >>>>>>>>>>>> >>>>>>>>>>>> If the final ACK of the handshake does not arrive before its >>>>>>>>>>>> retransmission timer expires, the procedure that the TCP Server >>>>>>>>>>>> will follow is given in Section 3.1.4.2. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Mirja >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 23. Aug 2025, at 00:05, Sandy Ginoza >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Mirja and Bob, >>>>>>>>>>>>> >>>>>>>>>>>>> This is a friendly reminder that we await your response to the >>>>>>>>>>>>> items noted below and whether any additional updates are needed. >>>>>>>>>>>>> We will wait to hear from you before continuing with publication. >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you, >>>>>>>>>>>>> Sandy Ginoza >>>>>>>>>>>>> RFC Production Center >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 15, 2025, at 11:11 AM, Sandy Ginoza >>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Mirja, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for your close review and the explanations provided. We >>>>>>>>>>>>>> have updated the document as described below. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We will wait to hear from Richard and/or Bob regarding this the >>>>>>>>>>>>>> author comments in the XML file. In addition, this question >>>>>>>>>>>>>> should have been included previously. Please let us know if any >>>>>>>>>>>>>> updates are desired. >>>>>>>>>>>>>> >>>>>>>>>>>>>> <!-- [rfced] Will "rights and obligations" be commonly understood >>>>>>>>>>>>>> in this context? We only see it used in RFC 3647, and it appears >>>>>>>>>>>>>> as part of quoted text there. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 3.1.1 original: >>>>>>>>>>>>>> Once in AccECN mode, a TCP Client or Server has the rights and >>>>>>>>>>>>>> obligations to participate in the ECN protocol defined in Section >>>>>>>>>>>>>> 3.1.5. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Section 3.1.5 original: >>>>>>>>>>>>>> An implementation that supports AccECN has the rights and >>>>>>>>>>>>>> obligations concerning the use of ECN defined below, which update >>>>>>>>>>>>>> those in Section 6.1.1 of [RFC3168]. >>>>>>>>>>>>>> --> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The current files are available here: >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>>>>>>>>>> 768.xml__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N >>>>>>>>>>>>>> 1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsBS67iLA$ >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>>>>>>>>>> 768.txt__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N >>>>>>>>>>>>>> 1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsNYmlEU4$ >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>>>>>>>>>> 768.pdf__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N >>>>>>>>>>>>>> 1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsU4CYw3o$ >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>>>>>>>>>> 768.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8 >>>>>>>>>>>>>> N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvs4nlU7Ks$ >>>>>>>>>>>>>> >>>>>>>>>>>>>> AUTH48 diffs: >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>>>>>>>>>> 768-auth48diff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1AL >>>>>>>>>>>>>> xCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsXtdzoao >>>>>>>>>>>>>> $ >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>>>>>>>>>> 768-auth48rfcdiff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE >>>>>>>>>>>>>> 1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsmjLE >>>>>>>>>>>>>> 6U8$ (side by side) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Comprehensive diffs: >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>>>>>>>>>> 768-diff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_Xg >>>>>>>>>>>>>> qHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvs6ny6L20$ >>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9 >>>>>>>>>>>>>> 768-rfcdiff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ >>>>>>>>>>>>>> _XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsEhb8T7I$ >>>>>>>>>>>>>> (side by side) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review and let us know if further updates are needed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you, >>>>>>>>>>>>>> Sandy Ginoza >>>>>>>>>>>>>> RFC Production Center >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 14, 2025, at 8:05 AM, Mirja Kuehlewind (IETF) >>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please see inline. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 12. Aug 2025, at 21:38, [email protected] wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Authors, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>>>>>>>>>> necessary) the following questions, which are also in the XML >>>>>>>>>>>>>>>> file. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) <!-- [rfced] Because these documents are defined in >>>>>>>>>>>>>>>> Informational RFCs, is "proposed" needed here? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx >>>>>>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [RFC9330] need to know when >>>>>>>>>>>>>>>> more than one marking is received in one RTT, which is >>>>>>>>>>>>>>>> information that cannot be provided by the feedback scheme as >>>>>>>>>>>>>>>> specified in [RFC3168]. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>> Newer mechanisms like Congestion Exposure (ConEx [RFC7713]), >>>>>>>>>>>>>>>> DCTCP [RFC8257], or L4S [RFC9330] ... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Or perhaps, "More recently defined mechanisms ..." >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I’d prefer "More recently defined”. I think that’s what was >>>>>>>>>>>>>>> meant here anyway; the comma seems wrong. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2) <!-- [rfced] We are having trouble parsing "extent of >>>>>>>>>>>>>>>> congestion notification". Perhaps this means "indicate the >>>>>>>>>>>>>>>> amount of congestion over the round trip"? Please clarify. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> Or, unlike Reno or >>>>>>>>>>>>>>>> CUBIC, AccECN can be used to respond to the extent of >>>>>>>>>>>>>>>> congestion >>>>>>>>>>>>>>>> notification over a round trip, as for example DCTCP does in >>>>>>>>>>>>>>>> controlled environments [RFC8257]. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NEW >>>>>>>>>>>>>>> Or, unlike as done by Reno or >>>>>>>>>>>>>>> CUBIC, AccECN can be used to respond to the actual number of >>>>>>>>>>>>>>> congestion Notifications received over a round trip, as for >>>>>>>>>>>>>>> example DCTCP does in controlled environments [RFC8257]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 3) <!-- [rfced] Because "Reserved combination" is not used >>>>>>>>>>>>>>>> much, >>>>>>>>>>>>>>>> would it help the reader to add a pointer - perhaps to table 2? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> All these requirements ensure that future uses of all the >>>>>>>>>>>>>>>> Reserved combinations on a SYN or SYN/ACK can rely on >>>>>>>>>>>>>>>> consistent >>>>>>>>>>>>>>>> behaviour from the installed base of AccECN implementations. >>>>>>>>>>>>>>>> See >>>>>>>>>>>>>>>> Appendix B.3 for related discussion. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, adding a point to the table is good. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 4) <!-- [rfced] Should a second closing parens appear after >>>>>>>>>>>>>>>> "congestion)"? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> Implementers MAY use other fall-back strategies if they are >>>>>>>>>>>>>>>> found >>>>>>>>>>>>>>>> to be more effective (e.g., attempting to negotiate AccECN on >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> SYN only once or more than twice (most appropriate during high >>>>>>>>>>>>>>>> levels of congestion). >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, please add another closing parens. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 5) <!-- [rfced] We are unsure what "try it without" refers to >>>>>>>>>>>>>>>> here. Is it "advisable to experiment without using the ECT on >>>>>>>>>>>>>>>> a SYN"? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original (sentence prior included for context): >>>>>>>>>>>>>>>> Further it might make sense to also remove any other new or >>>>>>>>>>>>>>>> experimental fields or options on the SYN in case a middlebox >>>>>>>>>>>>>>>> might be blocking them, although the required behaviour will >>>>>>>>>>>>>>>> depend on the specification of the other option(s) and any >>>>>>>>>>>>>>>> attempt to co-ordinate fall-back between different modules of >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> stack. For instance, even if taking part in an [RFC8311] >>>>>>>>>>>>>>>> experiment that allows ECT on a SYN, it would be advisable to >>>>>>>>>>>>>>>> try it without. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NEW >>>>>>>>>>>>>>> For instance, >>>>>>>>>>>>>>> if taking part in an [RFC8311] experiment that allows ECT on a >>>>>>>>>>>>>>> SYN, it would be advisable to have a fall-back strategy that >>>>>>>>>>>>>>> tries >>>>>>>>>>>>>>> use of AccECN without setting ETC on SYN. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 6) <!-- [rfced] Throughout, some of the bulleted lists use a >>>>>>>>>>>>>>>> mix >>>>>>>>>>>>>>>> of periods and semicolons to close the item - some within the >>>>>>>>>>>>>>>> same list. Please consider whether these may be updated for >>>>>>>>>>>>>>>> consistency. We recommend using terminating periods, unless >>>>>>>>>>>>>>>> the goal is to clarify an "and" or "or" connection between the >>>>>>>>>>>>>>>> list items. >>>>>>>>>>>>>>>> Please review. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, this should be unified. I’d be okay with terminating >>>>>>>>>>>>>>> periods. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 7) <!-- [rfced] For clarity, we'd like to add quotes to >>>>>>>>>>>>>>>> "handshake encoding". >>>>>>>>>>>>>>>> Please confirm this is correct, as opposed to "handshake >>>>>>>>>>>>>>>> encoding >>>>>>>>>>>>>>>> of the ACE field". >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> This shall be called the handshake encoding of the ACE field, >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> it is the only exception to the rule that the ACE field carries >>>>>>>>>>>>>>>> the 3 least significant bits of the r.cep counter on packets >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> SYN=0. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, this should be only "handshake encoding”. However, I’m not >>>>>>>>>>>>>>> sure if the quotes are really needed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 8) <!-- [rfced] For readability, may we break this text into >>>>>>>>>>>>>>>> two sentences? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> When an AccECN Server in SYN-RCVD state receives a pure ACK >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> SYN=0 and no SACK blocks, instead of treating the ACE field as >>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>> counter, it MUST infer the meaning of each possible value of >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> ACE field from Table 4, which also shows the value that an >>>>>>>>>>>>>>>> AccECN >>>>>>>>>>>>>>>> Server MUST set s.cep to as a result. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>> When an AccECN Server in SYN-RCVD state receives a pure ACK >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> SYN=0 and no SACK blocks, it MUST infer the meaning of each >>>>>>>>>>>>>>>> possible value of the ACE field from Table 4 instead of >>>>>>>>>>>>>>>> treating >>>>>>>>>>>>>>>> the ACE field as a counter. Table 4 also shows the value to >>>>>>>>>>>>>>>> which an AccECN Server MUST set s.cep as a result. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Given these are two normative statement let’s rather do it this >>>>>>>>>>>>>>> way: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NEW >>>>>>>>>>>>>>> When an AccECN Server in SYN-RCVD state receives a pure ACK with >>>>>>>>>>>>>>> SYN=0 and no SACK blocks, it MUST infer the meaning of each >>>>>>>>>>>>>>> possible value of the ACE field from Table 4 instead of treating >>>>>>>>>>>>>>> the ACE field as a counter. As a result, an AccECN Server MUST >>>>>>>>>>>>>>> set >>>>>>>>>>>>>>> s.cep to the respective value also shown in Table 4. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 9) <!-- [rfced] We are unclear what "it" refers to in the >>>>>>>>>>>>>>>> following. Perhaps "it" >>>>>>>>>>>>>>>> can be deleted? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> Given this encoding of the ACE field on the ACK of a SYN/ACK is >>>>>>>>>>>>>>>> exceptional, an AccECN Server using large receive offload (LRO) >>>>>>>>>>>>>>>> might prefer to disable LRO until such an ACK has transitioned >>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>> out of SYN-RCVD state. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No it is not correct to remove the “it". “It” is the server. A >>>>>>>>>>>>>>> longer version of the text would be: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Given this encoding of the ACE field on the ACK of a SYN/ACK is >>>>>>>>>>>>>>> exceptional, an AccECN Server using large receive offload (LRO) >>>>>>>>>>>>>>> might prefer to disable LRO until the ACK of the SYN/ACK was >>>>>>>>>>>>>>> sent >>>>>>>>>>>>>>> and it has transitioned out of SYN-RCVD state. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 10) <!-- [rfced] We converted the notes following Table 4 into >>>>>>>>>>>>>>>> a list for clarity. >>>>>>>>>>>>>>>> Please let us know if you have any concerns. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That’s okay. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 11) <!-- [rfced] We are having trouble parsing "depend on >>>>>>>>>>>>>>>> experience of the most likely scenarios". Does it depend on how >>>>>>>>>>>>>>>> good the experience is, the outcome, etc? Please consider >>>>>>>>>>>>>>>> whether this text can be clarified. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> This advice is not stated normatively (in capitals), because >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> best strategy might depend on experience of the most likely >>>>>>>>>>>>>>>> scenarios, which can only be known at the time of deployment. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think we can do the following: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NEW >>>>>>>>>>>>>>> This advice is not stated normatively (in capitals), because the >>>>>>>>>>>>>>> best strategy might depend on the likelihood to experience these >>>>>>>>>>>>>>> scenarios, which can only be known at the time of deployment. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 12) <!-- [rfced] Where is "below these bullets", as we don't >>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>> a bulletized list in Section 3.2.2.5.1? If possible, we >>>>>>>>>>>>>>>> recommend adding a pointer for clarity. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> Even though this rule is stated as a "SHOULD", it is important >>>>>>>>>>>>>>>> for a transition to trigger an ACK if at all possible, The only >>>>>>>>>>>>>>>> valid exception to this rule is given below these bullets. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Maybe let’s do it that way: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NEW >>>>>>>>>>>>>>> Even though this rule is stated as a "SHOULD", it is important >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> a transition to trigger an ACK if at all possible, The only >>>>>>>>>>>>>>> valid >>>>>>>>>>>>>>> exception to this rule is due to large receive offload (LRO) or >>>>>>>>>>>>>>> generic receive offload (GRO) as further described below. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 13) <!-- [rfced] For ease of the reader, we suggest adding a >>>>>>>>>>>>>>>> pointer to the examples. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> Recommended Simple Scheme: The Data Receiver SHOULD include an >>>>>>>>>>>>>>>> AccECN TCP Option on every scheduled ACK if any byte counter >>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>> incremented since the last ACK. Whenever possible, it SHOULD >>>>>>>>>>>>>>>> include a field for every byte counter that has changed at some >>>>>>>>>>>>>>>> time during the connection (see examples later). >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It’s just in the text later in the same section. Not sure how >>>>>>>>>>>>>>> to adda pointer here. I also don’t think this is needed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 14) <!-- [rfced] Mention of BCP 69 was removed to the HTML and >>>>>>>>>>>>>>>> PDF could link directly to Section 5.2.1 of RFC 3449. Would you >>>>>>>>>>>>>>>> prefer that BCP 69 be included as the cite tag? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> Section 5.2.1 of BCP 69 [RFC3449] gives best current practice >>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>> filtering (aka. thinning or coalescing) of pure TCP ACKs. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>> Section 5.2.1 of RFC 3449 [BCP69] gives best current practice >>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>> filtering (aka thinning or coalescing) of pure TCP ACKs. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please aline this with whatever the normal practice is supposed >>>>>>>>>>>>>>> to be now. I don’t have a real opinion here. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 15) <!-- [rfced] Does "even if it is" refer to using AccECN >>>>>>>>>>>>>>>> without ECN++ or with >>>>>>>>>>>>>>>> ECN++? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> However, it might omit some AccECN ACKs, because AccECN can be >>>>>>>>>>>>>>>> used without ECN++ and even if it is, ECN++ does not have to >>>>>>>>>>>>>>>> make pure ACKs ECN-capable - only deployment experience will >>>>>>>>>>>>>>>> tell. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>> However, it might omit some AccECN ACKs because AccECN can be >>>>>>>>>>>>>>>> used without ECN++. Even if ECN++ is used, it does not have to >>>>>>>>>>>>>>>> make pure ACKs ECN-capable - only deployment experience will >>>>>>>>>>>>>>>> tell. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If we split up in two sentences, I this this would be maybe >>>>>>>>>>>>>>> better: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, it might omit some AccECN ACKs because AccECN can be >>>>>>>>>>>>>>> used >>>>>>>>>>>>>>> without ECN++. Even if ECN++ is used, pure ACKs do not >>>>>>>>>>>>>>> necessarily have to be marked as ECN-capable - only deployment >>>>>>>>>>>>>>> experience will tell. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 16) <!-- [rfced] Instead of using [RFC3168] as an adjective, >>>>>>>>>>>>>>>> may >>>>>>>>>>>>>>>> we update this text to refer to "Classic ECN"? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> One way around this could be to only negotiate for Accurate >>>>>>>>>>>>>>>> ECN, >>>>>>>>>>>>>>>> but not offer a fall back to [RFC3168] ECN. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>> One way around this could be to only negotiate for Accurate >>>>>>>>>>>>>>>> ECN, >>>>>>>>>>>>>>>> but not offer a fall back to Classic ECN [RFC3168]. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> For LRO in the receive direction, a different issue may get >>>>>>>>>>>>>>>> exposed with [RFC3168] ECN supporting hardware. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>> For LRO in the receive direction, a different issue may get >>>>>>>>>>>>>>>> exposed with Classic-ECN [RFC3168] supporting hardware. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, please. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 17) <!-- [rfced] Throughout: We have removed the section titles >>>>>>>>>>>>>>>> and linked the section numbers directly to the section of the >>>>>>>>>>>>>>>> RFC >>>>>>>>>>>>>>>> specified. For example, the text has been updated as follows: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> * The whole of "6.1.1 TCP Initialization" of [RFC3168] is >>>>>>>>>>>>>>>> updated by Section 3.1 of the present specification. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Current: >>>>>>>>>>>>>>>> * The whole of Section 6.1.1 of [RFC3168] is updated by Section >>>>>>>>>>>>>>>> 3.1 of the present specification. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In the HTML and PDF files, "Section 6.1.1 links to Section >>>>>>>>>>>>>>>> 6.1.1 of RFC 3168. >>>>>>>>>>>>>>>> Please review and let us know if you prefer the section titles >>>>>>>>>>>>>>>> be included. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is fine. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 18) <!-- [rfced] We are unclear why "potentially updates" is >>>>>>>>>>>>>>>> mentioned here. Is it mentioned to cover implementations of RFC >>>>>>>>>>>>>>>> 3168 have not been updated yet and/or potential future >>>>>>>>>>>>>>>> updates? Otherwise, may it be cut? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> It will be noted that RFC 8311 already updates, or potentially >>>>>>>>>>>>>>>> updates, a number of the requirements in "6.1.2. The TCP >>>>>>>>>>>>>>>> Sender". >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> RFC8311 says in some parts that it explicitly doesn’t update >>>>>>>>>>>>>>> RFC3168 because a new experimental RFC should do that instead >>>>>>>>>>>>>>> but it provided the “legitimacy" to update… this is a weird >>>>>>>>>>>>>>> thing anyway but I agree that probably saying “potentially >>>>>>>>>>>>>>> updates” doesn’t help either. I’d be okay to simply remove that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 19) <!-- [rfced] As we believe "pressure" refers to options >>>>>>>>>>>>>>>> vying >>>>>>>>>>>>>>>> for limited space, perhaps this update would be more clear? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> When option space is under pressure from other options, Section >>>>>>>>>>>>>>>> 3.2.3.3 provides guidance on how important it is to send an >>>>>>>>>>>>>>>> AccECN Option relative to other options, and which fields are >>>>>>>>>>>>>>>> more important to include. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>> Because option space is limited, Section 3.2.3.3 provides >>>>>>>>>>>>>>>> guidance on how important it is to send an AccECN Option >>>>>>>>>>>>>>>> relative >>>>>>>>>>>>>>>> to other options and specifies which fields are more important >>>>>>>>>>>>>>>> to include. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Okay for me. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 20) <!-- [rfced] Please confirm "experimental" is correct here. >>>>>>>>>>>>>>>> We ask because RFC 7713 is an Informational RFC. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> ConEx is an experimental change to the Data Sender that would >>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>> most useful when combined with AccECN. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, rfc7731 in informational but that's only explains the >>>>>>>>>>>>>>> architecture. But the protocol documents RFC7837 and RFC7786 >>>>>>>>>>>>>>> are experimental. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 21) <!-- [rfced] We have updated the registry title per the >>>>>>>>>>>>>>>> note >>>>>>>>>>>>>>>> below from IANA. While draft-ietf-tsvwg-udp-options has not yet >>>>>>>>>>>>>>>> been published, this title matches what currently appears on >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> IANA site. Please let us know any concerns. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> NOTE: The name of the registry called "TCP Experimental Option >>>>>>>>>>>>>>>> Experiment Identifiers (TCP ExIDs)" in the IANA Considerations >>>>>>>>>>>>>>>> section has been changed to "TCP/UDP Experimental Option >>>>>>>>>>>>>>>> Experiment Identifiers (TCP/UDP ExIDs)," per >>>>>>>>>>>>>>>> draft-ietf-tsvwg-udp-options-45. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> Early experimental implementations of the two AccECN Options >>>>>>>>>>>>>>>> used >>>>>>>>>>>>>>>> experimental option 254 per [RFC6994] with the 16-bit magic >>>>>>>>>>>>>>>> numbers >>>>>>>>>>>>>>>> 0xACC0 and 0xACC1 respectively for Order 0 and 1, as allocated >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> the IANA "TCP Experimental Option Experiment Identifiers (TCP >>>>>>>>>>>>>>>> ExIDs)" >>>>>>>>>>>>>>>> registry. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, thanks! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 22) <!-- [rfced] Please consider whether the placement of B at >>>>>>>>>>>>>>>> the end of the sentence is correct. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> This opens up a potential covert channel of up to 29B (40 - >>>>>>>>>>>>>>>> (2+3*3)) B. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, please remove the last B >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 23) <!-- [rfced] This sentence reads a bit awkwardly. Perhaps >>>>>>>>>>>>>>>> this can be rephrased? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> No known way can yet be contrived for a receiver to take >>>>>>>>>>>>>>>> advantage of this behaviour, which seems to always degrade its >>>>>>>>>>>>>>>> own performance. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>> Currently, there is no known way for a receiver to take >>>>>>>>>>>>>>>> advantage >>>>>>>>>>>>>>>> of this behaviour, which seems to always degrade its own >>>>>>>>>>>>>>>> performance. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, thanks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 24) <!-- [rfced] Instead of "show up more easily", perhaps "be >>>>>>>>>>>>>>>> more easily identified" would improve readability? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> A generic privacy concern of any new protocol is that for a >>>>>>>>>>>>>>>> while >>>>>>>>>>>>>>>> it will be used by a small population of hosts, and thus show >>>>>>>>>>>>>>>> up >>>>>>>>>>>>>>>> more easily. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Maybe: >>>>>>>>>>>>>>> A generic privacy concern of any new protocol is that for a >>>>>>>>>>>>>>> while >>>>>>>>>>>>>>> it will be used by a small population of hosts, and thus those >>>>>>>>>>>>>>> hosts could be more easily identified. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 25) <!-- [rfced] We have updated the text as shown below. >>>>>>>>>>>>>>>> Please >>>>>>>>>>>>>>>> let us know any concerns. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> However, it is expected that this option will become available >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> operating systems over time, and eventually turned on by >>>>>>>>>>>>>>>> default >>>>>>>>>>>>>>>> in them. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Current: >>>>>>>>>>>>>>>> However, it is expected that AccECN will become available in >>>>>>>>>>>>>>>> operating systems over time and that it will eventually be >>>>>>>>>>>>>>>> turned >>>>>>>>>>>>>>>> on by default. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 26) <!-- [rfced] [RoCEv2] >>>>>>>>>>>>>>>> Please review. We could not confirm the Volume or Release >>>>>>>>>>>>>>>> number >>>>>>>>>>>>>>>> for this reference. Note that there is information at the >>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>> URL which mentions "Volume 1 Release 1.8" (see: >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.infinibandta.org/wp-content/uploads/2024/09/IBTA-Overview-of-IBTA-Volume-1-Release-1.8.pdf__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvs2LQeOvU$ >>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Would you like us to update this reference to Release 1.8, use >>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>> version-less reference, or keep the Release 1.4 version of the >>>>>>>>>>>>>>>> reference? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Current: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture >>>>>>>>>>>>>>>> Specification", Volume 1, Release 1.4, 2020, >>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.infinibandta.org/ibta-specification/__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsUPWHlV0$ >>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture >>>>>>>>>>>>>>>> Specification", >>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.infinibandta.org/ibta-specification/__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsUPWHlV0$ >>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> OR >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture >>>>>>>>>>>>>>>> Specification", Volume 1, Release 1.8, July 2024, >>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.infinibandta.org/ibta-specification/__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsUPWHlV0$ >>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please use the version-less reference. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 27) <!-- [rfced] May we update "implement" to "satisfy" to >>>>>>>>>>>>>>>> clarify the text and avoid "implementers implement"? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> However, implementers are free to choose other ways to >>>>>>>>>>>>>>>> implement >>>>>>>>>>>>>>>> the requirements. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Okay. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 28) <!-- [rfced] The following note was included in the XML. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ToDo: Note to RFC Editor: Pls change all bare <artwork> >>>>>>>>>>>>>>>> elements >>>>>>>>>>>>>>>> (without any keywords like align) to <sourcecode>. >>>>>>>>>>>>>>>> Reason My XML editor doesn't support the <sourcecode> element, >>>>>>>>>>>>>>>> so >>>>>>>>>>>>>>>> it mangles line breaks within sourcecode, ignoring even CDATA >>>>>>>>>>>>>>>> protection. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We have updated the XML file as noted. Please let us know >>>>>>>>>>>>>>>> how/if he "type" >>>>>>>>>>>>>>>> attribute of each sourcecode element should be set. Perhaps >>>>>>>>>>>>>>>> some/all should be marked as pseudocode? >>>>>>>>>>>>>>>> If the current list of preferred values for "type" >>>>>>>>>>>>>>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/ >>>>>>>>>>>>>>>> doku.php?id=sourcecode-types__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvs2ag7Uq0$ >>>>>>>>>>>>>>>> ) does not contain an applicable type, then feel free to let >>>>>>>>>>>>>>>> us know. >>>>>>>>>>>>>>>> Also, it is acceptable to leave the "type" attribute not set. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, I think pseudocode should be fine for all artwork in the >>>>>>>>>>>>>>> appendix. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 29) <!-- [rfced] We are having trouble parsing this sentence. >>>>>>>>>>>>>>>> Where does the "which" statement end - after "full-sized"? >>>>>>>>>>>>>>>> Does "it" refer to the algorithm? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> However, we shall start >>>>>>>>>>>>>>>> with the simplest algorithm, which assumes segments are all >>>>>>>>>>>>>>>> full- >>>>>>>>>>>>>>>> sized and ultra-conservatively it assumes that ECN marking was >>>>>>>>>>>>>>>> 100% on the forward path when ACKs on the reverse path started >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> all be dropped. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes and yes. Which ends after “full-sized” and it is the >>>>>>>>>>>>>>> algorithm. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 30) <!-- [rfced] May we change "works out" to "indicates" or >>>>>>>>>>>>>>>> "determines"? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> The above formula works out that it would still be safe to >>>>>>>>>>>>>>>> assume >>>>>>>>>>>>>>>> 2 CE marks (because 9 - ((9-2) % 8) = 2). >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> “indicates” is fine. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 31) <!-- [rfced] Does "5% of full-sized" mean segments are "5% >>>>>>>>>>>>>>>> of their full >>>>>>>>>>>>>>>> size"? May we change "as long as" to "while" for readability? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> The simple algorithm for dSafer.cep above requires no >>>>>>>>>>>>>>>> monitoring of >>>>>>>>>>>>>>>> prevailing conditions and it would still be safe if, for >>>>>>>>>>>>>>>> example, >>>>>>>>>>>>>>>> segments were on average at least 5% of full-sized as long as >>>>>>>>>>>>>>>> ECN >>>>>>>>>>>>>>>> marking was 5% or less. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Not of “their” full-size but 5% of a full-sized packet. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 32) <!-- [rfced] We updated the text to point directly to >>>>>>>>>>>>>>>> Section 3.2.2.5.2 >>>>>>>>>>>>>>>> (where the quoted text appears). Please let us know any >>>>>>>>>>>>>>>> concerns. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> If missing acknowledgement numbers arrive later (due to >>>>>>>>>>>>>>>> reordering), >>>>>>>>>>>>>>>> Section 3.2.2.5 says "the Data Sender MAY attempt to >>>>>>>>>>>>>>>> neutralize the >>>>>>>>>>>>>>>> effect of any action it took based on a conservative >>>>>>>>>>>>>>>> assumption that >>>>>>>>>>>>>>>> it later found to be incorrect". >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Okay. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 33) <!-- [rfced] We are having trouble parsing "will consider >>>>>>>>>>>>>>>> d.cep can replace". >>>>>>>>>>>>>>>> Please clarify. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> The chart below shows when the above algorithm will consider >>>>>>>>>>>>>>>> d.cep >>>>>>>>>>>>>>>> can replace dSafer.cep as a safe enough estimate of the number >>>>>>>>>>>>>>>> of CE- >>>>>>>>>>>>>>>> marked packets: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>>>>> The chart below shows when the above algorithm will consider >>>>>>>>>>>>>>>> the number >>>>>>>>>>>>>>>> of CE-marked packets as a safe enough estimate to replace >>>>>>>>>>>>>>>> dsafer.cep >>>>>>>>>>>>>>>> with d.cep. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think this should have been: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NEW >>>>>>>>>>>>>>> The chart below shows when the above algorithm will consider >>>>>>>>>>>>>>> that d.cep >>>>>>>>>>>>>>> can replace dSafer.cep as a safe enough estimate of the number >>>>>>>>>>>>>>> of CE >>>>>>>>>>>>>>> marked packets: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Or this might be more clear (?): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NEW >>>>>>>>>>>>>>> The chart below shows when the above algorithm will consider >>>>>>>>>>>>>>> d.cep as a safe enough estimate of the number of CE >>>>>>>>>>>>>>> marked packets and replace dSafer.cep with it: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Or I guess we can simplify a bit and remove the word consider: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NEW >>>>>>>>>>>>>>> The chart below shows when the above algorithm will >>>>>>>>>>>>>>> replace dSafer.cep with d.cep as a safe enough estimate of the >>>>>>>>>>>>>>> number of CE >>>>>>>>>>>>>>> marked packets: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 34) <!-- [rfced] To what does "this" refer - the ACK? The >>>>>>>>>>>>>>>> sentence prior is >>>>>>>>>>>>>>>> included for context. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> If AccECN Options are not available, the Data Sender can only >>>>>>>>>>>>>>>> decode >>>>>>>>>>>>>>>> CE-marking from the ACE field in packets. Every time an ACK >>>>>>>>>>>>>>>> arrives, >>>>>>>>>>>>>>>> to convert this into an estimate of CE-marked bytes, it needs >>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>> average of the segment size, s_ave. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> convert the number of CE markings into an estimated CE-marked >>>>>>>>>>>>>>> bytes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 35) <!-- [rfced] Does "earlier versions" refer to earlier >>>>>>>>>>>>>>>> draft versions of this >>>>>>>>>>>>>>>> document? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Original: >>>>>>>>>>>>>>>> This development consumed the remaining 2 codepoints >>>>>>>>>>>>>>>> on the SYN/ACK that had been reserved for future use by AccECN >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> earlier versions. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes earlier version of the protocol defined in earlier versions >>>>>>>>>>>>>>> of this document. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 36) <!-- [rfced] Please review the following >>>>>>>>>>>>>>>> terminology-related questions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A) We updated the following to the form on the right. Please >>>>>>>>>>>>>>>> let us know if any >>>>>>>>>>>>>>>> corrections are needed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> not-ECT vs Not-ECT >>>>>>>>>>>>>>>> no ECN vs No ECN >>>>>>>>>>>>>>>> ECN Nonce vs ECN-Nonce vs ECN nonce (to match RFC 3540) >>>>>>>>>>>>>>>> Cubic vs CUBIC (to match RFC 9438) >>>>>>>>>>>>>>>> IP ECN field vs IP-ECN field >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think this should be IP ECN field. It’s also TCP ECN flag. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ECN capable vs ECN-capable (to match RFC 3168, though we >>>>>>>>>>>>>>>> wonder if it should be open (ECN capable) when not acting as >>>>>>>>>>>>>>>> an adjective appearing before then noun. >>>>>>>>>>>>>>>> time-out vs timeout >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> CE mark* vs CE-mark* - updated to use the hyphen when acting >>>>>>>>>>>>>>>> as an adjective >>>>>>>>>>>>>>>> appearing before the noun >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> B) Please review occurrences of the terms below and let us >>>>>>>>>>>>>>>> know if/how they may >>>>>>>>>>>>>>>> be made consistent. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TCP Option vs TCP option (perhaps TCP Option when referring to >>>>>>>>>>>>>>>> a specific option?) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TCP Option aligns with RFC9293. I would use that everywhere. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Established state vs established state vs ESTABLISHED state >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, let’s aways use ESTABLISHED state as in RFC9293. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> half connection vs half-connection >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Let's go for half-connection. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> C) We note that "time-stamp" is used consistently. However, >>>>>>>>>>>>>>>> RFC 7323 uses "timestamp". May we update the text for >>>>>>>>>>>>>>>> consistency? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, please use timestamp. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 37) <!-- [rfced] Please review whether any of the notes in >>>>>>>>>>>>>>>> this document >>>>>>>>>>>>>>>> should be in the <aside> element. It is defined as "a >>>>>>>>>>>>>>>> container for >>>>>>>>>>>>>>>> content that is semantically less important or tangential to >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> content that surrounds it" >>>>>>>>>>>>>>>> (https://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsnpJFfQI$ >>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You mean everything that starts with “Note.”? Would that be >>>>>>>>>>>>>>> different displayed? I think I would prefer to not display it >>>>>>>>>>>>>>> differently than other text. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 38) <!-- [rfced] Some author comments are present in the XML. >>>>>>>>>>>>>>>> Please confirm >>>>>>>>>>>>>>>> that no updates related to these comments are outstanding. >>>>>>>>>>>>>>>> Note that the >>>>>>>>>>>>>>>> comments will be deleted prior to publication. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Richard and Bob would need to double-check this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 39) <!-- [rfced] Please review the "Inclusive Language" >>>>>>>>>>>>>>>> portion of the online >>>>>>>>>>>>>>>> Style Guide >>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsWYz5Npc$ >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> and let us know if any changes are needed. Updates of this >>>>>>>>>>>>>>>> nature typically >>>>>>>>>>>>>>>> result in more precise language, which is helpful for readers. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Note that our script did not flag any words in particular, but >>>>>>>>>>>>>>>> this should >>>>>>>>>>>>>>>> still be reviewed as a best practice. >>>>>>>>>>>>>>>> --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> Mirja >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thank you. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> RFC Editor >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Aug 12, 2025, at 12:31 PM, [email protected] wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *****IMPORTANT***** >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Updated 2025/08/12 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> RFC Author(s): >>>>>>>>>>>>>>>> -------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Instructions for Completing AUTH48 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Your document has now entered AUTH48. Once it has been >>>>>>>>>>>>>>>> reviewed and >>>>>>>>>>>>>>>> approved by you and all coauthors, it will be published as an >>>>>>>>>>>>>>>> RFC. >>>>>>>>>>>>>>>> If an author is no longer available, there are several remedies >>>>>>>>>>>>>>>> available as listed in the FAQ >>>>>>>>>>>>>>>> (https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsR9Far3E$ >>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You and you coauthors are responsible for engaging other >>>>>>>>>>>>>>>> parties >>>>>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before >>>>>>>>>>>>>>>> providing >>>>>>>>>>>>>>>> your approval. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Planning your review >>>>>>>>>>>>>>>> --------------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review the following aspects of your document: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * RFC Editor questions >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review and resolve any questions raised by the RFC >>>>>>>>>>>>>>>> Editor >>>>>>>>>>>>>>>> that have been included in the XML file as comments marked as >>>>>>>>>>>>>>>> follows: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <!-- [rfced] ... --> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> These questions will also be sent in a subsequent email. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Changes submitted by coauthors >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please ensure that you review any changes submitted by your >>>>>>>>>>>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>>>>>>>>>>> agree to changes submitted by your coauthors. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Content >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review the full content of the document, as this cannot >>>>>>>>>>>>>>>> change once the RFC is published. Please pay particular >>>>>>>>>>>>>>>> attention to: >>>>>>>>>>>>>>>> - IANA considerations updates (if applicable) >>>>>>>>>>>>>>>> - contact information >>>>>>>>>>>>>>>> - references >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Copyright notices and legends >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review the copyright notice and legends as defined in >>>>>>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>>>>>>>>>>> (TLP – >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvs_yrE8tU$ >>>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Semantic markup >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review the markup in the XML file to ensure that >>>>>>>>>>>>>>>> elements of >>>>>>>>>>>>>>>> content are correctly tagged. For example, ensure that >>>>>>>>>>>>>>>> <sourcecode> >>>>>>>>>>>>>>>> and <artwork> are set correctly. See details at >>>>>>>>>>>>>>>> <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsamdaZN8$ >>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Formatted output >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>>>>>>>>>>> formatted output, as generated from the markup in the XML >>>>>>>>>>>>>>>> file, is >>>>>>>>>>>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>>>>>>>>>>> limitations compared to the PDF and HTML. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Submitting changes >>>>>>>>>>>>>>>> ------------------ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY >>>>>>>>>>>>>>>> ALL’ as all >>>>>>>>>>>>>>>> the parties CCed on this message need to see your changes. The >>>>>>>>>>>>>>>> parties >>>>>>>>>>>>>>>> include: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * your coauthors >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * [email protected] (the RPC team) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * other document participants, depending on the stream (e.g., >>>>>>>>>>>>>>>> IETF Stream participants are your working group chairs, the >>>>>>>>>>>>>>>> responsible ADs, and the document shepherd). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * [email protected], which is a new archival >>>>>>>>>>>>>>>> mailing list >>>>>>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active >>>>>>>>>>>>>>>> discussion >>>>>>>>>>>>>>>> list: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * More info: >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsxrEMsgA$ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * The archive itself: >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvs6-oR2-8$ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt >>>>>>>>>>>>>>>> out >>>>>>>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive >>>>>>>>>>>>>>>> matter). >>>>>>>>>>>>>>>> If needed, please add a note at the top of the message that you >>>>>>>>>>>>>>>> have dropped the address. When the discussion is concluded, >>>>>>>>>>>>>>>> [email protected] will be re-added to the CC list >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> its addition will be noted at the top of the message. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You may submit your changes in one of two ways: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> An update to the provided XML file >>>>>>>>>>>>>>>> — OR — >>>>>>>>>>>>>>>> An explicit list of changes in this format >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Section # (or indicate Global) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> OLD: >>>>>>>>>>>>>>>> old text >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> NEW: >>>>>>>>>>>>>>>> new text >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You do not need to reply with both an updated XML file and an >>>>>>>>>>>>>>>> explicit >>>>>>>>>>>>>>>> list of changes, as either form is sufficient. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We will ask a stream manager to review and approve any changes >>>>>>>>>>>>>>>> that seem >>>>>>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text, >>>>>>>>>>>>>>>> deletion of text, >>>>>>>>>>>>>>>> and technical changes. Information about stream managers can >>>>>>>>>>>>>>>> be found in >>>>>>>>>>>>>>>> the FAQ. Editorial changes do not require approval from a >>>>>>>>>>>>>>>> stream manager. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Approving for publication >>>>>>>>>>>>>>>> -------------------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To approve your RFC for publication, please reply to this >>>>>>>>>>>>>>>> email stating >>>>>>>>>>>>>>>> that you approve this RFC for publication. Please use ‘REPLY >>>>>>>>>>>>>>>> ALL’, >>>>>>>>>>>>>>>> as all the parties CCed on this message need to see your >>>>>>>>>>>>>>>> approval. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Files >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The files are available here: >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.xml__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsBS67iLA$ >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvs4nlU7Ks$ >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.pdf__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsU4CYw3o$ >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.txt__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsNYmlEU4$ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Diff file of the text: >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-diff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvs6ny6L20$ >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsEhb8T7I$ >>>>>>>>>>>>>>>> (side by side) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Diff of the XML: >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-xmldiff1.html__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvsYeyyjhI$ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Tracking progress >>>>>>>>>>>>>>>> ----------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9768__;!!Nhn8V6BzJA!XwUmEkpehjDoArabCpWTxDxlaoZVE1ALxCQ_XgqHW_8N1kURRf_rjobYVJ4s33CBHpn234Ix73JBwJJOXOfgstaqjFvs0AcBGiQ$ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thank you for your cooperation, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> RFC Editor >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>>>>>> RFC 9768 (draft-ietf-tcpm-accurate-ecn-34) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Title : More Accurate Explicit Congestion Notification >>>>>>>>>>>>>>>> (AccECN) Feedback in TCP >>>>>>>>>>>>>>>> Author(s) : B. Briscoe, M. Kühlewind, R. Scheffenegger >>>>>>>>>>>>>>>> WG Chair(s) : Yoshifumi Nishida, Michael Tüxen >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Area Director(s) : Gorry Fairhurst, Mike Bishop >>>>>>>>>>>>>>>> >>>>>> >>>>>> >>>>> >>>> >> > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
