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