Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\))
From: Sandy Ginoza <sginoza@staff.rfc-editor.org>
In-Reply-To: <418B3967-CA17-4266-A39B-49C6A97C3B45@staff.rfc-editor.org>
Date: Fri, 12 Sep 2025 15:02:21 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEE29C34-C872-44FF-802B-95B411AEE097@staff.rfc-editor.org>
References: <20250812193805.1F86B27FF60@rfcpa.rfc-editor.org>
 <78FAC8EA-F27F-4DBB-BDC5-3002B6108A9A@kuehlewind.net>
 <9787AB83-475F-4B01-9B4C-7865E15C3167@staff.rfc-editor.org>
 <3C7B2F31-8171-408A-8A6B-C18EC17C2EF4@staff.rfc-editor.org>
 <93276A1A-6470-4E49-B8C5-10E94DDE5762@kuehlewind.net>
 <418B3967-CA17-4266-A39B-49C6A97C3B45@staff.rfc-editor.org>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Message-ID-Hash: HRIMQZVPCFZ45KU64URLPVVNSBFMZ5QL
CC: RFC Editor <rfc-editor@rfc-editor.org>, Bob Briscoe <ietf@bobbriscoe.net>,
 richard.scheffenegger@netapp.com, tcpm-ads@ietf.org, tcpm-chairs@ietf.org,
 Michael Tuexen <tuexen@fh-muenster.de>,
 Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>,
 auth48archive <auth48archive@rfc-editor.org>
Precedence: list
Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_AUTH48=3A_RFC-to-be_9768_=3Cdraft-ietf-tcpm-acc?=
 =?utf-8?q?urate-ecn-34=3E_for_your_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/auth48archive/I6GYKTFLMyPFBXTExVmHUuAjozY>

Hi Mirja, Bob, Richard,

We made some updates to the document, but we await guidance regarding =
items 1 and 5 below. =20


1) Please review the the info below and let us know how you would like =
to proceed.=20

>> 1) There is an inconsistency now about these two sentences/terms:
>>=20
>> =E2=80=9CIt is called the more "Accurate ECN" feedback scheme, or =
AccECN for short.=E2=80=9D
>>=20
>> "This document uses the term "Classic ECN feedback" when =E2=80=A6=E2=80=
=9D
>>=20
>> I think you either have to have the word =E2=80=9Cfeedback=E2=80=9D =
as part of both terms or none.
>>=20
>> So either:
>>=20
>> =E2=80=9CIt is called the more "Accurate ECN feedback" scheme, or =
AccECN feedback for short.=E2=80=9D
>>=20
>> "This document uses the term "Classic ECN feedback" when =E2=80=A6=E2=80=
=9D
>>=20
>> or
>>=20
>> =E2=80=9CIt is called the more "Accurate ECN=E2=80=9D scheme, or =
AccECN for short.=E2=80=9D
>>=20
>> "This document uses the term "Classic ECN" when =E2=80=A6=E2=80=9D
>>=20

> Thanks for your thorough review.  Regarding item 1, the doc defines =
the following in section 1.3:
>=20
>=20
>   AccECN:  The more Accurate ECN feedback scheme will be called AccECN
>      for short.
>=20
>   Classic ECN:  The ECN protocol specified in [RFC3168].
>=20
>   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.
>=20
>=20
> So perhaps we should be using =E2=80=9CClassic ECN feedback=E2=80=9D =
and =E2=80=9CAccECN feedback=E2=80=9D, and the AccECN definition above =
should be updated to refer to "AccECN feedback=E2=80=9D? =20
>=20
> That is:=20
>   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.=20

> 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=E2=80=99=
m fine to go with whatever is most commonly done in RFCs.




5) We have updated the text to read =E2=80=9Cset to 1 indicate=E2=80=9D =
(deleted =E2=80=9Cto=E2=80=9D after "1"). Please let us know if any =
corrections are needed.=20

> 5) I think adding the =E2=80=9Care=E2=80=9D in the first sentence in =
Section 3.1.2 is wrong:
>=20
> The three flags are
>  set to 1 to indicate AccECN support on the SYN have been carefully =
chosen=E2=80=A6


=20
The current files are available here:=20
   https://www.rfc-editor.org/authors/rfc9768.xml
   https://www.rfc-editor.org/authors/rfc9768.txt
   https://www.rfc-editor.org/authors/rfc9768.pdf
   https://www.rfc-editor.org/authors/rfc9768.html

Diffs highlighting the most recent updates:=20
   https://www.rfc-editor.org/authors/rfc9768-lastdiff.html
   https://www.rfc-editor.org/authors/rfc9768-lastrfcdiff.html (side by =
side)

AUTH48 diffs:=20
   https://www.rfc-editor.org/authors/rfc9768-auth48diff.html
   https://www.rfc-editor.org/authors/rfc9768-auth48rfcdiff.html (side =
by side)

Comprehensive diffs:=20
   https://www.rfc-editor.org/authors/rfc9768-diff.html
   https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html (side by =
side)

Thank you,
Sandy Ginoza
RFC Production Center





