On 10/12/2025 19:15, Sandy Ginoza wrote:
I'm chiming in to suggest resolution on these two topics (unless other decisions have already been taken).Hi All,Apologies for the delayed reply - I was hoping we might hear more from the authors. There seems to be open questions about the items noted below. Please let us know how these should be resolved.
REASON: It's not meant to be saying that DCTCP, L4S etc. need the specific accurate scheme called AccECN. It's just saying they need more accurate feedback. The words "more accurate" here were just adjectives. This capitalization was introduced at draft-33, but IMHO needs to be reverted. We could use lower case 'accurate', again, but using 'precise' would avoid the ambiguity completely.I think this happens because it would be nice to introduce the acronym AccECN already in the abstract. Maybe something like this works: OLD: ..need more Accurate ECN (AccECN) feedback information whenever more than one marking is received in one RTT. This document updates the original ECN specification in RFC 3168 to specify a scheme that provides more than one feedback signal per RTT in the TCP header. NEW: need more accurate feedback information whenever more than one marking is received in one RTT. This document updates the original ECN specification in RFC 3168 to specify a scheme that provides more than one feedback signal per RTT in the TCP header, called More Accurate ECN (AccECN).
The above NEW text seems correct, I suggest we adopt this,
§1. Introduction CURRENT: (Mirja's item #1) more "Accurate ECN feedback" scheme, or AccECN for short PROPOSED: "more Accurate ECN feedback" scheme, or AccECN for short OR PERHAPS more Accurate ECN feedback scheme, or AccECN for short REASON: If we have to have quotes here, I think the word "more" should be inside them as well. When AccECN was first adopted into the WG, it was agreed to call it "More Accurate ECN Feedback" (hence the draft title) because, without 'More' some people objected to the implication that it was perfectly accurate. If it makes consensus easier, I'd accept no quotes at all too.Hm, you are right I guess. I think it would be nice to remove the “More” entirely but I do remember these early discussions. I guess we could do back to the WG and propose to remove it but not sure that’s worth the discussion.
I think we should probably use "more Accurate ECN feedback". I would not recommend asking for another consenus call on this topic.
Thanks, Sandy Ginoza RFC Production Center
Gorry (WIT AD)
On Nov 17, 2025, at 5:57 AM, Mirja Kuehlewind (IETF) <[email protected]> wrote: HI Bob, hi Sandy, hi all, Thanks a lot for doing another in depth review and flagging these things! Most look good to me but I have a few comments. Please see below. MirjaOn 8. Nov 2025, at 20:02, Bob Briscoe <[email protected]> wrote: Sandy, (and a couple of responses that Mirja & Richard will need to agree to), All my review comments are below. Apology: I stopped working on Internet technology a couple of years ago, so I'm afraid I also have some comments on editorial changes to the draft that have been introduced in the ensuing period, as the native English speaker among the authors. This email was based on just looking at the highlighted diffs. Once I've sent it, I will try to read through the whole doc one last time (in parallel to discussion of the two outstanding discussion items noted below). Abstract: CURRENT: (Sandy's item #1) More recently defined TCP mechanisms PROPOSED: More recently defined mechanisms REASON: ConEx, DCTCP and L4S are all cross-layer (L3/L4) mechanisms, not specifically TCP mechanisms. CURRENT: ...need more Accurate ECN (AccECN) feedback information... PROPOSED: ...need more precise ECN feedback information... REASON: It's not meant to be saying that DCTCP, L4S etc. need the specific accurate scheme called AccECN. It's just saying they need more accurate feedback. The words "more accurate" here were just adjectives. This capitalization was introduced at draft-33, but IMHO needs to be reverted. We could use lower case 'accurate', again, but using 'precise' would avoid the ambiguity completely.I think this happens because it would be nice to introduce the acronym AccECN already in the abstract. Maybe something like this works: OLD: ..need more Accurate ECN (AccECN) feedback information whenever more than one marking is received in one RTT. This document updates the original ECN specification in RFC 3168 to specify a scheme that provides more than one feedback signal per RTT in the TCP header. NEW: need more accurate feedback information whenever more than one marking is received in one RTT. This document updates the original ECN specification in RFC 3168 to specify a scheme that provides more than one feedback signal per RTT in the TCP header, called More Accurate ECN (AccECN).§1. Introduction CURRENT: (Mirja's item #1) more "Accurate ECN feedback" scheme, or AccECN for short PROPOSED: "more Accurate ECN feedback" scheme, or AccECN for short OR PERHAPS more Accurate ECN feedback scheme, or AccECN for short REASON: If we have to have quotes here, I think the word "more" should be inside them as well. When AccECN was first adopted into the WG, it was agreed to call it "More Accurate ECN Feedback" (hence the draft title) because, without 'More' some people objected to the implication that it was perfectly accurate. If it makes consensus easier, I'd accept no quotes at all too.Hm, you are right I guess. I think it would be nice to remove the “More” entirely but I do remember these early discussions. I guess we could do back to the WG and propose to remove it but not sure that’s worth the discussion.§ 1.2. Goals CURRENT: Section 6 considers the properties of AccECN against these requirements and discusses the trade-offs. PROPOSED: Section 6 assesses the properties of AccECN against these requirements and discusses the trade-offs. REASONING: You can't really consider something against some requirements. After "...an AccECN receiver acts as a generic (mechanistic) reflector of congestion information with the aim that new sender behaviours" CURRENT: can be deployed unilaterally (see Section 2.5) in the future. PROPOSED: can be deployed unilaterally in the future (see Section 2.5). REASONING: This read as if §2.5 is about unilateral deployment, rather than generic (mechanistic) reflection. §1.3 Terminology CURRENT: (Mirja's item #1) Accurate ECN feedback: The more Accurate ECN feedback scheme is called AccECN for short. PROPOSED: AccECN: The more Accurate ECN feedback scheme. REASON: Surely, in a list of name-definition pairs, the first of the pair would be expected to be the name or abbreviation that people are expected to be looking up? Also, as the Current text stands, it's become a circular definition.Agreed.§1.4 Recap of Existing ECN Feedback in IP/TCP s/conceptionally/conceptually/ REASON: conceptional relates to the process or act of conceiving, and often has an implication of an idea in early formation. Whereas what is meant here is surely just "in terms of concepts," for which the correct word is just conceptually. CURRENT: This signal carried in the IP (Layer 3) header is exposed to network devices and may be modified when such a device starts to experience congestion ... PROPOSED: This signal carried in the IP (Layer 3) header is exposed to network devices, which can modify it when they start to experience congestion ... REASON: Avoids the passive voice to be clear which node does what. CURRENT: by which the original data sender is notified of the current congestion state PROPOSED: by which the data receiver notifies the current congestion state to the original data sender REASON: Avoids the passive voice to be clear which node does what. CURRENT: That returned signal is carried in a protocol-specific manner, PROPOSED: That returned signal is carried in a transport-protocol-specific manner, REASON: Otherwise this would incorrectly imply that it might depend on the protocol being used below or above L4. §2.3 Delayed ACKs and Resilience Against ACK Loss CURRENT: a whole cycle of the field would never occur between ACKs unless there has been an infeasibly long sequence of ACK losses. PROPOSED: a whole cycle of the field would never occur between ACKs unless there had been an infeasibly long sequence of ACK losses. REASONING: Surely, either "will never ... unless there is" (present hypothetical or unreal present) or "would never ... unless there had" (past hypothetical or unreal past). §3.1.2 Backward Compatibility CURRENT: (Mirja's item #5) The three flags set to 1 to indicate AccECN support on the SYN has been carefully chosen PROPOSED: The setting of all three flags to 1 in order to indicate AccECN support on the SYN was carefully chosen OR PERHAPS The three flags set to 1 in order to indicate AccECN support on the SYN have been carefully chosen REASON: Plural subject, singular noun. I notice in the diffs this went through "The three flags are set to 1..." then, "are" was removed and "have" became "has" This implied to me that the sentence was hard to parse, so I've suggested a rework. §3.1.3. Forward Compatibility CURRENT: (Sandy's item #3) all the Reserved combinations on a SYN or SYN/ACK (see Table 2) PROPOSED: all the Reserved combinations of all the TCP header bits on a SYN or SYN/ACK REASON: This is not just about the one reserved combination in Table 2. The previous para was about the three remaining reserved TCP header bits as well. §3.1.4.1. Retransmitted SYNs CURRENT: (Sandy's item #4) more effective (e.g., attempting to negotiate AccECN on the SYN only once or more than twice (most appropriate during high levels of congestion)). PROPOSED: more effective, e.g., attempting to negotiate AccECN on the SYN only once or more than twice (most appropriate during high levels of congestion). REASON: The correction to close both parentheses as now in the Current text is acceptable, but the Proposed text avoids the nested parentheses entirely. CURRENT: (Sandy's item #5) that tries use of AccECN without setting ETC on SYN. PROPOSED: that tries use of AccECN without setting ECT on the SYN. REASON: Note: 2 edits here. CURRENT: Note that this rule is different than PROPOSED: Note that this rule is different from REASON: This form should be comfortable for both British and US English readers (British uses 'to', not 'than', but both can use 'from').§3.1.5.CURRENT: MUST NOT switch into a different feedback mode than the one PROPOSED: MUST NOT switch into a different feedback mode from the one REASON: Ibid §3.2.2.1. ACE Field on the ACK of the SYN/ACK CURRENT: (Mirja's item #6) 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. PROPOSED: If the TCP Server does not receive the final ACK of the handshake before its retransmission timer expires, the procedure for it to follow is given in Section 3.1.4.2. REASON: The newly reversed wording made the ACK the subject, not the Server, so it no longer made sense to talk of "its retransmission timer". CURRENT: 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. PROPOSED: an AccECN Server using large receive offload (LRO) might prefer to disable LRO until it transitions out of SYN-RCVD state (when it first receives an ACK that covers the SYN/ACK). REASON: Having caught this technical bug in the spec, in side-discussion with Richard I pointed out that we need to specify which of the two events would cause LRO to start, because the ACK of the SYN/ACK can be lost or delayed, then a later ACK would trigger the transition out of SYN-RCVD state. Richard replied that it would be best to use the transition. Incidentally, the text could not be kept as it was anyway, because the Server doesn't know when (or whether) the ACK was sent (by the Client); The Server only knows when it receives the ACK. I've also avoided the passive (and 'was' should have been 'has been' anyway) CURRENT: For example, it will not disable ECN (at least not just because ACE is 0b000) and it will not set s.cep. PROPOSED: That is, it will not disable ECN (at least not just because ACE is 0b000) and it will not set s.cep. REASON: When I wrote this sentence, it was not intended as an example, but rather, a more specific statement of the previous sentence (it was changed from 'i.e.' at draft-33, but I can't find a reason given for changing it). §3.2.2.3. Testing for Mangling of the IP/ECN Field After this sentence: The above advice on switching to sending non-ECN-capable packets but still responding to CE markings unless they become continuous is not stated normatively (in capitals), because the best strategy might depend on experience of the most likely types of mangling, which can only be known at the time of deployment. CURRENT: The same is true for other forms of mangling (or resumption of expected marking) during later stages of a connection. PROPOSED: For instance, later in a connection, sender implementations might need to detect the onset (or the end) of mangling and stop (or start) sending ECN-capable packets accordingly. REASON: I've reworded, because it broke the flow (for me) to have to work out which part of the previous long sentence the phrase "The same is true" referred to. §3.2.2.4. Testing for Zeroing of the ACE Field [@Sandy, please wait for a decision from an ongoing parallel discussion about whether this test should now be removed completely from the draft. In that case, both changes below to this section might become redundant - they merely improve clarity/grammar/consistency. ] CURRENT: (related to Sandy's item #11) might depend on the likelihood to experience these scenarios, PROPOSED: might depend on the likelihood of experiencing these scenarios, REASON: The Current text is grammatically possible (just), but the Proposed text is the more common and universally accepted construction. See https://forum.wordreference.com/threads/likelihood-to.3114359/ or search CURRENT: If reordering occurs, the first feedback packet that arrives will not necessarily be the same PROPOSED: If reordering occurs, the first feedback packet that arrives after the three-way handshake will not necessarily be the same REASON: This refers back to an earlier sentence that is now a long way back due to extra reasoning and notes having been added. "The first packet that arrives" was originally in quotes to make it clear this was a reference back, but if the quotes are to be removed, we have to repeat the full definition of which packet is being talked about. Personally, I think it would be clearer and briefer to reintroduce the quotes and just say "The first packet that arrives". §3.2.2.5.1. Packet Receiver Safety Procedures CURRENT: Active Queue Management (AQM) packet schedulers PROPOSED: Active Queue Management (AQM) algorithms REASON: IMHO, an AQM algorithm isn't typically a scheduler (because it doesn't typically or necessarily alter the order of packets, which is what 'scheduling' implies). § 3.3.2. Requirements for Transparent Middleboxes and TCP Normalizers CURRENT: a rather narrow interpretation of the TCP specifications that is not always up to date. PROPOSED: a rather narrow interpretation of the TCP specifications that is also not always kept up to date. REASON: Reverted to include 'also', otherwise it could be misunderstood as "the interpretation of the TCP specs is not always up to date, which makes it narrow". FYI, narrow means, amongst other things, "the interpretation excludes the allowances for future evolution in the TCP specs " (i.e. less likely to go out of date). BTW, I've added 'kept' to redirect this criticism away from middlebox designers, given we want them to read and comply with the RFCs. §3.3.3. Requirements for TCP ACK Filtering CURRENT: (Sandy's item #15) Section 5.2.1 of RFC 3449 [BCP69] gives best current practice on filtering PROPOSED: Section 5.2.1 of [RFC3449] gives best current practice on filtering REASON: This is a reference to one specific para of RFC 3449. The reference is solely about filtering, as just one topic amongst all the path asymmetry topics in RFC3449. It's definitely not intended to be a reference to all other possible future aspects of the BCP 69 set as a whole (currently a set with one member - RFC 3449 concerning path asymmetry). By referencing [BCP69], the tools have expanded the listing in the references to allow for the possibility of further RFCs being added to the BCP, but currently there is only this one listed. Instead, it should be like all other listings of RFCs that are also BCPs, which are constructed as just a reference to a specific RFC (correctly in each case). CURRENT: (Sandy's iem #15) Even if ECN++ is used, pure ACKs do not necessarily have to be marked as ECN-capable PROPOSED: Even if a sender uses ECN++, it does not necessarily have to mark pure ACKs as ECN-capable REASON: Avoiding the passive to remove ambiguity; otherwise this could be talking about use and marking in general, rather than each individual sender. §3.3.4. Requirements for TCP Segmentation Offload and Large Receive Offload CURRENT: (Sandy's item #16) with Classic ECN [RFC3168] supporting hardware PROPOSED: with hardware that supports Classic ECN [RFC3168] REASON: To remove ambiguity this ought to have been hyphenated as Classic-ECN-supporting hardware. But the reference gets in the way, so re-worked. §4. Updates to RFC 3168 (Sandy's item #17) I'm afraid I disagree with Mirja's agreement with you. In all cases, where section headings from RFC3168 have been removed, I would prefer them to be reinstated (in whatever style is the norm). This follows the general rule that references should be briefly described inline. Each quoted heading gave just enough context.Removing them would turn this section into an incomprehensible list of mappings between numbers, which would then require the reader to follow each reference to understand the implications of each change.I don’t have a strong opinion here but I don’t think that is a style that is commonly used. I see no problem in only having the section number as you anyway need to look at rfc3168 to make sense of this section. That normal for the kind of section, or actually their whole purpose.§5.2. CURRENT: (Sandy's item #19) 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. PROPOSED: specifies which AccECN Option fields are more important to include and provides guidance on the relative importance of AccECN Options against other TCP Options. REASON: I could see parsing this sentence had been problematic. So first tried to reword to avoid splitting the phrase "how important relative to other options", but ended up reworking completely for clarity. §6. Summary: Protocol Properties CURRENT: any blocking will at least be under policy control and not hard-coded. PROPOSED: any blocking will at least be under policy control, not hard-coded. REASON: The Current text could now be misinterpreted as "both under policy control and not hard-coded." Whereas it was intended to imply "under policy control, which is well-known not to be hard-coded." As well as reverting, I've added a comma. §8. Security and Privacy Considerations CURRENT: it is no different than the use of unknown TCP Options PROPOSED: it is no different from the use of unknown TCP Options The para starting and ending as follows would be better shifted one para earlier, because it is not about privacy but it sits between paras that are about privacy. "There is a potential concern that a Data Receiver could deliberately omit AccECN Options ... ... for completeness." s/to not enable the Accurate ECN/ /to not enable Accurate ECN/ 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. PROPOSED: However, it is expected that AccECN will become available in more operating systems over time and that it will eventually be turned on by default. REASONING: It's already in a number of OSs (actually listed at the end of the spec). Last two para's: [@Sandy, please wait for a decision from parallel discussion about the last two para's "As Accurate ECN exposes ... ... for that matter." ] §9.2. Informative References (Sandy's item #26) CURRENT: InfiniBand Trade Association, "InfiniBand Architecture Specification", <https://www.infinibandta.org/ibta-specification/>. PROPOSED: InfiniBand Trade Association, "InfiniBand Architecture Specification" Volume 1, since Release 1.4 (2020), <https://www.infinibandta.org/ibta-specification/>. REASONING: Pls check with Richard, who added this ref a month after I took a step back. Given he added it to AccECN draft-31 in Dec 2024, I assume he was referring back to the release when precise ECN feedback had been added to RoCEv2. The specs are only available to members, so it's hard for me to check now. I notice Richard has put the following URL in as an XML comment: https://cw.infinibandta.org/document/dl/7781 but it's Permission Denied for me. §A.2.1. Safety Algorithm Without the AccECN Option CURRENT: (Sandy's item #31) at least 5% of a full-sized packet PROPOSED: at least 5% of a full-sized segment s/A.2.2. Safety Algorithm with the AccECN Option/ /A.2.2. Safety Algorithm With the AccECN Option/ REASON: Consistent with previous section heading. §A.3. Example Algorithm to Estimate Marked Bytes from Marked Packets CURRENT: (Sandy's item #34) the Data Sender can only decode a CE marking from the ACE field in packets. PROPOSED: the Data Sender can only decode the ACE field as a number of marked packets. REASONING: I detect that otherwise "in packets" was ambiguous, possibly being interpreted as "inside packets" rather than "in units of packets" §B.1. Three TCP Header Flags in the SYN-SYN/ACK Handshake CURRENT: (Sandy's item #36) and fell back to No ECN support PROPOSED: and fell back to no ECN support REASONING: Not intended to be a name; it just means "no support for ECN" (which you might wish to write in full). The four other occurrences of No ECN are correct (because they refer to the 'No ECN' feedback mode defined just for Table 2 and its discussion) Throughout: I actually disagree with Mirja and think that all should be changed back to IP-ECN, but I wouldn't fight for this. Unfortunately, there is no consistency in the RFCs to guide us. However, I would have thought these ought to follow the general grammar rule about hyphenation of compound nouns used as adjectives before the noun that they modify - a rule intended to remove ambiguity. There are 9 occurrences TCP-ECN and 7 occurrences of TCP ECN. I suggest they are all made consistent with IP-ECN/IP ECN. Even when the words 'TCP ECN' are used for other things than the flags (e.g. TCP ECN feedback or TCP ECN capability negotiation) IMHO it would still be OK to hyphenate (or not) as long as they are all consistent.I have no strong opinion here. I didn’t fine ECN-IP or ECN-TCP in any other RFC, therefore I found it more appropriate to not use the hyphenate. If we think it beneficial for this document to use it, it would be okay for me. I don’t find that makes really a difference as reader. I agree that it should be consistent, also with TCP-ECN.<aside> tags (Sandy's item #37) I agree with Mirja for most of the notes, but <aside> could/would be appropriate in the cases below, however it's not important enough to me to fight over it: • §3.2.2.4:Note that a host in AccECN mode MUST continue to provide Accurate ECN feedback to its peer, even if it is no longer sending ECT itself over the other half-connection. • §3.2.2.4: Note that the Data Sender MUST NOT test whether the arriving counter in the initial ACE field has been initialized to a specific valid value -- the above check solely tests whether the ACE fields have been incorrectly zeroed. This allows hosts to use different initial values as an additional signalling channel in the future. • §3.2.3.2.4: Note that the Data Sender MUST NOT test whether the arriving byte counters in an initial AccECN Option have been initialized to specific valid values -- the above checks... XML Comments (Sandy's item #38) I've checked through, and they can all be deleted from my PoV. Thank you again, for staying focused and precise throughout such a long spec. Amazing! Cheers Bob On 21/10/2025 16:45, Sandy Ginoza wrote:Thanks Mirja! I know Bob usually likes to do a full read through, so we’ll be on the lookout for his updates. Thanks, Sandy Ginoza RFC Production CenterOn Oct 21, 2025, at 8:35 AM, Mirja Kuehlewind <[email protected]> wrote: Yes I’m in touch with Bob and he promised me to reply so hopefully we‘ll see something soon!Am 21.10.2025 um 18:24 schrieb Sandy Ginoza <[email protected]>: Hi Mirja and Richard, Thank you for your quick replies. We have noted your approvals on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9768>. We do not believe we have received input from Bob yet. Do you know if he is receiving these mails? Thanks, Sandy Ginoza RFC Production CenterOn Oct 21, 2025, at 1:53 AM, Mirja Kuehlewind (IETF) <[email protected]> wrote: Yes, that works for me! Thanks!On 21. Oct 2025, at 09:53, Scheffenegger, Richard <[email protected]> wrote:Sounds perfect! Thanks! Mirja, do you concur? Richard Scheffenegger Senior Solution Architect NAS & Networking NetApp +43 1 3676 811 3157 Direct Phone +43 664 8866 1857 Mobile Phone [email protected] -----Original Message----- From: Sandy Ginoza <[email protected]> Sent: Montag, 20. Oktober 2025 19:04 To: Scheffenegger, Richard <[email protected]> Cc: Mirja Kuehlewind <[email protected]>; RFC Editor <[email protected]>; Bob Briscoe <[email protected]>; [email protected]; [email protected]; Michael Tuexen <[email protected]>; Zaheduzzaman Sarker <[email protected]>; auth48archive <[email protected]> Subject: Re: AUTH48: RFC-to-be 9768 <draft-ietf-tcpm-accurate-ecn-34> for your review EXTERNAL EMAIL - USE CAUTION when clicking links or attachments Hi Richard, The following reflects the updated text, and the diffs (only) can be viewed in the following files: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVFbzDLww$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastrfcdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVAfG0B5I$ (side by side) Current Section 1: It is called the more "Accurate ECN feedback" scheme, or AccECN for short. Current Section 1.3: Accurate ECN feedback: The more Accurate ECN feedback scheme is called AccECN for short. Because the text indicates "Accurate ECN feedback” is referred to as AccECN, we do not believe other updates are needed throughout the text. The current files are available here: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.xml__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GV8xZuVnI$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.txt__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVYY2szYY$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.pdf__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVyMl7NGE$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVLG4uHT0$ Diffs of the most recent updates only: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVFbzDLww$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastrfcdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVAfG0B5I$ (side by side) AUTH48 diffs: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-auth48diff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GV71nPedA$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-auth48rfcdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVaNvCWN0$ (side by side) Comprehensive diffs: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-diff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVzZc6dx4$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html__;!!Nhn8V6BzJA!Rw9A_qPwQjMxUuKn1S6xhRZetjJTro-M0zixYJYnrgvZjoFSmtk0_rPcH4vdciZlrt3yi5GhAOgilJO7HsNPPS0gv1GVG7QTG4c$ (side by side) Please let us know if this is acceptable and/or if other changes are needed. Thank you, Sandy Ginoza RFC Production CenterOn Oct 20, 2025, at 3:47 AM, Scheffenegger, Richard <[email protected]> wrote: Hi Sandy, Can you please go ahead with the proposed changes to include the "feedback" suffix when referring to the schemes of AccECN feedback and also Classic ECN feedback? Looking at the latest AUTH48 diff, I didn’t really spot on which places in total that moficiation (addition of "feedback" when talking about AccECN and Classic ECN) would go, really. Thanks, Richard Scheffenegger Senior Solution Architect NAS & Networking NetApp +43 1 3676 811 3157 Direct Phone +43 664 8866 1857 Mobile Phone [email protected] -----Original Message----- From: Sandy Ginoza <[email protected]> Sent: Freitag, 17. Oktober 2025 18:01 To: Mirja Kuehlewind <[email protected]> Cc: Scheffenegger, Richard <[email protected]>; RFC Editor <[email protected]>; Bob Briscoe <[email protected]>; [email protected]; [email protected]; Michael Tuexen <[email protected]>; Zaheduzzaman Sarker <[email protected]>; auth48archive <[email protected]> Subject: Re: AUTH48: RFC-to-be 9768 <draft-ietf-tcpm-accurate-ecn-34> for your review EXTERNAL EMAIL - USE CAUTION when clicking links or attachments Hi Mirja, We updated the text per your preference for item 5. We will wait to hear further regarding item 1, as we believe this is under discussion with the authors. Thanks, Sandy Ginoza RFC Production CenterOn Oct 13, 2025, at 7:28 AM, Mirja Kuehlewind (IETF) <[email protected]> wrote: Hi again, Sorry, I’m still catching up on emails from my holidays end of September and saw just now that the discussion already moved on. Please see below.On 16. Sep 2025, at 00:06, Sandy Ginoza <[email protected]> wrote: Hi Ricard, Please see notes below.On Sep 15, 2025, at 2:07 AM, Scheffenegger, Richard <[email protected]> wrote: Re 1: I opt to have the "feedback" part a suffix, because adding feedback in "" marks then would necessitate this to be deployed throughout the documnent and i think it would start reading awkward. As the document really only ever touches the TCP based feedback, but not the overarching concept of ECN as a whole, I think mentioning it once in the definitions (outside the quotation marks) should suffice and makes the rest of the document more readable...We have not made any changes here. While we typically use quotes to specify the terms being introduced (e.g., this action is called “abc”), another option would be to drop the quotes.I’m a bit lost now. Where do people want to use or not use quotes? I agree that usually the word “feedback” shouldn’t be included in the quotes but if so we need to make it consent for both “AccECN feedback” and “Classic ECN feedback”. The problem is that “Classic ECN” consists of more than just the feedback part, therefore it is correct to define both “Classic ECN” and “Classic ECN feedback”. I think to be consistent we could then also use the term “AccECN feedback”.Re 5 For me as non-native speaker, this now reads a bit awkward. Maybe: Setting the three flags (AE, CWR, ECE) to 1 to indicate AccECN support on the SYN has been carefully chosen to enable natural fall-back to prior stages in the evolution of ECN. (s/have/has/ -> was plural/ is singular now).Good catch - the text now reads as follows: The three flags set to 1 indicate AccECN support on the SYN has been carefully chosen to enable natural fall-back to prior stages in the evolution of ECN.See my previous mails. I think the sentence is more clear with the “to”.Please note that we await input regarding the author comments in the XML file.38) <!-- [rfced] Some author comments are present in the XML. Please confirm that no updates related to these comments are outstanding. Note that the comments will be deleted prior to publication. -->Richard and Bob would need to double-check this.Richard confirmed to me by chat that we don’t need the comments anymore from his point of view. And as I said I just pinged Bob hoping we will hear from him soon. MirjaThe current files are available here: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.xml__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NooNo_Mo$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.txt__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NnSOHbdM$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.pdf__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6Nsw4rcHE$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6N4xvmu_U$ Diffs highlighting the last two rounds of updates: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastdiff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NkHTxV5c$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-lastrfcdiff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NMlwcBmQ$ (side by side) AUTH48 diffs: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-auth48diff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NFFwjlTg$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-auth48rfcdiff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6N9BDUn1U$ (side by side) Comprehensive diffs: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-diff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NoOH8FJk$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html__;!!Nhn8V6BzJA!XTLEmol_ZrwwJADunXGCGTYvamILBrxGiqhlCElga_nfyQw-9jW-Pwi4zzS4bJHbCbIMLUw36KVd_8fN8t0-GWnQRe6NlIk1ZVc$ (side by side) Thank you, Sandy Ginoza RFC Production CenterBest 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 CenterThanks, Sandy Ginoza RFC Production CenterOn 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. MirjaOn 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 CenterOn 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 CenterOn 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 B23) <!-- [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, thanks24) <!-- [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 bytes35) <!-- [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 fieldI 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 stateYes, let’s aways use ESTABLISHED state as in RFC9293.half connection vs half-connectionLet'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! MirjaThank 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-- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
