[auth48] Fwd: AUTH48: RFC-to-be 9426 <draft-irtf-nwcrg-bats-07> for your review
Alanna Paloma <apaloma@amsl.com> Tue, 11 July 2023 20:14 UTC
Return-Path: <apaloma@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A55C15C524 for <auth48archive@ietfa.amsl.com>; Tue, 11 Jul 2023 13:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSjcBO7BHQN1 for <auth48archive@ietfa.amsl.com>; Tue, 11 Jul 2023 13:14:16 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E18C16950E for <auth48archive@rfc-editor.org>; Tue, 11 Jul 2023 13:14:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 17237424B440 for <auth48archive@rfc-editor.org>; Tue, 11 Jul 2023 13:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4YAGd4D4z7H for <auth48archive@rfc-editor.org>; Tue, 11 Jul 2023 13:14:16 -0700 (PDT)
Received: from [IPv6:2600:1700:bac0:1070:d8f3:a192:aae5:4494] (unknown [IPv6:2600:1700:bac0:1070:d8f3:a192:aae5:4494]) by c8a.amsl.com (Postfix) with ESMTPSA id B3338424B434 for <auth48archive@rfc-editor.org>; Tue, 11 Jul 2023 13:14:15 -0700 (PDT)
From: Alanna Paloma <apaloma@amsl.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7B77AF16-8E92-4031-8B3B-DD382DF44D7D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Message-Id: <B263F899-EAB1-4D0F-A0FB-7B5C846F638D@amsl.com>
References: <8A62CB78-B8FC-4E43-8473-7A2BC6B22355@cuhk.edu.cn>
To: auth48archive <auth48archive@rfc-editor.org>
Date: Tue, 11 Jul 2023 13:14:15 -0700
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/AHSMNKbHuemSRuk4MYaxJb43JGc>
Subject: [auth48] Fwd: AUTH48: RFC-to-be 9426 <draft-irtf-nwcrg-bats-07> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jul 2023 20:14:20 -0000
> Begin forwarded message: > > From: "Dr. Yang Shenghao (SSE)" <shyang@cuhk.edu.cn> > Subject: Re: AUTH48: RFC-to-be 9426 <draft-irtf-nwcrg-bats-07> for your review > Date: June 19, 2023 at 5:49:45 PM PDT > To: Alanna Paloma <apaloma@amsl.com> > Cc: "1155136647@link.cuhk.edu.hk" <1155136647@link.cuhk.edu.hk>, "whyeung@ie.cuhk.edu.hk" <whyeung@ie.cuhk.edu.hk>, "jkzao@ieee.org" <jkzao@ieee.org>, "irsg@irtf.org" <irsg@irtf.org>, Vincent Roca <vincent.roca@inria.fr>, auth48archive <auth48archive@rfc-editor.org>, "RFC Errata System" <rfc-editor@rfc-editor.org> > > We have checked the queries. No further updates. > > Shenghao > >> On 20 Jun 2023, at 08:27, Alanna Paloma <apaloma@amsl.com> wrote: >> >> Hi Shenghao, >> >> Thank you for the updated XML file. We have updated the other files accordingly. >> >> We note that the following queries were not addressed. Please review and let us know if further updates are necessary. >> >>> 1) <!--[rfced] Please ensure that the guidelines listed in Section 2.1 of RFC >>> 5743 >>> have been adhered to in this document. --> >> >>> 5) <!-- [rfced] FYI, we have used the <sup> element for superscript in this >>> document. >>> Please review and let us know if further updates are needed. >>> >>> Note: In the HTML and PDF, it appears as superscript. In the text output, <sup> >>> generates a^b. >>> --> >> >>> 7) <!--[rfced] We see a number of author-inserted comments in the XML file for >>> this document. We are unsure if these have been resolved. Please review >>> and let us know if these can be deleted or if they need to be addressed. >>> --> >> >>> 13) <!-- [rfced] Please review the "type" attribute of each sourcecode element >>> in the XML file to ensure correctness. If the current list of preferred >>> values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt) >>> does not contain an applicable type, then feel free to let us know. Also, it >>> is acceptable to leave the "type" attribute not set. >>> --> >> >>> 14) <!-- [rfced] FYI - We have added the expansion for the following >>> abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please >>> review each expansion in the document carefully to ensure correctness. >>> >>> Path MTU (PMTU) >>> --> >> >> >> The files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9426.xml >> https://www.rfc-editor.org/authors/rfc9426.txt >> https://www.rfc-editor.org/authors/rfc9426.html >> https://ddei3-0-ctp.asiainfo-sec.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.rfc%2deditor.org%2fauthors%2frfc9426.pdf&umid=CBD28397-FE84-B605-90C5-ECCC071DA4EF&auth=dc85afdffa75f9bc5357f32e37bf917c5d89a957-198f6391565c46b5d24905e3e406653a4935771a >> >> The relevant diff files have been posted here: >> https://www.rfc-editor.org/authors/rfc9426-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9426-auth48diff.html (AUTH48 changes) >> >> Please review the document carefully and contact us with any further updates you may have. Note that we do not make changes once a document is published as an RFC. >> >> We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process. >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9426 >> >> Thank you, >> RFC Editor/ap >> >>> On Jun 19, 2023, at 4:45 PM, Dr. Yang Shenghao (SSE) <shyang@cuhk.edu.cn> wrote: >>> >>> Dear all, >>> >>> Attached is the response, which has been discussed with the other authors as well. >>> >>> >>> Shenghao >>> >>>>> On 20 Jun 2023, at 05:44, Alanna Paloma <apaloma@amsl.com> wrote: >>>> >>>> Greetings, >>>> >>>> This is a friendly reminder that we await answers to the questions sent on 6/5/2023 and your review of the document before continuing with the publication process. Please let us know if we can be of assistance as you begin the AUTH48 review process. >>>> >>>> The AUTH48 status page for this document is available here: >>>> https://www.rfc-editor.org/auth48/rfc9426 >>>> >>>> Thank you, >>>> RFC Editor/ap >>>> >>>>> On Jun 12, 2023, at 10:11 AM, Alanna Paloma <apaloma@amsl.com> wrote: >>>>> >>>>> Greetings, >>>>> >>>>> We do not believe we have heard from you regarding this document's readiness >>>>> for publication. Please review our previous messages describing the AUTH48 >>>>> process and containing any document-specific questions we may have had. >>>>> >>>>> We will wait to hear from you before continuing with the publication process. >>>>> >>>>> The AUTH48 status page for this document is located here: >>>>> https://www.rfc-editor.org/auth48/rfc9426 >>>>> >>>>> Thank you, >>>>> RFC Editor/ap >>>>> >>>>> >>>>>> On Jun 5, 2023, at 10:28 PM, rfc-editor@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] Please ensure that the guidelines listed in Section 2.1 of RFC >>>>>> 5743 >>>>>> have been adhered to in this document. --> >>>>>> >>>>>> >>>>>> 2) <!--[rfced] Please note the title of the document has been updated as >>>>>> follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC >>>>>> Style Guide"). >>>>>> Please review. >>>>>> >>>>>> Original: >>>>>> BATS Coding Scheme for Multi-hop Data Transport >>>>>> >>>>>> Current: >>>>>> BATched Sparse (BATS) Coding Scheme for Multi-hop Data Transport >>>>>> --> >>>>>> >>>>>> >>>>>> 3) <!--[rfced] John, would you like to update your author information? >>>>>> If so, please provide the updated information. We note that >>>>>> National Chiao Tung University (NCTU) has become >>>>>> National Yang Ming Chiao Tung University (NYCU). >>>>>> --> >>>>>> >>>>>> >>>>>> 4) <!--[rfced] Are the terms "data delivery process" or "Data Delivery >>>>>> Procedures" interchangeable with "Data Delivery Protocol"? >>>>>> If so, please consider whether the acronym "DDP" should be used, as it >>>>>> is defined in Section 2. >>>>>> >>>>>> Original (Section 2.1): >>>>>> We describe a data delivery process that involves one source node, >>>>>> one destination node, and multiple intermediate nodes in between. >>>>>> >>>>>> Original: >>>>>> 2.2. Data Delivery Procedures >>>>>> --> >>>>>> >>>>>> >>>>>> 5) <!-- [rfced] FYI, we have used the <sup> element for superscript in this >>>>>> document. >>>>>> Please review and let us know if further updates are needed. >>>>>> >>>>>> Note: In the HTML and PDF, it appears as superscript. In the text output, <sup> >>>>>> generates a^b. >>>>>> --> >>>>>> >>>>>> >>>>>> 6) <!--[rfced] We note that the spacing of equations is inconsistent within this >>>>>> document. May we include spaces to make them consistent and improve readability? >>>>>> >>>>>> For example: >>>>>> Original: >>>>>> Let P = K*T-F denote the number of padding octets. >>>>>> >>>>>> Perhaps: >>>>>> Let P = K * T - F denote the number of padding octets. >>>>>> --> >>>>>> >>>>>> >>>>>> 7) <!--[rfced] We see a number of author-inserted comments in the XML file for >>>>>> this document. We are unsure if these have been resolved. Please review >>>>>> and let us know if these can be deleted or if they need to be addressed. >>>>>> --> >>>>>> >>>>>> >>>>>> 8) <!--[rfced] For clarity, may we update this sentence as follows >>>>>> to remove the first instance of "with"? >>>>>> >>>>>> Original: >>>>>> The DDP MUST >>>>>> deliver with each coded packet with its batch ID, which will be >>>>>> further used by both recoder and decoder. >>>>>> >>>>>> Perhaps: >>>>>> DDP MUST >>>>>> deliver each coded packet with its batch ID, which will be >>>>>> further used by both the recoder and decoder. >>>>>> --> >>>>>> >>>>>> >>>>>> 9) <!--[rfced] Is it accurate that "DDP" is a type of protocol rather >>>>>> than the name of a specific protocol? >>>>>> >>>>>> If "DDP" is the name of a specific protocol, we suggest >>>>>> removing the definite article. For examples: >>>>>> >>>>>> Current: The DDP MUST deliver some of the information ... >>>>>> Perhaps: DDP MUST deliver some of the information ... >>>>>> >>>>>> Current: The DDP extracts the coded packets ... >>>>>> Perhaps: DDP extracts the coded packets ... >>>>>> --> >>>>>> >>>>>> >>>>>> 10) <!--[rfced] May "DDP protocol version" be updated as follows to avoid >>>>>> redundancy? (If expanded, "DDP protocol" would read "Data Delivery Protocol >>>>>> protocol".) >>>>>> >>>>>> Also, FYI, one instance of "DPP packet" has been corrected to "DDP packet"; >>>>>> please let us know if that is not accurate. >>>>>> >>>>>> Original: >>>>>> A DDP can form a DDP packet using a coded >>>>>> packet by adding necessary information that can help to deliver the >>>>>> DPP packet to the next node, e.g., the DDP protocol version, >>>>>> addresses and session identifiers. >>>>>> >>>>>> Perhaps: >>>>>> A DDP can form a DDP packet using a coded >>>>>> packet by adding necessary information that can help to deliver the >>>>>> DDP packet to the next node (e.g., the version of the DDP, >>>>>> addresses, and session identifiers). >>>>>> --> >>>>>> >>>>>> >>>>>> 11) <!--[rfced] Please clarify the "/" in "point-to-point/one-hop". >>>>>> Does it mean "or"? >>>>>> >>>>>> Original: >>>>>> A BATS coding scheme is suitable for high data load >>>>>> delivery in such networks without the requirement that the point-to- >>>>>> point/one-hop communication is highly reliable. >>>>>> >>>>>> Perhaps: >>>>>> A BATS coding scheme is suitable for high data load >>>>>> delivery in such networks without the requirement that the point-to- >>>>>> point or one-hop communication is highly reliable. >>>>>> --> >>>>>> >>>>>> >>>>>> 12) <!--[rfced] We are having some difficulty understanding "same as the payload" >>>>>> in the sentence below. Please review and let us know how it should be updated. >>>>>> >>>>>> Original: >>>>>> In these schemes, the >>>>>> source node attaches a signature to each packet to transmit, and the >>>>>> signature is allowed to be processed by network coding same as the >>>>>> payload. >>>>>> >>>>>> Perhaps: >>>>>> In these schemes, the >>>>>> source node attaches a signature to each packet to transmit, and the >>>>>> signature is allowed to be processed by network coding in the same >>>>>> way as the payload. >>>>>> --> >>>>>> >>>>>> >>>>>> 13) <!-- [rfced] Please review the "type" attribute of each sourcecode element >>>>>> in the XML file to ensure correctness. If the current list of preferred >>>>>> values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt) >>>>>> does not contain an applicable type, then feel free to let us know. Also, it >>>>>> is acceptable to leave the "type" attribute not set. >>>>>> --> >>>>>> >>>>>> >>>>>> 14) <!-- [rfced] FYI - We have added the expansion for the following >>>>>> abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please >>>>>> review each expansion in the document carefully to ensure correctness. >>>>>> >>>>>> Path MTU (PMTU) >>>>>> --> >>>>>> >>>>>> >>>>>> 15) <!-- [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. For example, please consider >>>>>> whether "native" should be updated. >>>>>> >>>>>> In addition, please consider whether "traditional" should be updated for clarity. >>>>>> While the NIST website >>>>>> <https://www.nist.gov/nist-research-library/nist-technical-series-publications-au\ >>>>>> thor-instructions#table1> >>>>>> indicates that this term is potentially biased, it is also ambiguous. >>>>>> "Tradition" is a subjective term, as it is not the same for everyone. >>>>>> --> >>>>>> >>>>>> >>>>>> Thank you. >>>>>> >>>>>> RFC Editor/ap/ar >>>>>> >>>>>> >>>>>> On Jun 5, 2023, rfc-editor@rfc-editor.org wrote: >>>>>> >>>>>> *****IMPORTANT***** >>>>>> >>>>>> Updated 2023/06/05 >>>>>> >>>>>> 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-editor@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/rfc9426.xml >>>>>> https://www.rfc-editor.org/authors/rfc9426.html >>>>>> https://ddei3-0-ctp.asiainfo-sec.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fwww.rfc%2deditor.org%2fauthors%2frfc9426.pdf&umid=CBD28397-FE84-B605-90C5-ECCC071DA4EF&auth=dc85afdffa75f9bc5357f32e37bf917c5d89a957-198f6391565c46b5d24905e3e406653a4935771a >>>>>> https://www.rfc-editor.org/authors/rfc9426.txt >>>>>> >>>>>> Diff file of the text: >>>>>> https://www.rfc-editor.org/authors/rfc9426-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9426-rfcdiff.html (side by side) >>>>>> >>>>>> Diff of the XML: >>>>>> https://www.rfc-editor.org/authors/rfc9426-xmldiff1.html >>>>>> >>>>>> >>>>>> Tracking progress >>>>>> ----------------- >>>>>> >>>>>> The details of the AUTH48 status of your document are here: >>>>>> https://www.rfc-editor.org/auth48/rfc9426 >>>>>> >>>>>> Please let us know if you have any questions. >>>>>> >>>>>> Thank you for your cooperation, >>>>>> >>>>>> RFC Editor >>>>>> >>>>>> -------------------------------------- >>>>>> RFC9426 (draft-irtf-nwcrg-bats-07) >>>>>> >>>>>> Title : BATS Coding Scheme for Multi-hop Data Transport >>>>>> Author(s) : S. Yang, X. Huang, R. Yeung, J. Zao >>>>>> Document Shepherd: V. Roca >>>>>> >>>>> >>> <rfc9426-reply.xml>
- [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-nwcrg… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Vincent Roca
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Raymond Yeung
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Alanna Paloma
- [auth48] Fwd: AUTH48: RFC-to-be 9426 <draft-irtf-… Alanna Paloma
- [auth48] Fwd: AUTH48: RFC-to-be 9426 <draft-irtf-… Alanna Paloma
- [auth48] Fwd: AUTH48: RFC-to-be 9426 <draft-irtf-… Alanna Paloma
- [auth48] Fwd: AUTH48: RFC-to-be 9426 <draft-irtf-… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Alanna Paloma
- [auth48] Fwd: AUTH48: RFC-to-be 9426 <draft-irtf-… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9426 <draft-irtf-n… Alanna Paloma