>=20
>=20
> Thanks,
> Sandy Ginoza
> RFC Production Center
>=20
>=20
>=20
>> On Sep 2, 2025, at 8:38 AM, Mirja Kuehlewind (IETF) =
<ietf@kuehlewind.net> wrote:
>>=20
>> Hi Sandy,
>>=20
>> I now reviewed the whole document and I have a few minor things.
>>=20
>> 1) There is an inconsistency now about these two sentences/terms:
>>=20
>> =E2=80=9CIt is called the more "Accurate ECN" feedback scheme, or =
AccECN for short.=E2=80=9D
>>=20
>> "This document uses the term "Classic ECN feedback" when =E2=80=A6=E2=80=
=9D
>>=20
>> I think you either have to have the word =E2=80=9Cfeedback=E2=80=9D =
as part of both terms or none.
>>=20
>> So either:
>>=20
>> =E2=80=9CIt is called the more "Accurate ECN feedback" scheme, or =
AccECN feedback for short.=E2=80=9D
>>=20
>> "This document uses the term "Classic ECN feedback" when =E2=80=A6=E2=80=
=9D
>>=20
>> or
>>=20
>> =E2=80=9CIt is called the more "Accurate ECN=E2=80=9D scheme, or =
AccECN for short.=E2=80=9D
>>=20
>> "This document uses the term "Classic ECN" when =E2=80=A6=E2=80=9D
>>=20
>>=20
>> 2) I think you should use upper case letter here:
>>=20
>> OLD
>> large receive offload (LRO) or generic receive offload (GRO)
>>=20
>> NEW
>> Large Receive Offload (LRO) or Generic Receive Offload (GRO)
>>=20
>>=20
>> 3) Congestion Window Reduced (CWR) is introduced a second time in =
Section 2.3. This can be removed.
>>=20
>>=20
>> 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=E2=80=
=99m fine to go with whatever is most commonly done in RFCs.
>>=20
>>=20
>> 5) I think adding the =E2=80=9Care=E2=80=9D in the first sentence in =
Section 3.1.2 is wrong:
>>=20
>> The three flags are
>> set to 1 to indicate AccECN support on the SYN have been carefully =
chosen=E2=80=A6
>>=20
>>=20
>>=20
>> 6) There is also a wrong word is in this sentence in section 3.2.2.1:
>>=20
>> 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.
>>=20
>> 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:
>>=20
>> 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.
>>=20
>>=20
>> Mirja
>>=20
>>=20
>>=20
>>=20
>>> On 23. Aug 2025, at 00:05, Sandy Ginoza =
<sginoza@staff.rfc-editor.org> wrote:
>>>=20
>>> Hi Mirja and Bob,
>>>=20
>>> 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.=20
>>>=20
>>> Thank you,
>>> Sandy Ginoza
>>> RFC Production Center
>>>=20
>>>=20
>>>=20
>>>> On Aug 15, 2025, at 11:11 AM, Sandy Ginoza =
<sginoza@staff.rfc-editor.org> wrote:
>>>>=20
>>>> Hi Mirja,
>>>>=20
>>>> Thanks for your close review and the explanations provided.  We =
have updated the document as described below. =20
>>>>=20
>>>> 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.=20=

>>>>=20
>>>> <!-- [rfced] Will "rights and obligations" be commonly understood =
in this context?  We only    =20
>>>> see it used in RFC 3647, and it appears as part of quoted text =
there.                          =20
>>>>=20
>>>> Section 3.1.1 original:                                             =
                           =20
>>>> Once in AccECN mode, a TCP Client or Server has the rights and      =
                        =20
>>>> obligations to participate in the ECN protocol defined in           =
                        =20
>>>> Section 3.1.5.                                                      =
                        =20
>>>>=20
>>>> Section 3.1.5 original:                                             =
                           =20
>>>> An implementation that supports AccECN has the rights and =
obligations                       =20
>>>> concerning the use of ECN defined below, which update those in      =
                        =20
>>>> Section 6.1.1 of [RFC3168].                                         =
                        =20
