Hi Mirja,
Thanks for your close review and the explanations provided. We have updated
the document as described below.
We will wait to hear from Richard and/or Bob regarding this the author comments
in the XML file. In addition, this question should have been included
previously. Please let us know if any updates are desired.
<!-- [rfced] Will "rights and obligations" be commonly understood in this
context? We only
see it used in RFC 3647, and it appears as part of quoted text there.
Section 3.1.1 original:
Once in AccECN mode, a TCP Client or Server has the rights and
obligations to participate in the ECN protocol defined in
Section 3.1.5.
Section 3.1.5 original:
An implementation that supports AccECN has the rights and obligations
concerning the use of ECN defined below, which update those in
Section 6.1.1 of [RFC3168].
-->
The current files are available here:
https://www.rfc-editor.org/authors/rfc9768.xml
https://www.rfc-editor.org/authors/rfc9768.txt
https://www.rfc-editor.org/authors/rfc9768.pdf
https://www.rfc-editor.org/authors/rfc9768.html
AUTH48 diffs:
https://www.rfc-editor.org/authors/rfc9768-auth48diff.html
https://www.rfc-editor.org/authors/rfc9768-auth48rfcdiff.html (side by side)
Comprehensive diffs:
https://www.rfc-editor.org/authors/rfc9768-diff.html
https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html (side by side)
Please review and let us know if further updates are needed.
Thank you,
Sandy Ginoza
RFC Production Center
> On Aug 14, 2025, at 8:05 AM, Mirja Kuehlewind (IETF) <[email protected]>
> wrote:
>
> Hi all,
>
> Please see inline.
>
>> On 12. Aug 2025, at 21:38, [email protected] wrote:
>>
>> Authors,
>>
>> While reviewing this document during AUTH48, please resolve (as necessary)
>> the following questions, which are also in the XML file.
>>
>> 1) <!-- [rfced] Because these documents are defined in Informational RFCs,
>> is "proposed" needed here?
>>
>> Original:
>> Recently, proposed mechanisms like Congestion Exposure (ConEx
>> [RFC7713]), DCTCP [RFC8257] or L4S [RFC9330] need to know when more
>> than one marking is received in one RTT, which is information that
>> cannot be provided by the feedback scheme as specified in [RFC3168].
>>
>> Perhaps:
>> Newer mechanisms like Congestion Exposure (ConEx
>> [RFC7713]), DCTCP [RFC8257], or L4S [RFC9330] ...
>>
>> Or perhaps, "More recently defined mechanisms ..."
>> -->
>
> I’d prefer "More recently defined”. I think that’s what was meant here
> anyway; the comma seems wrong.
>
>>
>>
>> 2) <!-- [rfced] We are having trouble parsing "extent of congestion
>> notification". Perhaps this means "indicate the amount of congestion over
>> the round trip"? Please clarify.
>>
>> Original:
>> Or, unlike Reno or
>> CUBIC, AccECN can be used to respond to the extent of congestion
>> notification over a round trip, as for example DCTCP does in
>> controlled environments [RFC8257].
>> -->
>
> NEW
> Or, unlike as done by Reno or
> CUBIC, AccECN can be used to respond to the actual number of congestion
> Notifications received over a round trip, as for example DCTCP does in
> controlled environments [RFC8257].
>
>>
>>
>> 3) <!-- [rfced] Because "Reserved combination" is not used much, would it
>> help the reader to add a pointer - perhaps to table 2?
>>
>> Original:
>> All these requirements ensure that future uses of all the Reserved
>> combinations on a SYN or SYN/ACK can rely on consistent behaviour
>> from the installed base of AccECN implementations. See Appendix B.3
>> for related discussion.
>> -->
>
> Yes, adding a point to the table is good.
>>
>>
>> 4) <!-- [rfced] Should a second closing parens appear after "congestion)"?
>>
>> Original:
>> Implementers MAY use other fall-back strategies if they are found to
>> be more effective (e.g., attempting to negotiate AccECN on the SYN
>> only once or more than twice (most appropriate during high levels of
>> congestion).
>> -->
>
> Yes, please add another closing parens.
>
>>
>>
>> 5) <!-- [rfced] We are unsure what "try it without" refers to here. Is it
>> "advisable to experiment without using the ECT on a SYN"?
>>
>> Original (sentence prior included for context):
>> Further it might make sense to also remove any other new or
>> experimental fields or options on the SYN in case a middlebox might
>> be blocking them, although the required behaviour will depend on the
>> specification of the other option(s) and any attempt to co-ordinate
>> fall-back between different modules of the stack. For instance, even
>> if taking part in an [RFC8311] experiment that allows ECT on a SYN,
>> it would be advisable to try it without.
>> -->
>
>
> NEW
> For instance,
> if taking part in an [RFC8311] experiment that allows ECT on a SYN,
> it would be advisable to have a fall-back strategy that tries use of AccECN
> without
> setting ETC on SYN.
>
>>
>>
>> 6) <!-- [rfced] Throughout, some of the bulleted lists use a mix of periods
>> and
>> semicolons to close the item - some within the same list. Please consider
>> whether
>> these may be updated for consistency. We recommend using terminating
>> periods,
>> unless the goal is to clarify an "and" or "or" connection between the list
>> items.
>> Please review.
>> -->
>
> Yes, this should be unified. I’d be okay with terminating periods.
>
>>
>>
>> 7) <!-- [rfced] For clarity, we'd like to add quotes to "handshake
>> encoding".
>> Please confirm this is correct, as opposed to "handshake encoding of the ACE
>> field".
>>
>> Original:
>> This shall be called the handshake encoding of the ACE
>> field, and it is the only exception to the rule that the ACE field
>> carries the 3 least significant bits of the r.cep counter on packets
>> with SYN=0.
>> -->
>
> Yes, this should be only "handshake encoding”. However, I’m not sure if the
> quotes are really needed.
>
>>
>>
>> 8) <!-- [rfced] For readability, may we break this text into two sentences?
>>
>> Original:
>> When an AccECN Server in SYN-RCVD state receives a pure ACK with
>> SYN=0 and no SACK blocks, instead of treating the ACE field as a
>> counter, it MUST infer the meaning of each possible value of the ACE
>> field from Table 4, which also shows the value that an AccECN Server
>> MUST set s.cep to as a result.
>>
>> Perhaps:
>> When an AccECN Server in SYN-RCVD state receives a pure ACK with
>> SYN=0 and no SACK blocks, it MUST infer the meaning of each possible
>> value of the ACE field from Table 4 instead of treating the ACE field
>> as a counter. Table 4 also shows the value to which an AccECN Server
>> MUST set s.cep as a result.
>> -->
>
> Given these are two normative statement let’s rather do it this way:
>
> NEW
> When an AccECN Server in SYN-RCVD state receives a pure ACK with
> SYN=0 and no SACK blocks, it MUST infer the meaning of each possible
> value of the ACE field from Table 4 instead of treating the ACE field
> as a counter. As a result, an AccECN Server
> MUST set s.cep to the respective value also shown in Table 4.
>
>
>>
>>
>> 9) <!-- [rfced] We are unclear what "it" refers to in the following.
>> Perhaps "it"
>> can be deleted?
>>
>> Original:
>> Given this encoding of the ACE field on the ACK of a SYN/ACK is
>> exceptional, an AccECN Server using large receive offload (LRO) might
>> prefer to disable LRO until such an ACK has transitioned it out of
>> SYN-RCVD state.
>> -->
>
> No it is not correct to remove the “it". “It” is the server. A longer version
> of the text would be:
>
> Given this encoding of the ACE field on the ACK of a SYN/ACK is
> exceptional, an AccECN Server using large receive offload (LRO) might
> prefer to disable LRO until the ACK of the SYN/ACK was sent and
> it has transitioned out of SYN-RCVD state.
>
>>
>>
>> 10) <!-- [rfced] We converted the notes following Table 4 into a list for
>> clarity.
>> Please let us know if you have any concerns.
>> -->
>
> That’s okay.
>
>>
>>
>> 11) <!-- [rfced] We are having trouble parsing "depend on experience of the
>> most
>> likely scenarios". Does it depend on how good the experience is, the
>> outcome,
>> etc? Please consider whether this text can be clarified.
>>
>> Original:
>> This advice is not stated normatively (in capitals), because the best
>> strategy might depend on experience of the most likely scenarios,
>> which can only be known at the time of deployment.
>> -->
>
> I think we can do the following:
>
> NEW
> This advice is not stated normatively (in capitals), because the best
> strategy might depend on the likelihood to experience these scenarios,
> which can only be known at the time of deployment.
>
>
>>
>>
>> 12) <!-- [rfced] Where is "below these bullets", as we don't see a
>> bulletized list
>> in Section 3.2.2.5.1? If possible, we recommend adding a pointer for
>> clarity.
>>
>> Original:
>> Even though this rule is stated as a "SHOULD", it is important for
>> a transition to trigger an ACK if at all possible, The only valid
>> exception to this rule is given below these bullets.
>> -->
>
> Maybe let’s do it that way:
>
> NEW
> Even though this rule is stated as a "SHOULD", it is important for
> a transition to trigger an ACK if at all possible, The only valid
> exception to this rule is due to large receive offload (LRO) or
> generic receive offload (GRO) as further described below.
>
>
>>
>>
>> 13) <!-- [rfced] For ease of the reader, we suggest adding a pointer to the
>> examples.
>>
>> Original:
>> Recommended Simple Scheme: The Data Receiver SHOULD include an
>> AccECN TCP Option on every scheduled ACK if any byte counter has
>> incremented since the last ACK. Whenever possible, it SHOULD
>> include a field for every byte counter that has changed at some
>> time during the connection (see examples later).
>> -->
>
> It’s just in the text later in the same section. Not sure how to adda pointer
> here. I also don’t think this is needed.
>
>>
>>
>> 14) <!-- [rfced] Mention of BCP 69 was removed to the HTML and PDF could
>> link
>> directly to Section 5.2.1 of RFC 3449. Would you prefer that BCP 69 be
>> included
>> as the cite tag?
>>
>> Original:
>> Section 5.2.1 of BCP 69 [RFC3449] gives best current practice on
>> filtering (aka. thinning or coalescing) of pure TCP ACKs.
>>
>> Perhaps:
>> Section 5.2.1 of RFC 3449 [BCP69] gives best current practice on
>> filtering (aka thinning or coalescing) of pure TCP ACKs.
>> -->
>
> Please aline this with whatever the normal practice is supposed to be now. I
> don’t have a real opinion here.
>
>>
>>
>> 15) <!-- [rfced] Does "even if it is" refer to using AccECN without ECN++
>> or with
>> ECN++?
>>
>> Original:
>> However, it might omit some AccECN ACKs, because
>> AccECN can be used without ECN++ and even if it is, ECN++ does not
>> have to make pure ACKs ECN-capable - only deployment experience
>> will tell.
>>
>> Perhaps:
>> However, it might omit some AccECN ACKs because
>> AccECN can be used without ECN++. Even if ECN++ is used, it does not
>> have to make pure ACKs ECN-capable - only deployment experience
>> will tell.
>> -->
>
> If we split up in two sentences, I this this would be maybe better:
>
> However, it might omit some AccECN ACKs because
> AccECN can be used without ECN++. Even if ECN++ is used, pure ACKs
> do not necessarily have to be marked as ECN-capable - only deployment
> experience
> will tell.
>
>>
>>
>> 16) <!-- [rfced] Instead of using [RFC3168] as an adjective, may we update
>> this
>> text to refer to "Classic ECN"?
>>
>> Original:
>> One way around this could be to only negotiate for Accurate ECN, but
>> not offer a fall back to [RFC3168] ECN.
>>
>> Perhaps:
>> One way around this could be to only negotiate for Accurate ECN, but
>> not offer a fall back to Classic ECN [RFC3168].
>>
>> Original:
>> For LRO in the receive direction, a different issue may get exposed
>> with [RFC3168] ECN supporting hardware.
>>
>> Perhaps:
>> For LRO in the receive direction, a different issue may get exposed
>> with Classic-ECN [RFC3168] supporting hardware.
>>
>> -->
>
> Yes, please.
>
>>
>>
>> 17) <!-- [rfced] Throughout: We have removed the section titles and linked
>> the
>> section numbers directly to the section of the RFC specified. For example,
>> the
>> text has been updated as follows:
>>
>> Original:
>> * The whole of "6.1.1 TCP Initialization" of [RFC3168] is updated by
>> Section 3.1 of the present specification.
>>
>> Current:
>> * The whole of Section 6.1.1 of [RFC3168] is updated by Section 3.1
>> of the present specification.
>>
>> In the HTML and PDF files, "Section 6.1.1 links to Section 6.1.1 of RFC
>> 3168.
>> Please review and let us know if you prefer the section titles be included.
>> -->
>
> This is fine.
>>
>>
>> 18) <!-- [rfced] We are unclear why "potentially updates" is mentioned here.
>> Is
>> it mentioned to cover implementations of RFC 3168 have not been updated yet
>> and/or
>> potential future updates? Otherwise, may it be cut?
>>
>> Original:
>> It will be noted that RFC 8311 already updates, or potentially
>> updates, a number of the requirements in "6.1.2. The TCP Sender".
>> -->
>
> RFC8311 says in some parts that it explicitly doesn’t update RFC3168 because
> a new experimental RFC should do that instead but it provided the
> “legitimacy" to update… this is a weird thing anyway but I agree that
> probably saying “potentially updates” doesn’t help either. I’d be okay to
> simply remove that.
>
>>
>>
>> 19) <!-- [rfced] As we believe "pressure" refers to options vying for
>> limited
>> space, perhaps this update would be more clear?
>>
>> Original:
>> When option space is under pressure from other options,
>> Section 3.2.3.3 provides guidance on how important it is to send an
>> AccECN Option relative to other options, and which fields are more
>> important to include.
>>
>> Perhaps:
>> Because option space is limited, Section 3.2.3.3 provides guidance on
>> how important it is to send an AccECN Option relative to other options
>> and specifies which fields are more important to include.
>> -->
>
> Okay for me.
>
>>
>>
>> 20) <!-- [rfced] Please confirm "experimental" is correct here. We ask
>> because
>> RFC 7713 is an Informational RFC.
>>
>> Original:
>> ConEx is an experimental change to the Data Sender that would be
>> most useful when combined with AccECN.
>> -->
>
> Yes, rfc7731 in informational but that's only explains the architecture. But
> the protocol documents RFC7837 and RFC7786 are experimental.
>
>>
>>
>> 21) <!-- [rfced] We have updated the registry title per the note below
>> from IANA. While draft-ietf-tsvwg-udp-options has not yet been published,
>> this title matches what currently appears on the IANA site. Please let us
>> know any concerns.
>>
>> NOTE: The name of the registry called "TCP Experimental Option Experiment
>> Identifiers (TCP ExIDs)" in the IANA Considerations section has been changed
>> to "TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)," per
>> draft-ietf-tsvwg-udp-options-45.
>>
>> Original:
>> Early experimental implementations of the two AccECN Options used
>> experimental option 254 per [RFC6994] with the 16-bit magic numbers
>> 0xACC0 and 0xACC1 respectively for Order 0 and 1, as allocated in the
>> IANA "TCP Experimental Option Experiment Identifiers (TCP ExIDs)"
>> registry.
>> -->
>>
> Yes, thanks!
>
>>
>> 22) <!-- [rfced] Please consider whether the placement of B at the end
>> of the sentence is correct.
>>
>> Original:
>> This opens up a potential covert channel of up to 29B (40 -
>> (2+3*3)) B.
>> -->
>
> Yes, please remove the last B
>
>>
>>
>> 23) <!-- [rfced] This sentence reads a bit awkwardly. Perhaps this can
>> be rephrased?
>>
>> Original:
>> No known way can yet be contrived for a receiver to take
>> advantage of this behaviour, which seems to always degrade its own
>> performance.
>>
>> Perhaps:
>> Currently, there is no known way for a receiver to take
>> advantage of this behaviour, which seems to always degrade its own
>> performance.
>> -->
>
> Yes, thanks
>
>>
>>
>> 24) <!-- [rfced] Instead of "show up more easily", perhaps "be more
>> easily identified" would improve readability?
>>
>> Original:
>> A generic privacy concern of any new protocol is that for a while it
>> will be used by a small population of hosts, and thus show up more
>> easily.
>> -->
>
> Maybe:
> A generic privacy concern of any new protocol is that for a while it
> will be used by a small population of hosts, and thus those hosts could
> be more easily identified.
>
>
>>
>>
>> 25) <!-- [rfced] We have updated the text as shown below. Please let us
>> know any concerns.
>>
>> Original:
>> However, it is expected that this option will become
>> available in operating systems over time, and eventually turned on by
>> default in them.
>>
>> Current:
>> However, it is expected that AccECN will become
>> available in operating systems over time and that it will eventually
>> be turned on by default.
>> -->
>
> Yes.
>
>>
>>
>> 26) <!-- [rfced] [RoCEv2]
>> Please review. We could not confirm the Volume or Release number for
>> this reference. Note that there is information at the current URL which
>> mentions
>> "Volume 1 Release 1.8" (see:
>> https://www.infinibandta.org/wp-content/uploads/2024/09/IBTA-Overview-of-IBTA-Volume-1-Release-1.8.pdf).
>>
>> Would you like us to update this reference to Release 1.8, use a
>> version-less reference, or keep the Release 1.4 version of the reference?
>>
>> Current:
>>
>> [RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture
>> Specification", Volume 1, Release 1.4, 2020,
>> <https://www.infinibandta.org/ibta-specification/>.
>>
>> Perhaps:
>>
>> [RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture
>> Specification",
>> <https://www.infinibandta.org/ibta-specification/>.
>>
>> OR
>>
>> [RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture
>> Specification", Volume 1, Release 1.8, July 2024,
>> <https://www.infinibandta.org/ibta-specification/>.
>>
>> -->
>
> Please use the version-less reference.
>
>>
>>
>> 27) <!-- [rfced] May we update "implement" to "satisfy" to clarify the text
>> and
>> avoid "implementers implement"?
>>
>> Original:
>> However, implementers are free to choose other ways
>> to implement the requirements.
>> -->
>
> Okay.
>
>>
>> 28) <!-- [rfced] The following note was included in the XML.
>>
>> ToDo: Note to RFC Editor: Pls change all bare <artwork> elements
>> (without
>> any keywords like align) to <sourcecode>.
>> Reason My XML editor doesn't support the <sourcecode> element, so it mangles
>> line
>> breaks within sourcecode, ignoring even CDATA protection.
>>
>> We have updated the XML file as noted. Please let us know how/if he "type"
>> attribute of each sourcecode element should be set. Perhaps some/all should
>> be
>> marked as pseudocode?
>> If the current list of preferred values for "type"
>> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
>> does not contain an applicable type, then feel free to let us know.
>> Also, it is acceptable to leave the "type" attribute not set.
>> -->
>
> Yes, I think pseudocode should be fine for all artwork in the appendix.
>
>>
>>
>> 29) <!-- [rfced] We are having trouble parsing this sentence. Where does
>> the
>> "which" statement end - after "full-sized"? Does "it" refer to the
>> algorithm?
>>
>> Original:
>> However, we shall start
>> with the simplest algorithm, which assumes segments are all full-
>> sized and ultra-conservatively it assumes that ECN marking was 100%
>> on the forward path when ACKs on the reverse path started to all be
>> dropped.
>> -->
>
> Yes and yes. Which ends after “full-sized” and it is the algorithm.
>>
>>
>> 30) <!-- [rfced] May we change "works out" to "indicates" or "determines"?
>>
>> Original:
>> The above formula works out that it
>> would still be safe to assume 2 CE marks (because 9 - ((9-2) % 8) =
>> 2).
>> -->
>
> “indicates” is fine.
>
>>
>>
>> 31) <!-- [rfced] Does "5% of full-sized" mean segments are "5% of their full
>> size"? May we change "as long as" to "while" for readability?
>>
>> Original:
>> The simple algorithm for dSafer.cep above requires no monitoring of
>> prevailing conditions and it would still be safe if, for example,
>> segments were on average at least 5% of full-sized as long as ECN
>> marking was 5% or less.
>> -->
>
> Not of “their” full-size but 5% of a full-sized packet.
>
>>
>>
>> 32) <!-- [rfced] We updated the text to point directly to Section 3.2.2.5.2
>> (where the quoted text appears). Please let us know any concerns.
>>
>> Original:
>> If missing acknowledgement numbers arrive later (due to reordering),
>> Section 3.2.2.5 says "the Data Sender MAY attempt to neutralize the
>> effect of any action it took based on a conservative assumption that
>> it later found to be incorrect".
>> -->
>
> Okay.
>
>>
>>
>> 33) <!-- [rfced] We are having trouble parsing "will consider d.cep can
>> replace".
>> Please clarify.
>>
>> Original:
>> The chart below shows when the above algorithm will consider d.cep
>> can replace dSafer.cep as a safe enough estimate of the number of CE-
>> marked packets:
>>
>> Perhaps:
>> The chart below shows when the above algorithm will consider the number
>> of CE-marked packets as a safe enough estimate to replace dsafer.cep
>> with d.cep.
>> -->
>
> I think this should have been:
>
> NEW
> The chart below shows when the above algorithm will consider that d.cep
> can replace dSafer.cep as a safe enough estimate of the number of CE
> marked packets:
>
> Or this might be more clear (?):
>
> NEW
> The chart below shows when the above algorithm will consider
> d.cep as a safe enough estimate of the number of CE
> marked packets and replace dSafer.cep with it:
>
> Or I guess we can simplify a bit and remove the word consider:
>
> NEW
> The chart below shows when the above algorithm will
> replace dSafer.cep with d.cep as a safe enough estimate of the number of CE
> marked packets:
>
>
>>
>>
>> 34) <!-- [rfced] To what does "this" refer - the ACK? The sentence prior is
>> included for context.
>>
>> Original:
>> If AccECN Options are not available, the Data Sender can only decode
>> CE-marking from the ACE field in packets. Every time an ACK arrives,
>> to convert this into an estimate of CE-marked bytes, it needs an
>> average of the segment size, s_ave.
>> -->
>
> convert the number of CE markings into an estimated CE-marked bytes
>
>>
>>
>> 35) <!-- [rfced] Does "earlier versions" refer to earlier draft versions of
>> this
>> document?
>>
>> Original:
>> This development consumed the remaining 2 codepoints
>> on the SYN/ACK that had been reserved for future use by AccECN in
>> earlier versions.
>> -->
>
> Yes earlier version of the protocol defined in earlier versions of this
> document.
>
>>
>>
>> 36) <!-- [rfced] Please review the following terminology-related questions.
>>
>> A) We updated the following to the form on the right. Please let us know if
>> any
>> corrections are needed.
>>
>> not-ECT vs Not-ECT
>> no ECN vs No ECN
>> ECN Nonce vs ECN-Nonce vs ECN nonce (to match RFC 3540)
>> Cubic vs CUBIC (to match RFC 9438)
>> IP ECN field vs IP-ECN field
>
> I think this should be IP ECN field. It’s also TCP ECN flag.
>
>> ECN capable vs ECN-capable (to match RFC 3168, though we wonder if it should
>> be open (ECN capable) when not acting as an adjective appearing before then
>> noun.
>> time-out vs timeout
>>
>> CE mark* vs CE-mark* - updated to use the hyphen when acting as an adjective
>> appearing before the noun
>>
>>
>> B) Please review occurrences of the terms below and let us know if/how they
>> may
>> be made consistent.
>>
>> TCP Option vs TCP option (perhaps TCP Option when referring to a specific
>> option?)
>
> TCP Option aligns with RFC9293. I would use that everywhere.
>
>>
>> Established state vs established state vs ESTABLISHED state
>
> Yes, let’s aways use ESTABLISHED state as in RFC9293.
>
>>
>> half connection vs half-connection
>
> Let's go for half-connection.
>
>>
>>
>> C) We note that "time-stamp" is used consistently. However, RFC 7323 uses
>> "timestamp". May we update the text for consistency?
>
> Yes, please use timestamp.
>
>>
>> -->
>>
>>
>> 37) <!-- [rfced] Please review whether any of the notes in this document
>> should be in the <aside> element. It is defined as "a container for
>> content that is semantically less important or tangential to the
>> content that surrounds it"
>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
>> -->
>
> You mean everything that starts with “Note.”? Would that be different
> displayed? I think I would prefer to not display it differently than other
> text.
>
>>
>>
>> 38) <!-- [rfced] Some author comments are present in the XML. Please confirm
>> that no updates related to these comments are outstanding. Note that the
>> comments will be deleted prior to publication.
>> -->
>
> Richard and Bob would need to double-check this.
>
>>
>> 39) <!-- [rfced] Please review the "Inclusive Language" portion of the
>> online
>> Style Guide
>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>> and let us know if any changes are needed. Updates of this nature typically
>>
>> result in more precise language, which is helpful for readers.
>>
>>
>> Note that our script did not flag any words in particular, but this should
>>
>> still be reviewed as a best practice.
>>
>> -->
>
> Thanks!
> Mirja
>
>
>>
>>
>> Thank you.
>>
>> RFC Editor
>>
>>
>>
>> On Aug 12, 2025, at 12:31 PM, [email protected] wrote:
>>
>> *****IMPORTANT*****
>>
>> Updated 2025/08/12
>>
>> RFC Author(s):
>> --------------
>>
>> Instructions for Completing AUTH48
>>
>> Your document has now entered AUTH48. Once it has been reviewed and
>> approved by you and all coauthors, it will be published as an RFC.
>> If an author is no longer available, there are several remedies
>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>
>> You and you coauthors are responsible for engaging other parties
>> (e.g., Contributors or Working Group) as necessary before providing
>> your approval.
>>
>> Planning your review
>> ---------------------
>>
>> Please review the following aspects of your document:
>>
>> * RFC Editor questions
>>
>> Please review and resolve any questions raised by the RFC Editor
>> that have been included in the XML file as comments marked as
>> follows:
>>
>> <!-- [rfced] ... -->
>>
>> These questions will also be sent in a subsequent email.
>>
>> * Changes submitted by coauthors
>>
>> Please ensure that you review any changes submitted by your
>> coauthors. We assume that if you do not speak up that you
>> agree to changes submitted by your coauthors.
>>
>> * Content
>>
>> Please review the full content of the document, as this cannot
>> change once the RFC is published. Please pay particular attention to:
>> - IANA considerations updates (if applicable)
>> - contact information
>> - references
>>
>> * Copyright notices and legends
>>
>> Please review the copyright notice and legends as defined in
>> RFC 5378 and the Trust Legal Provisions
>> (TLP – https://trustee.ietf.org/license-info).
>>
>> * Semantic markup
>>
>> Please review the markup in the XML file to ensure that elements of
>> content are correctly tagged. For example, ensure that <sourcecode>
>> and <artwork> are set correctly. See details at
>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>
>> * Formatted output
>>
>> Please review the PDF, HTML, and TXT files to ensure that the
>> formatted output, as generated from the markup in the XML file, is
>> reasonable. Please note that the TXT will have formatting
>> limitations compared to the PDF and HTML.
>>
>>
>> Submitting changes
>> ------------------
>>
>> To submit changes, please reply to this email using ‘REPLY ALL’ as all
>> the parties CCed on this message need to see your changes. The parties
>> include:
>>
>> * your coauthors
>>
>> * [email protected] (the RPC team)
>>
>> * other document participants, depending on the stream (e.g.,
>> IETF Stream participants are your working group chairs, the
>> responsible ADs, and the document shepherd).
>>
>> * [email protected], which is a new archival mailing list
>> to preserve AUTH48 conversations; it is not an active discussion
>> list:
>>
>> * More info:
>>
>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>
>> * The archive itself:
>> https://mailarchive.ietf.org/arch/browse/auth48archive/
>>
>> * Note: If only absolutely necessary, you may temporarily opt out
>> of the archiving of messages (e.g., to discuss a sensitive matter).
>> If needed, please add a note at the top of the message that you
>> have dropped the address. When the discussion is concluded,
>> [email protected] will be re-added to the CC list and
>> its addition will be noted at the top of the message.
>>
>> You may submit your changes in one of two ways:
>>
>> An update to the provided XML file
>> — OR —
>> An explicit list of changes in this format
>>
>> Section # (or indicate Global)
>>
>> OLD:
>> old text
>>
>> NEW:
>> new text
>>
>> You do not need to reply with both an updated XML file and an explicit
>> list of changes, as either form is sufficient.
>>
>> We will ask a stream manager to review and approve any changes that seem
>> beyond editorial in nature, e.g., addition of new text, deletion of text,
>> and technical changes. Information about stream managers can be found in
>> the FAQ. Editorial changes do not require approval from a stream manager.
>>
>>
>> Approving for publication
>> --------------------------
>>
>> To approve your RFC for publication, please reply to this email stating
>> that you approve this RFC for publication. Please use ‘REPLY ALL’,
>> as all the parties CCed on this message need to see your approval.
>>
>>
>> Files
>> -----
>>
>> The files are available here:
>> https://www.rfc-editor.org/authors/rfc9768.xml
>> https://www.rfc-editor.org/authors/rfc9768.html
>> https://www.rfc-editor.org/authors/rfc9768.pdf
>> https://www.rfc-editor.org/authors/rfc9768.txt
>>
>> Diff file of the text:
>> https://www.rfc-editor.org/authors/rfc9768-diff.html
>> https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html (side by side)
>>
>> Diff of the XML:
>> https://www.rfc-editor.org/authors/rfc9768-xmldiff1.html
>>
>>
>> Tracking progress
>> -----------------
>>
>> The details of the AUTH48 status of your document are here:
>> https://www.rfc-editor.org/auth48/rfc9768
>>
>> Please let us know if you have any questions.
>>
>> Thank you for your cooperation,
>>
>> RFC Editor
>>
>> --------------------------------------
>> RFC 9768 (draft-ietf-tcpm-accurate-ecn-34)
>>
>> Title : More Accurate Explicit Congestion Notification (AccECN)
>> Feedback in TCP
>> Author(s) : B. Briscoe, M. Kühlewind, R. Scheffenegger
>> WG Chair(s) : Yoshifumi Nishida, Michael Tüxen
>>
>> Area Director(s) : Gorry Fairhurst, Mike Bishop
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
