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