>>>> -->
>>>>=20
>>>>=20
>>>> The current files are available here:=20
>>>> https://www.rfc-editor.org/authors/rfc9768.xml
>>>> https://www.rfc-editor.org/authors/rfc9768.txt
>>>> https://www.rfc-editor.org/authors/rfc9768.pdf
>>>> https://www.rfc-editor.org/authors/rfc9768.html
>>>>=20
>>>> AUTH48 diffs:=20
>>>> https://www.rfc-editor.org/authors/rfc9768-auth48diff.html
>>>> https://www.rfc-editor.org/authors/rfc9768-auth48rfcdiff.html (side =
by side)
>>>>=20
>>>> Comprehensive diffs:=20
>>>> https://www.rfc-editor.org/authors/rfc9768-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html (side by =
side)
>>>>=20
>>>>=20
>>>> Please review and let us know if further updates are needed.=20
>>>>=20
>>>> Thank you,
>>>> Sandy Ginoza
>>>> RFC Production Center
>>>>=20
>>>>=20
>>>>=20
>>>>> On Aug 14, 2025, at 8:05 AM, Mirja Kuehlewind (IETF) =
<ietf@kuehlewind.net> wrote:
>>>>>=20
>>>>> Hi all,
>>>>>=20
>>>>> Please see inline.
>>>>>=20
>>>>>> On 12. Aug 2025, at 21:38, rfc-editor@rfc-editor.org wrote:
>>>>>>=20
>>>>>> Authors,
>>>>>>=20
>>>>>> While reviewing this document during AUTH48, please resolve (as =
necessary)=20
>>>>>> the following questions, which are also in the XML file.
>>>>>>=20
>>>>>> 1) <!-- [rfced] Because these documents are defined in =
Informational RFCs,=20
>>>>>> is "proposed" needed here?=20
>>>>>>=20
>>>>>> Original:=20
>>>>>> 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].
>>>>>>=20
>>>>>> Perhaps:
>>>>>> Newer mechanisms like Congestion Exposure (ConEx
>>>>>> [RFC7713]), DCTCP [RFC8257], or L4S [RFC9330] ...=20
>>>>>>=20
>>>>>> Or perhaps, "More recently defined mechanisms ..."
>>>>>> -->
>>>>>=20
>>>>> I=E2=80=99d prefer "More recently defined=E2=80=9D. I think =
that=E2=80=99s what was meant here anyway; the comma seems wrong.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 2) <!-- [rfced] We are having trouble parsing "extent of =
congestion=20
>>>>>> notification".  Perhaps this means "indicate the amount of =
congestion over=20
>>>>>> the round trip"?  Please clarify. =20
>>>>>>=20
>>>>>> 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].=20
>>>>>> -->
>>>>>=20
>>>>> 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].=20
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 3) <!-- [rfced] Because "Reserved combination" is not used much, =
would it=20
>>>>>> help the reader to add a pointer - perhaps to table 2?=20
>>>>>>=20
>>>>>> 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.
>>>>>> -->
>>>>>=20
>>>>> Yes, adding a point to the table is good.
>>>>>>=20
>>>>>>=20
>>>>>> 4) <!-- [rfced] Should a second closing parens appear after =
"congestion)"?=20
>>>>>>=20
>>>>>> 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).
>>>>>> -->
>>>>>=20
>>>>> Yes, please add another closing parens.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 5) <!-- [rfced] We are unsure what "try it without" refers to =
here. Is it=20
>>>>>> "advisable to experiment without using the ECT on a SYN"?=20
>>>>>>=20
>>>>>> 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.
>>>>>> -->
>>>>>=20
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 6) <!-- [rfced] Throughout, some of the bulleted lists use a mix =
of periods and=20
>>>>>> semicolons to close the item - some within the same list.  Please =
consider whether=20
>>>>>> these may be updated for consistency.  We recommend using =
terminating periods,=20
>>>>>> unless the goal is to clarify an "and" or "or" connection between =
the list items. =20
>>>>>> Please review.=20
>>>>>> -->
>>>>>=20
>>>>> Yes, this should be unified. I=E2=80=99d be okay with terminating =
periods.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 7) <!-- [rfced] For clarity, we'd like to add quotes to =
"handshake encoding". =20
>>>>>> Please confirm this is correct, as opposed to "handshake encoding =
of the ACE=20
>>>>>> field".=20
>>>>>>=20
>>>>>> 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=3D0.
>>>>>> -->
>>>>>=20
>>>>> Yes, this should be only "handshake encoding=E2=80=9D. However, =
I=E2=80=99m not sure if the quotes are really needed.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 8) <!-- [rfced] For readability, may we break this text into two =
sentences? =20
>>>>>>=20
>>>>>> Original:
>>>>>> When an AccECN Server in SYN-RCVD state receives a pure ACK with
>>>>>> SYN=3D0 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.
>>>>>>=20
>>>>>> Perhaps:
>>>>>> When an AccECN Server in SYN-RCVD state receives a pure ACK with
>>>>>> SYN=3D0 and no SACK blocks, it MUST infer the meaning of each =
possible=20
>>>>>> value of the ACE field from Table 4 instead of treating the ACE =
field=20
>>>>>> as a counter.  Table 4 also shows the value to which an AccECN =
Server
>>>>>> MUST set s.cep as a result.
>>>>>> -->
>>>>>=20
>>>>> Given these are two normative statement let=E2=80=99s rather do it =
this way:
>>>>>=20
>>>>> NEW
>>>>> When an AccECN Server in SYN-RCVD state receives a pure ACK with
>>>>> SYN=3D0 and no SACK blocks, it MUST infer the meaning of each =
possible=20
>>>>> value of the ACE field from Table 4 instead of treating the ACE =
field=20
>>>>> as a counter. As a result, an AccECN Server
>>>>> MUST set s.cep to the respective value also shown in Table 4.
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 9) <!-- [rfced] We are unclear what "it" refers to in the =
following.  Perhaps "it"=20
>>>>>> can be deleted?
>>>>>>=20
>>>>>> 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.
>>>>>> -->
>>>>>=20
>>>>> No it is not correct to remove the =E2=80=9Cit". =E2=80=9CIt=E2=80=9D=
 is the server. A longer version of the text would be:
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 10) <!-- [rfced] We converted the notes following Table 4 into a =
list for clarity. =20
>>>>>> Please let us know if you have any concerns.=20
>>>>>> -->
>>>>>=20
>>>>> That=E2=80=99s okay.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 11) <!-- [rfced] We are having trouble parsing "depend on =
experience of the most=20
>>>>>> likely scenarios".  Does it depend on how good the experience is, =
the outcome,=20
>>>>>> etc?  Please consider whether this text can be clarified.
>>>>>>=20
>>>>>> 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.
>>>>>> -->
>>>>>=20
>>>>> I think we can do the following:
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 12) <!-- [rfced] Where is "below these bullets", as we don't see =
a bulletized list=20
>>>>>> in Section 3.2.2.5.1?  If possible, we recommend adding a pointer =
for clarity.=20
>>>>>>=20
>>>>>> 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.
>>>>>> -->
>>>>>=20
>>>>> Maybe let=E2=80=99s do it that way:
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 13) <!-- [rfced] For ease of the reader, we suggest adding a =
pointer to the=20
>>>>>> examples.=20
>>>>>>=20
>>>>>> 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).
>>>>>> -->
>>>>>=20
>>>>> It=E2=80=99s just in the text later in the same section. Not sure =
how to adda pointer here. I also don=E2=80=99t think this is needed.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 14) <!--  [rfced] Mention of BCP 69 was removed to the HTML and =
PDF could link=20
>>>>>> directly to Section 5.2.1 of RFC 3449.  Would you prefer that BCP =
69 be included=20
>>>>>> as the cite tag? =20
>>>>>>=20
>>>>>> Original:
>>>>>> Section 5.2.1 of BCP 69 [RFC3449] gives best current practice on
>>>>>> filtering (aka. thinning or coalescing) of pure TCP ACKs.
>>>>>>=20
>>>>>> Perhaps:=20
>>>>>> Section 5.2.1 of RFC 3449 [BCP69] gives best current practice on
>>>>>> filtering (aka thinning or coalescing) of pure TCP ACKs.
>>>>>> -->
>>>>>=20
>>>>> Please aline this with whatever the normal practice is supposed to =
be now. I don=E2=80=99t have a real opinion here.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 15) <!-- [rfced]  Does "even if it is" refer to using AccECN =
without ECN++ or with=20
>>>>>> ECN++?
>>>>>>=20
>>>>>> 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.=20
>>>>>>=20
>>>>>> 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.=20
>>>>>> -->
>>>>>=20
>>>>> If we split up in two sentences, I this this would be maybe =
better:
>>>>>=20
>>>>> 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.=20
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 16) <!-- [rfced] Instead of using [RFC3168] as an adjective, may =
we update this=20
>>>>>> text to refer to "Classic ECN"?=20
>>>>>>=20
>>>>>> Original:
>>>>>> One way around this could be to only negotiate for Accurate ECN, =
but
>>>>>> not offer a fall back to [RFC3168] ECN.
>>>>>>=20
>>>>>> Perhaps:
>>>>>> One way around this could be to only negotiate for Accurate ECN, =
but
>>>>>> not offer a fall back to Classic ECN [RFC3168].
>>>>>>=20
>>>>>> Original:
>>>>>> For LRO in the receive direction, a different issue may get =
exposed
>>>>>> with [RFC3168] ECN supporting hardware.
>>>>>>=20
>>>>>> Perhaps:
>>>>>> For LRO in the receive direction, a different issue may get =
exposed
>>>>>> with Classic-ECN [RFC3168] supporting hardware.
>>>>>>=20
>>>>>> -->
>>>>>=20
>>>>> Yes, please.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 17) <!-- [rfced] Throughout: We have removed the section titles =
and linked the=20
>>>>>> section numbers directly to the section of the RFC specified.  =
For example, the=20
>>>>>> text has been updated as follows:=20
>>>>>>=20
>>>>>> Original:
>>>>>> *  The whole of "6.1.1 TCP Initialization" of [RFC3168] is =
updated by
>>>>>>  Section 3.1 of the present specification.
>>>>>>=20
>>>>>> Current:
>>>>>> *  The whole of Section 6.1.1 of [RFC3168] is updated by Section =
3.1
>>>>>>  of the present specification.
>>>>>>=20
>>>>>> In the HTML and PDF files, "Section 6.1.1 links to Section 6.1.1 =
of RFC 3168. =20
>>>>>> Please review and let us know if you prefer the section titles be =
included.=20
>>>>>> -->
>>>>>=20
>>>>> This is fine.
>>>>>>=20
>>>>>>=20
>>>>>> 18) <!-- [rfced] We are unclear why "potentially updates" is =
mentioned here.  Is=20
>>>>>> it mentioned to cover implementations of RFC 3168 have not been =
updated yet and/or=20
>>>>>> potential future updates?  Otherwise, may it be cut?=20
>>>>>>=20
>>>>>> 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".
>>>>>> -->
>>>>>=20
>>>>> RFC8311 says in some parts that it explicitly doesn=E2=80=99t =
update RFC3168 because a new experimental RFC should do that instead but =
it provided the =E2=80=9Clegitimacy" to update=E2=80=A6 this is a weird =
thing anyway but I agree that probably saying =E2=80=9Cpotentially =
updates=E2=80=9D doesn=E2=80=99t help either. I=E2=80=99d be okay to =
simply remove that.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 19) <!-- [rfced] As we believe "pressure" refers to options vying =
for limited=20
>>>>>> space, perhaps this update would be more clear?=20
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Perhaps:
>>>>>> Because option space is limited, Section 3.2.3.3 provides =
guidance on=20
>>>>>> how important it is to send an AccECN Option relative to other =
options
>>>>>> and specifies which fields are more important to include.=20
>>>>>> -->  =20
>>>>>=20
>>>>> Okay for me.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 20) <!-- [rfced] Please confirm "experimental" is correct here.  =
We ask because=20
>>>>>> RFC 7713 is an Informational RFC.
>>>>>>=20
>>>>>> Original:
>>>>>>  ConEx is an experimental change to the Data Sender that would be
>>>>>>  most useful when combined with AccECN.
>>>>>> -->
>>>>>=20
>>>>> Yes, rfc7731 in informational but that's only explains the =
architecture. But the protocol documents RFC7837 and RFC7786 are =
experimental.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 21) <!-- [rfced] We have updated the registry title per the note =
below=20
>>>>>> from IANA.  While draft-ietf-tsvwg-udp-options has not yet been =
published,=20
>>>>>> this title matches what currently appears on the IANA site. =
Please let us=20
>>>>>> know any concerns. =20
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Original:=20
>>>>>> 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.
>>>>>> -->
>>>>>>=20
>>>>> Yes, thanks!
>>>>>=20
>>>>>>=20
>>>>>> 22) <!-- [rfced] Please consider whether the placement of B at =
the end=20
>>>>>> of the sentence is correct.
>>>>>>=20
>>>>>> Original:=20
>>>>>> This opens up a potential covert channel of up to 29B (40 -
>>>>>> (2+3*3)) B.=20
>>>>>> -->
>>>>>=20
>>>>> Yes, please remove the last B
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 23) <!-- [rfced] This sentence reads a bit awkwardly.  Perhaps =
this can=20
>>>>>> be rephrased?=20
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Perhaps:
>>>>>> Currently, there is no known way for a receiver to take
>>>>>> advantage of this behaviour, which seems to always degrade its =
own
>>>>>> performance.
>>>>>> -->
>>>>>=20
>>>>> Yes, thanks
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 24) <!-- [rfced] Instead of "show up more easily", perhaps "be =
more=20
>>>>>> easily identified" would improve readability?=20
>>>>>>=20
>>>>>> 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.
>>>>>> -->
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 25) <!-- [rfced] We have updated the text as shown below.  Please =
let us=20
>>>>>> know any concerns.=20
>>>>>>=20
>>>>>> Original:
>>>>>> However, it is expected that this option will become
>>>>>> available in operating systems over time, and eventually turned =
on by
>>>>>> default in them.
>>>>>>=20
>>>>>> Current:
>>>>>> However, it is expected that AccECN will become
>>>>>> available in operating systems over time and that it will =
eventually=20
>>>>>> be turned on by default.=20
>>>>>> -->
>>>>>=20
>>>>> Yes.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 26) <!-- [rfced] [RoCEv2]
>>>>>> Please review. We could not confirm the Volume or Release number =
for
>>>>>> this reference. Note that there is information at the current URL =
which mentions
>>>>>> "Volume 1 Release 1.8" (see: =
https://www.infinibandta.org/wp-content/uploads/2024/09/IBTA-Overview-of-I=
BTA-Volume-1-Release-1.8.pdf).
>>>>>>=20
>>>>>> 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?
>>>>>>=20
>>>>>> Current:
>>>>>>=20
>>>>>> [RoCEv2]   InfiniBand Trade Association, "InfiniBand Architecture
>>>>>>          Specification", Volume 1, Release 1.4, 2020,
>>>>>>          <https://www.infinibandta.org/ibta-specification/>.
>>>>>>=20
>>>>>> Perhaps:
>>>>>>=20
>>>>>> [RoCEv2]   InfiniBand Trade Association, "InfiniBand Architecture
>>>>>>          Specification",
>>>>>>          <https://www.infinibandta.org/ibta-specification/>.
>>>>>>=20
>>>>>> OR=20
>>>>>>=20
>>>>>> [RoCEv2]   InfiniBand Trade Association, "InfiniBand Architecture
>>>>>>          Specification", Volume 1, Release 1.8, July 2024,
>>>>>>          <https://www.infinibandta.org/ibta-specification/>.
>>>>>>=20
>>>>>> -->
>>>>>=20
>>>>> Please use the version-less reference.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 27) <!-- [rfced] May we update "implement" to "satisfy" to =
clarify the text and=20
>>>>>> avoid "implementers implement"?
>>>>>>=20
>>>>>> Original:
>>>>>> However, implementers are free to choose other ways
>>>>>> to implement the requirements.
>>>>>> -->
>>>>>=20
>>>>> Okay.
>>>>>=20
>>>>>>=20
>>>>>> 28) <!-- [rfced] The following note was included in the XML. =20
>>>>>>=20
>>>>>>  ToDo: Note to RFC Editor: Pls change all bare <artwork> elements =
(without=20
>>>>>> any keywords like align) to <sourcecode>.
>>>>>> Reason My XML editor doesn't support the <sourcecode> element, so =
it mangles line=20
>>>>>> breaks within sourcecode, ignoring even CDATA protection.
>>>>>>=20
>>>>>> We have updated the XML file as noted.  Please let us know how/if =
he "type"=20
>>>>>> attribute of each sourcecode element should be set. Perhaps =
some/all should be=20
>>>>>> marked as pseudocode? =20
>>>>>> If the current list of preferred values for "type"
>>>>>> =
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=3Dsourcecode-types)
>>>>>> does not contain an applicable type, then feel free to let us =
know.
>>>>>> Also, it is acceptable to leave the "type" attribute not set.
>>>>>> -->
>>>>>=20
>>>>> Yes, I think pseudocode should be fine for all artwork in the =
appendix.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 29) <!-- [rfced] We are having trouble parsing this sentence.  =
Where does the=20
>>>>>> "which" statement end - after "full-sized"?  Does "it" refer to =
the algorithm?=20
>>>>>>=20
>>>>>> 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.=20
>>>>>> -->
>>>>>=20
>>>>> Yes and yes. Which ends after =E2=80=9Cfull-sized=E2=80=9D and it =
is the algorithm.
>>>>>>=20
>>>>>>=20
>>>>>> 30) <!-- [rfced] May we change "works out" to "indicates" or =
"determines"?=20
>>>>>>=20
>>>>>> Original:
>>>>>> The above formula works out that it
>>>>>> would still be safe to assume 2 CE marks (because 9 - ((9-2) % 8) =
=3D
>>>>>> 2).
>>>>>> -->
>>>>>=20
>>>>> =E2=80=9Cindicates=E2=80=9D is fine.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 31) <!-- [rfced] Does "5% of full-sized" mean segments are "5% of =
their full=20
>>>>>> size"?  May we change "as long as" to "while" for readability?=20
>>>>>>=20
>>>>>> 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.
>>>>>> -->
>>>>>=20
>>>>> Not of =E2=80=9Ctheir=E2=80=9D full-size but 5% of a full-sized =
packet.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 32) <!-- [rfced] We updated the text to point directly to Section =
3.2.2.5.2=20
>>>>>> (where the quoted text appears).  Please let us know any =
concerns.=20
>>>>>>=20
>>>>>> 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".
>>>>>> -->
>>>>>=20
>>>>> Okay.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 33) <!-- [rfced] We are having trouble parsing "will consider =
d.cep can replace". =20
>>>>>> Please clarify.=20
>>>>>>=20
>>>>>> 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:
>>>>>>=20
>>>>>> Perhaps:
>>>>>> The chart below shows when the above algorithm will consider the =
number=20
>>>>>> of CE-marked packets as a safe enough estimate to replace =
dsafer.cep=20
>>>>>> with d.cep.=20
>>>>>> -->
>>>>>=20
>>>>> I think this should have been:
>>>>>=20
>>>>> 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:
>>>>>=20
>>>>> Or this might be more clear (?):
>>>>>=20
>>>>> 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:
>>>>>=20
>>>>> Or I guess we can simplify a bit and remove the word consider:
>>>>>=20
>>>>> 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:
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 34) <!-- [rfced] To what does "this" refer - the ACK?  The =
sentence prior is=20
>>>>>> included for context.=20
>>>>>>=20
>>>>>> 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.
>>>>>> -->
>>>>>=20
>>>>> convert the number of CE markings into an estimated CE-marked =
bytes
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 35) <!-- [rfced] Does "earlier versions" refer to earlier draft =
versions of this=20
>>>>>> document?=20
>>>>>>=20
>>>>>> Original:
>>>>>> This development consumed the remaining 2 codepoints
>>>>>> on the SYN/ACK that had been reserved for future use by AccECN in
>>>>>> earlier versions.
>>>>>> -->
>>>>>=20
>>>>> Yes earlier version of the protocol defined in earlier versions of =
this document.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 36) <!-- [rfced] Please review the following terminology-related =
questions.=20
>>>>>>=20
>>>>>> A) We updated the following to the form on the right.  Please let =
us know if any=20
>>>>>> corrections are needed.=20
>>>>>>=20
>>>>>> not-ECT vs Not-ECT
>>>>>> no ECN vs No ECN=20
>>>>>> 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
>>>>>=20
>>>>> I think this should be IP ECN field. It=E2=80=99s also TCP ECN =
flag.
>>>>>=20
>>>>>> 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.=20
>>>>>> time-out vs timeout=20
>>>>>>=20
>>>>>> CE mark* vs CE-mark* - updated to use the hyphen when acting as =
an adjective=20
>>>>>> appearing before the noun
>>>>>>=20
>>>>>>=20
>>>>>> B) Please review occurrences of the terms below and let us know =
if/how they may=20
>>>>>> be made consistent. =20
>>>>>>=20
>>>>>> TCP Option vs TCP option (perhaps TCP Option when referring to a =
specific option?)
>>>>>=20
>>>>> TCP Option aligns with RFC9293. I would use that everywhere.
>>>>>=20
>>>>>>=20
>>>>>> Established state  vs established state vs ESTABLISHED state
>>>>>=20
>>>>> Yes, let=E2=80=99s aways use ESTABLISHED state as in RFC9293.
>>>>>=20
>>>>>>=20
>>>>>> half connection vs half-connection
>>>>>=20
>>>>> Let's go for half-connection.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> C) We note that "time-stamp" is used consistently.  However, RFC =
7323 uses "timestamp".  May we update the text for consistency?
>>>>>=20
>>>>> Yes, please use timestamp.
>>>>>=20
>>>>>>=20
>>>>>> -->
>>>>>>=20
>>>>>>=20
>>>>>> 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=20
>>>>>> content that is semantically less important or tangential to the=20=

