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]
