[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 67BF3C169511 for <auth48archive@ietfa.amsl.com>; Tue, 11 Jul 2023 13:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3uyfgHw4Knno for <auth48archive@ietfa.amsl.com>; Tue, 11 Jul 2023 13:14:13 -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 EC124C15C524 for <auth48archive@rfc-editor.org>; Tue, 11 Jul 2023 13:14:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id DEE7F424B440 for <auth48archive@rfc-editor.org>; Tue, 11 Jul 2023 13:14:13 -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 FVKFZO7oS1-t for <auth48archive@rfc-editor.org>; Tue, 11 Jul 2023 13:14:13 -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 B39E5424B434 for <auth48archive@rfc-editor.org>; Tue, 11 Jul 2023 13:14:12 -0700 (PDT)
From: Alanna Paloma <apaloma@amsl.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4008AA0E-EC5C-431F-A72F-08D2EA78D975"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Message-Id: <47758FD2-3F6B-4783-A86E-46F7DC663CB2@amsl.com>
References: <0EFBAA86-4CAC-48AA-B8F4-F396CD61F769@cuhk.edu.cn>
To: auth48archive <auth48archive@rfc-editor.org>
Date: Tue, 11 Jul 2023 13:14:12 -0700
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/64KT_SowtC-ty0NHKHmvqYBjs6s>
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:18 -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 4:45:13 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> > > 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 <mailto: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 <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 <mailto: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 <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 <mailto: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 <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 <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\ <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 <mailto: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/ <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/ <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 <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 <mailto: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 <mailto: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 <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> >>>> >>>> * The archive itself: >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ <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 <mailto: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.xml> >>>> https://www.rfc-editor.org/authors/rfc9426.html <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=CD413320-FE82-7005-BE56-9E177737B7B8&auth=dc85afdffa75f9bc5357f32e37bf917c5d89a957-be17cfb800b08c85020099c253969ec045953a48 <https://ddei3-0-ctp.asiainfo-sec.com/wis/clicktime/v1/query?url=https%3a%2f%2fwww.rfc%2deditor.org%2fauthors%2frfc9426.pdf&umid=CD413320-FE82-7005-BE56-9E177737B7B8&auth=dc85afdffa75f9bc5357f32e37bf917c5d89a957-be17cfb800b08c85020099c253969ec045953a48> >>>> 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 >>>> >>>
- [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