>>>>>> content that surrounds it" =
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
>>>>>> -->
>>>>>=20
>>>>> You mean everything that starts with =E2=80=9CNote.=E2=80=9D? =
Would that be different displayed? I think I would prefer to not display =
it differently than other text.
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> 38) <!-- [rfced] Some author comments are present in the XML. =
Please confirm=20
>>>>>> that no updates related to these comments are outstanding. Note =
that the
>>>>>> comments will be deleted prior to publication.
>>>>>> -->
>>>>>=20
>>>>> Richard and Bob would need to double-check this.
>>>>>=20
>>>>>>=20
>>>>>> 39) <!-- [rfced] Please review the "Inclusive Language" portion =
of the online           =20
>>>>>> Style Guide =
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>       =20=

>>>>>> and let us know if any changes are needed.  Updates of this =
nature typically        =20
>>>>>> result in more precise language, which is helpful for readers.    =
                  =20
>>>>>>=20
>>>>>> Note that our script did not flag any words in particular, but =
this should          =20
>>>>>> still be reviewed as a best practice.                             =
                  =20
>>>>>> -->
>>>>>=20
>>>>> Thanks!
>>>>> Mirja
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Thank you.
>>>>>>=20
>>>>>> RFC Editor
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Aug 12, 2025, at 12:31 PM, rfc-editor@rfc-editor.org wrote:
>>>>>>=20
>>>>>> *****IMPORTANT*****
>>>>>>=20
>>>>>> Updated 2025/08/12
>>>>>>=20
>>>>>> RFC Author(s):
>>>>>> --------------
>>>>>>=20
>>>>>> Instructions for Completing AUTH48
>>>>>>=20
>>>>>> Your document has now entered AUTH48.  Once it has been reviewed =
and=20
>>>>>> approved by you and all coauthors, it will be published as an =
RFC. =20
>>>>>> If an author is no longer available, there are several remedies=20=

