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 >> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
