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