>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>>>>=20
>>>>>> You and you coauthors are responsible for engaging other parties=20=

>>>>>> (e.g., Contributors or Working Group) as necessary before =
providing=20
>>>>>> your approval.
>>>>>>=20
>>>>>> Planning your review=20
>>>>>> ---------------------
>>>>>>=20
>>>>>> Please review the following aspects of your document:
>>>>>>=20
>>>>>> *  RFC Editor questions
>>>>>>=20
>>>>>> Please review and resolve any questions raised by the RFC Editor=20=

>>>>>> that have been included in the XML file as comments marked as=20
>>>>>> follows:
>>>>>>=20
>>>>>> <!-- [rfced] ... -->
>>>>>>=20
>>>>>> These questions will also be sent in a subsequent email.
>>>>>>=20
>>>>>> *  Changes submitted by coauthors=20
>>>>>>=20
>>>>>> Please ensure that you review any changes submitted by your=20
>>>>>> coauthors.  We assume that if you do not speak up that you=20
>>>>>> agree to changes submitted by your coauthors.
>>>>>>=20
>>>>>> *  Content=20
>>>>>>=20
>>>>>> Please review the full content of the document, as this cannot=20
>>>>>> change once the RFC is published.  Please pay particular =
attention to:
>>>>>> - IANA considerations updates (if applicable)
>>>>>> - contact information
>>>>>> - references
>>>>>>=20
>>>>>> *  Copyright notices and legends
>>>>>>=20
>>>>>> Please review the copyright notice and legends as defined in
>>>>>> RFC 5378 and the Trust Legal Provisions=20
>>>>>> (TLP =E2=80=93 https://trustee.ietf.org/license-info).
>>>>>>=20
>>>>>> *  Semantic markup
>>>>>>=20
>>>>>> Please review the markup in the XML file to ensure that elements =
of =20
>>>>>> content are correctly tagged.  For example, ensure that =
<sourcecode>=20
>>>>>> and <artwork> are set correctly.  See details at=20
>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>>>=20
>>>>>> *  Formatted output
>>>>>>=20
>>>>>> Please review the PDF, HTML, and TXT files to ensure that the=20
>>>>>> formatted output, as generated from the markup in the XML file, =
is=20
>>>>>> reasonable.  Please note that the TXT will have formatting=20
>>>>>> limitations compared to the PDF and HTML.
>>>>>>=20
>>>>>>=20
>>>>>> Submitting changes
>>>>>> ------------------
>>>>>>=20
>>>>>> To submit changes, please reply to this email using =E2=80=98REPLY =
ALL=E2=80=99 as all=20
>>>>>> the parties CCed on this message need to see your changes. The =
parties=20
>>>>>> include:
>>>>>>=20
>>>>>> *  your coauthors
>>>>>>=20
>>>>>> *  rfc-editor@rfc-editor.org (the RPC team)
>>>>>>=20
>>>>>> *  other document participants, depending on the stream (e.g.,=20
>>>>>>  IETF Stream participants are your working group chairs, the=20
>>>>>>  responsible ADs, and the document shepherd).
>>>>>>=20
>>>>>> *  auth48archive@rfc-editor.org, which is a new archival mailing =
list=20
>>>>>>  to preserve AUTH48 conversations; it is not an active discussion=20=

>>>>>>  list:
>>>>>>=20
>>>>>> *  More info:
>>>>>>    =
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P=
8O4Zc
>>>>>>=20
>>>>>> *  The archive itself:
>>>>>>    https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>>=20
>>>>>> *  Note: If only absolutely necessary, you may temporarily opt =
out=20
>>>>>>    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=20
>>>>>>    have dropped the address. When the discussion is concluded,=20
>>>>>>    auth48archive@rfc-editor.org will be re-added to the CC list =
and=20
>>>>>>    its addition will be noted at the top of the message.=20
>>>>>>=20
>>>>>> You may submit your changes in one of two ways:
>>>>>>=20
>>>>>> An update to the provided XML file
>>>>>> =E2=80=94 OR =E2=80=94
>>>>>> An explicit list of changes in this format
>>>>>>=20
>>>>>> Section # (or indicate Global)
>>>>>>=20
>>>>>> OLD:
>>>>>> old text
>>>>>>=20
>>>>>> NEW:
>>>>>> new text
>>>>>>=20
>>>>>> You do not need to reply with both an updated XML file and an =
explicit=20
>>>>>> list of changes, as either form is sufficient.
>>>>>>=20
>>>>>> 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,=20
>>>>>> and technical changes.  Information about stream managers can be =
found in=20
>>>>>> the FAQ.  Editorial changes do not require approval from a stream =
manager.
>>>>>>=20
>>>>>>=20
>>>>>> Approving for publication
>>>>>> --------------------------
>>>>>>=20
>>>>>> To approve your RFC for publication, please reply to this email =
stating
>>>>>> that you approve this RFC for publication.  Please use =E2=80=98REP=
LY ALL=E2=80=99,
>>>>>> as all the parties CCed on this message need to see your =
approval.
>>>>>>=20
>>>>>>=20
>>>>>> Files=20
>>>>>> -----
>>>>>>=20
>>>>>> The files are available here:
>>>>>> https://www.rfc-editor.org/authors/rfc9768.xml
>>>>>> https://www.rfc-editor.org/authors/rfc9768.html
>>>>>> https://www.rfc-editor.org/authors/rfc9768.pdf
>>>>>> https://www.rfc-editor.org/authors/rfc9768.txt
>>>>>>=20
>>>>>> Diff file of the text:
>>>>>> https://www.rfc-editor.org/authors/rfc9768-diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html (side by =
side)
>>>>>>=20
>>>>>> Diff of the XML:=20
>>>>>> https://www.rfc-editor.org/authors/rfc9768-xmldiff1.html
>>>>>>=20
>>>>>>=20
>>>>>> Tracking progress
>>>>>> -----------------
>>>>>>=20
>>>>>> The details of the AUTH48 status of your document are here:
>>>>>> https://www.rfc-editor.org/auth48/rfc9768
>>>>>>=20
>>>>>> Please let us know if you have any questions. =20
>>>>>>=20
>>>>>> Thank you for your cooperation,
>>>>>>=20
>>>>>> RFC Editor
>>>>>>=20
>>>>>> --------------------------------------
>>>>>> RFC 9768 (draft-ietf-tcpm-accurate-ecn-34)
>>>>>>=20
>>>>>> Title            : More Accurate Explicit Congestion Notification =
(AccECN) Feedback in TCP
>>>>>> Author(s)        : B. Briscoe, M. K=C3=BChlewind, R. =
Scheffenegger
>>>>>> WG Chair(s)      : Yoshifumi Nishida, Michael T=C3=BCxen
>>>>>>=20
>>>>>> Area Director(s) : Gorry Fairhurst, Mike Bishop
>>>>=20
>>>=20
>>=20
>=20