Hi all, Please see inline.
> On 12. Aug 2025, at 21:38, rfc-edi...@rfc-editor.org 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, rfc-edi...@rfc-editor.org 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 > > * rfc-edi...@rfc-editor.org (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). > > * auth48archive@rfc-editor.org, 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, > auth48archive@rfc-editor.org 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
