Hi Sandy, Sorry for my late reply. I will also try to ping Bob again. Hopefully we can wrap this up soonish!
Please see inline. > On 13. Sep 2025, at 00:02, Sandy Ginoza <[email protected]> wrote: > > 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. Yes, I think using “AccECN feedback" should work but I didn’t check all occurrences in the entire document carefully now. Maybe you can double-check that. > > > > 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. Thanks! Yes, this looks good now! > >> 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. Thanks! I actually think the sentence would be more clear with the “to” but maybe I’m missing some problem…? Mirja > >> 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://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 most recent 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 > > > > > >> >> >> 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://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 >>>>> >>>>> 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) >>>>> >>>>> >>>>> 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://www.infinibandta.org/wp-content/uploads/2024/09/IBTA-Overview-of-IBTA-Volume-1-Release-1.8.pdf). >>>>>>> >>>>>>> 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://www.infinibandta.org/ibta-specification/>. >>>>>>> >>>>>>> Perhaps: >>>>>>> >>>>>>> [RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture >>>>>>> Specification", >>>>>>> <https://www.infinibandta.org/ibta-specification/>. >>>>>>> >>>>>>> OR >>>>>>> >>>>>>> [RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture >>>>>>> Specification", Volume 1, Release 1.8, July 2024, >>>>>>> <https://www.infinibandta.org/ibta-specification/>. >>>>>>> >>>>>>> --> >>>>>> >>>>>> 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://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) >>>>>>> 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://authors.ietf.org/en/rfcxml-vocabulary#aside). >>>>>>> --> >>>>>> >>>>>> 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://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>>> >>>>>>> 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://www.rfc-editor.org/faq/). >>>>>>> >>>>>>> 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://trustee.ietf.org/license-info). >>>>>>> >>>>>>> * 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://authors.ietf.org/rfcxml-vocabulary>. >>>>>>> >>>>>>> * 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>>>> >>>>>>> * The archive itself: >>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>> >>>>>>> * 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://www.rfc-editor.org/authors/rfc9768.xml >>>>>>> https://www.rfc-editor.org/authors/rfc9768.html >>>>>>> https://www.rfc-editor.org/authors/rfc9768.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9768.txt >>>>>>> >>>>>>> Diff file of the text: >>>>>>> https://www.rfc-editor.org/authors/rfc9768-diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html (side by side) >>>>>>> >>>>>>> Diff of the XML: >>>>>>> https://www.rfc-editor.org/authors/rfc9768-xmldiff1.html >>>>>>> >>>>>>> >>>>>>> Tracking progress >>>>>>> ----------------- >>>>>>> >>>>>>> The details of the AUTH48 status of your document are here: >>>>>>> https://www.rfc-editor.org/auth48/rfc9768 >>>>>>> >>>>>>> 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]
