Greetings, This is a reminder to please review the followup discussion below and let us know how you would like to proceed.
Thank you, Sandy Ginoza RFC Production Center > On Sep 26, 2025, at 8:27 AM, Sandy Ginoza <[email protected]> > wrote: > > Greetings all, > > We do not believe we have heard further from you regarding the items below. > Please review and let us know how you’d like to proceed. > > The current files are here: > https://www.rfc-editor.org/authors/rfc9768.txt > https://www.rfc-editor.org/authors/rfc9768.pdf > https://www.rfc-editor.org/authors/rfc9768.html > https://www.rfc-editor.org/authors/rfc9768.xml > > Diffs highlighting the last two rounds of updates: > https://www.rfc-editor.org/authors/rfc9768-lastdiff.html > https://www.rfc-editor.org/authors/rfc9768-lastrfcdiff.html (side by side) > > AUTH48 diffs: > https://www.rfc-editor.org/authors/rfc9768-auth48diff.html > https://www.rfc-editor.org/authors/rfc9768-auth48rfcdiff.html (side by side) > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9768-diff.html > https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html (side by side) > > Thank you, > Sandy Ginoza > RFC Production Center > > > >> On Sep 15, 2025, at 3:06 PM, 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. >> >> >>> 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. >> >> >> 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. >> >> >> >> >> >> The current files are available here: >> https://www.rfc-editor.org/authors/rfc9768.xml >> https://www.rfc-editor.org/authors/rfc9768.txt >> https://www.rfc-editor.org/authors/rfc9768.pdf >> https://www.rfc-editor.org/authors/rfc9768.html >> >> Diffs highlighting the last two rounds of updates: >> https://www.rfc-editor.org/authors/rfc9768-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9768-lastrfcdiff.html (side by side) >> >> AUTH48 diffs: >> https://www.rfc-editor.org/authors/rfc9768-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9768-auth48rfcdiff.html (side by side) >> >> Comprehensive diffs: >> https://www.rfc-editor.org/authors/rfc9768-diff.html >> https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html (side by side) >> >> >> >> 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]
