[auth48] 答复: [AD] Re: AUTH48: RFC-to-be 9354 <draft-ietf-6lo-plc-11> for your review
"Houjianqiang (Derek)" <houjianqiang@huawei.com> Mon, 02 January 2023 09:22 UTC
Return-Path: <houjianqiang@huawei.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 89483C14CF19; Mon, 2 Jan 2023 01:22:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.895
X-Spam-Level:
X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_WP_DIRINDEX=1] autolearn=no 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 wkx8Bv8sBebJ; Mon, 2 Jan 2023 01:22:46 -0800 (PST)
Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974DFC14F741; Mon, 2 Jan 2023 01:22:45 -0800 (PST)
Received: from dggpeml500010.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Nlr2z13MHzJqHg; Mon, 2 Jan 2023 17:21:31 +0800 (CST)
Received: from kwepemi500017.china.huawei.com (7.221.188.110) by dggpeml500010.china.huawei.com (7.185.36.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.34; Mon, 2 Jan 2023 17:22:41 +0800
Received: from kwepemi500017.china.huawei.com ([7.221.188.110]) by kwepemi500017.china.huawei.com ([7.221.188.110]) with mapi id 15.01.2375.034; Mon, 2 Jan 2023 17:22:40 +0800
From: "Houjianqiang (Derek)" <houjianqiang@huawei.com>
To: "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "Liubing (Remy)" <remy.liubing@huawei.com>, "yonggeun.hong@gmail.com" <yonggeun.hong@gmail.com>, "itc@sgepri.sgcc.com.cn" <itc@sgepri.sgcc.com.cn>, "charliep@computer.org" <charliep@computer.org>
CC: "6lo-ads@ietf.org" <6lo-ads@ietf.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "carlesgo@entel.upc.edu" <carlesgo@entel.upc.edu>, "ek.ietf@gmail.com" <ek.ietf@gmail.com>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>
Thread-Topic: [AD] Re: AUTH48: RFC-to-be 9354 <draft-ietf-6lo-plc-11> for your review
Thread-Index: AQHZFwxoEAE4JN+tkU2buNRIluwoHa6EoDhw
Date: Mon, 02 Jan 2023 09:22:40 +0000
Message-ID: <4f8a36025d28455a8172b989ed53957f@huawei.com>
References: <20221223202304.9ACD1563C7@rfcpa.amsl.com>
In-Reply-To: <20221223202304.9ACD1563C7@rfcpa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.84.114.110]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/dJELqCNa-CiUcRau81X1hKjh5NY>
Subject: [auth48] 答复: [AD] Re: AUTH48: RFC-to-be 9354 <draft-ietf-6lo-plc-11> 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: Mon, 02 Jan 2023 09:22:50 -0000
Hi Erik and editors, Happy new year! Thanks for your valuable comments and questions. The polished version looks good to me, and I give a "pass". For details please see my response in line. Kind regards, Derek -----邮件原件----- 发件人: rfc-editor@rfc-editor.org [mailto:rfc-editor@rfc-editor.org] 发送时间: 2022年12月24日 4:23 收件人: Houjianqiang (Derek) <houjianqiang@huawei.com>; Liubing (Remy) <remy.liubing@huawei.com>; yonggeun.hong@gmail.com; itc@sgepri.sgcc.com.cn; charliep@computer.org 抄送: rfc-editor@rfc-editor.org; 6lo-ads@ietf.org; 6lo-chairs@ietf.org; carlesgo@entel.upc.edu; ek.ietf@gmail.com; auth48archive@rfc-editor.org 主题: [AD] Re: AUTH48: RFC-to-be 9354 <draft-ietf-6lo-plc-11> for your review Authors and *AD, *AD, please see question #1 below. Authors, while reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. 1) <!-- [rfced] *AD, please review and approve the text added to the end of the Acknowledgements section (it was added after the document was approved for publication). This added text is best viewed in this diff file: https://www.rfc-editor.org/authors/rfc9354-alt-diff.html. --> ///Derek: I am OK with the acknowledgements addition. And I agree with Erik and change "delegating the presentation" to "delivering the presentation". 2) <!-- [rfced] Please note that 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: Transmission of IPv6 Packets over PLC Networks Current: Transmission of IPv6 Packets over Power Line Communication (PLC) Networks --> ///Derek: I am OK with this change. 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> ///Derek: "6lo", "6lowpan", "6lo-plc", "6loplc", "plc" 4) <!-- [rfced] Please review "such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2". How may we update for clarity? Original: This document describes how IPv6 packets are transported over constrained PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2. Perhaps: This document describes how IPv6 packets are transported over constrained PLC networks, such as those described in ITU-T G.9903, IEEE 1901.1, and IEEE 1901.2. ///Derek: I am OK with this change. Thanks Or: This document describes how IPv6 packets are transported over constrained PLC networks, which are described in ITU-T G.9903, IEEE 1901.1, and IEEE 1901.2. --> ///Derek: "such as those" is preferred (I'm referring to the sentence below "Perhaps:") 5) <!-- [rfced] Will it be clear to readers what "large quantity" is referring to here? Should this read "large capacity", "large quantity of nodes", or something else? Original: The data acquisition devices in these scenarios share common features such as fixed position, large quantity, low data rate and low power consumption. --> ///Derek: I am OK with this change. "large quantity of nodes" is preferred 6) <!-- [rfced] Please confirm that "electric plugged devices" is correct here. Original: PLC technology enables convenient two-way communications for home users and utility companies to monitor and control electric plugged devices such as electricity meters and street lights. --> ///Derek: I suggest to use "electrically connected devices" instead of "electric plugged devices ". 7) <!-- [rfced] We have several questions about the sentence below. - Should "have been addressed on the MAC and PHY layers for this communication technology" be revised as shown below? - Would updating the text starting with "e.g." as follows to improve readability? Original: Various standards have been addressed on the MAC and PHY layers for this communication technology, e.g., BBPLC (1.8-250 MHz) including IEEE 1901 and ITU-T G.hn, and NBPLC (3-500 kHz) including ITU-T G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 (PRIME), IEEE 1901.2 [IEEE_1901.2] (a combination of G3-PLC and PRIME PLC) and IEEE 1901.2a [IEEE_1901.2a] (an amendment to IEEE 1901.2). Perhaps: Various standards address this communication technology on the MAC and Physical (PHY) layers. For example, standards for BBPLC (1.8-250 MHz) include IEEE 1901 and ITU-T G.hn, and standards for NBPLC (3-500 kHz) include ITU-T G.9902 (G.hnem), ITU-T G.9903 (G3-PLC) [ITU-T_G.9903], ITU-T G.9904 (PRIME), IEEE 1901.2 (a combination of G3-PLC and PRIME PLC) [IEEE_1901.2], and IEEE 1901.2a (an amendment to IEEE 1901.2) [IEEE_1901.2a]. --> Derek: I am OK with this change. Thanks 8) <!-- [rfced] Since the "PLC MAC Layer" and "PLC PHY Layer" are two different layers in Figure 1, we updated "PLC MAC/PHY layer" to read "PLC MAC and PLC PHY layers") in this sentence. Also, please review "corresponds to IEEE 1901.1, IEEE 1901.2, or ITU-T G.9903" and let us know if updates are needed for clarity. Original: The PLC MAC/PHY layer corresponds to IEEE 1901.1, IEEE 1901.2 or ITU-T G.9903. Perhaps: The PLC MAC and PLC PHY layers correspond to the layers described in IEEE 1901.1, IEEE 1901.2, or ITU-T G.9903. --> ///Derek: I am OK with this change. Thanks 9) <!-- [rfced] We see that "mesh-under" is mentioned in Section 3.4, but "route-over" is not. We see "route-over" in Section 4.4. Are any updates needed? Original: The routes can be built in mesh-under mode at layer 2 or in route-over mode at layer-3, as explained in Section 3.4. --> ///Derek: Thanks for your comments. I suggest changing the above sentence to "... as explained in Section 3.4 and Section 4.4." 10) <!-- [rfced] In Figure 1, should "IPv6" be "IPv6 Layer"? The other fields include "Layer". --> ///Derek: I am fine with "IPv6 Layer". 11) <!-- [rfced] We are having trouble parsing this sentence, specifically "besides [RFC4291]". Also, will it be clear to readers what "reliable indicators for their original meanings" means? Please let us know how we may update for clarity. Original: As investigated in [RFC7136], besides [RFC4291], some other IID generation methods defined in IETF do not imply any semantics for the "Universal/Local" (U/L) bit (bit 6) and the Individual/Group bit (bit 7), so that these two bits are not reliable indicators for their original meanings. Perhaps: As investigated in [RFC7136], aside from the method discussed in [RFC4291], other IID-generation methods defined by the IETF do not imply any additional semantics for the Universal/Local (U/L) bit (bit 6) and the Individual/Group bit (bit 7). Therefore, these two bits are not reliable indicators. --> ///Derek: I am OK with this change. Thanks 12) <!-- [rfced] Will readers understand "If so" (second sentence below) and "If not" (third sentence below)? We included the first sentence for context. Original: Thus when using an IID derived by a short address, the operators of the PLC network can choose to comply with the original meaning of these two bits or not. If so, since the IID derived from the short address is not global, these two bits MUST both be set to zero. ... If not, the operator must be aware that these two bits are not reliable indicators, and the IID cannot be transformed back into a short link layer address via a reverse operation of the mechanism presented above. Perhaps: Thus, when using an IID derived by a short address, the operators of the PLC network can choose whether or not to comply with the original meaning of these two bits. If they choose to comply with the original meaning, these two bits MUST both be set to zero, since the IID derived from the short address is not global. ... If they choose not to comply with the original meaning, the operator must be aware that these two bits are not reliable indicators, and the IID cannot be transformed back into a short link-layer address via a reverse operation of the mechanism presented above. --> ///Derek: I am OK with this change. Thanks 13) <!-- [rfced] Please clarify “by default of the implementations”. Original: The hash algorithm by default of the implementations SHOULD be SHA256, using the version number, the PANID/NID and the short address as the input arguments, and the 256-bits hash output is truncated into the IID by taking the high 64 bits. Perhaps: By default, the hash algorithm SHOULD be SHA256, using the version number, the PAN ID or NID, and the short address as the input arguments, and the 256-bit hash output is truncated into the IID by taking the high 64 bits. --> ///Derek: I am OK with this change. Thanks 14) <!-- [rfced] Please review "NCEs (neighbor cache entry)". Should this be singular or plural? Original: The resolution is realized by the NCEs (neighbor cache entry) created during the address registration at the routers. Perhaps (singular): The resolution is realized by the NCE (neighbor cache entry) created during the address registration at the routers. Or (plural): The resolution is realized by the NCEs (neighbor cache entries) created during the address registration at the routers. --> ///Derek: I suggest to use plural 15) <!-- [rfced] How may we recast this sentence to avoid hyphenation of "RFC6775-only" and "RFC8505-updated"? See the "RFCs as Compounds" section of the online style guide (https://www.rfc-editor.org/styleguide/part2/). Original: The section 6 of [RFC8505] how RFC6775-only devices work with RFC8505-updated devices. Perhaps: Section 6 of [RFC8505] shows how devices that only behave as specified in [RFC6775] can work with devices that have been updated per [RFC8505]. --> ///Derek: I am OK with this change. Thanks 16) <!-- [rfced] Please clarify "refers to" in the first sentence below. Is this sentence saying the same thing as the sentence that follows? Original: The compression of IPv6 datagrams within PLC MAC frames refers to [RFC6282], which updates [RFC4944]. Header compression as defined in [RFC6282] which specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4, is the basis for IPv6 header compression in PLC. --> ///Derek: Yes, this "refer to" sentence saying the same thing as the sentence that follows. 17) <!-- [rfced] We believe that this sentence is correct, but please confirm. We ask because we do not see "compression residu" in RFC 6282 (though we think this refers to Figure 1 in Section 3 of RFC 6282). Original: For situations when PLC MAC MTU cannot support the 1280-octet IPv6 packet, headers MUST be compressed according to [RFC6282] encoding formats, including the Dispatch Header, the LOWPAN_IPHC and the compression residu carried in-line. --> ///Derek: Yes, this sentence is correct. 18) <!-- [rfced] Please review "in the 16-bit to IID mapping". Should this read "in the 16-bit short address to the IDD mapping" or something else? Original: Any IID bits not covered by context information are taken directly from their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:0XXX, where 0XXX are the 16 bits carried in-line, in which the first 4 bits are zero. Perhaps: Any IID bits not covered by context information are taken directly from their corresponding bits in the 16-bit short address to the IID mapping given by 0000:00ff:fe00:0XXX, where 0XXX are the 16 bits carried inline, in which the first 4 bits are zero. --> ///Derek: I am OK with this change. Thanks 19) <!-- [rfced] Please review "of great potential applications". Should this be updated to one of the following suggestions? Original: Mesh networking in PLC is of great potential applications and has been studied for several years. Perhaps: a) Mesh networking in PLC has many potential applications and has been studied for several years. b) Mesh networking in PLC has great potential for many applications and has been studied for several years. --> ///Derek: option (a) is preferred, thanks 20) <!-- [rfced] Would it be helpful to include the names of the protocols here rather than just the citations? Original: Methods include protocols such as [RFC7925] (exchanging pre- installed certificates over DTLS), [I-D.ietf-6tisch-minimal-security] (which uses pre-shared keys), and [I-D.ietf-6tisch-dtsecurity-zerotouch-join] (a IoT version of BRSKI, which uses IDevID and MASA service to facilitate authentication). Perhaps: Methods include protocols such as the TLS/DTLS Profile [RFC7925] (exchanging pre-installed certificates over DTLS), the Constrained Join Protocol (CoJP) [RFC9031] (which uses pre-shared keys), and Zero-Touch Secure Join [ZEROTOUCH] (an IoT version of the Bootstrapping Remote Secure Key Infrastructure (BRSKI), which uses an Initial Device Identifier (IDevID) and a Manufacturer Authorized Signing Authority (MASA) service to facilitate authentication). --> ///Derek: I am OK with this change. Thanks 21) <!-- [rfced] Should “interface identifiers (IID)” here read either “IIDs” or “IPv6 Interface Identifiers (IIDs)”? Original: [RFC8065] discusses the privacy threats when interface identifiers (IID) are generated without sufficient entropy, including correlation of activities over time, location tracking, device-specific vulnerability exploitation, and address scanning. --> ///Derek: IID refers to interface identifier 22) <!-- [rfced] FYI - We updated the URLs for the two references below because the original URLs returned 404 Errors (Page not found). Original: [IEEE_1901.2] IEEE-SA Standards Board, "IEEE Standard for Low-Frequency (less than 500 kHz) Narrowband Power Line Communications for Smart Grid Applications", IEEE 1901.2, October 2013, <https://standards.ieee.org/findstds/ standard/1901.2-2013.html>. ... [IEEE_1901.2a] IEEE-SA Standards Board, "IEEE Standard for Low-Frequency (less than 500 kHz) Narrowband Power Line Communications for Smart Grid Applications - Amendment 1", IEEE 1901.2a, September 2015, <https://standards.ieee.org/findstds/ standard/1901.2a-2015.html>. Current: [IEEE_1901.2] IEEE, "IEEE Standard for Low-Frequency (less than 500 kHz) Narrowband Power Line Communications for Smart Grid Applications", DOI 10.1109/IEEESTD.2013.6679210, IEEE Std. 1901.2, December 2013, <https://ieeexplore.ieee.org/document/6679210>. ... [IEEE_1901.2a] IEEE, "IEEE Standard for Low-Frequency (less than 500 kHz) Narrowband Power Line Communications for Smart Grid Applications - Amendment 1", DOI 10.1109/IEEESTD.2015.7286946, IEEE Std. 1901.2a, October 2015, <https://ieeexplore.ieee.org/document/7286946>. --> ///Derek: I am OK with this change. Thanks 23) <!-- [rfced] The URL provided in this reference redirects to a document titled "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)” with a date of August 2017. May we update the title, date, and URL of this reference entry accordingly? Original: [EUI-64] IEEE-SA Standards Board, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", IEEE EUI-64, March 1997, <https://standards.ieee.org/content/dam/ieee- standards/standards/web/documents/tutorials/eui.pdf>. Suggested: [EUI-64] IEEE, "Guidelines for Use of Extended Unique Idenfier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)", August 2017, <https://standards.ieee.org/wp-content/uploads/import/documents/ tutorials/eui.pdf>. --> ///Derek: I am OK with this change. Thanks 24) <!-- [rfced] Terminology a) The following definitions in Section 2 include "IPv6". Is "IPv6" needed here? We ask because it's not part of the expansion. IID: IPv6 Interface Identifier RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks ///Derek: thanks for pointing out. "IPv6" is not needed here b) Please review instances of "Interface ID”. Should any of these read “IID” or “IPv6 Interface Identifier”? ///Derek: The abbreviation of IID has been used in other 6lo RFCs (e.g. RFC8065, RFC8015, RFC9159). I recommend keeping the abbreviation "IID". c) How should the acronym MAC be expanded in this document? We believe that "Media Access Control" may be correct, but the possibilities include the following: Media Access Control (MAC) Medium Access Control (MAC) Message Authentication Code (MAC) Mandatory Access Control (MAC) ///Derek: I agree acronym "Media Access Control (MAC)" should be expanded. Thanks d) We see both "PLC Device" and "PLC device" used in the document. Should these be uniform? If so, please let us know which form is preferred. ///Derek: "PLC device" is preferred e) We note inconsistencies in the terms listed below. We chose the form on the right. Please let us know any objections. PANID vs. PAN ID EtherType vs. Ethertype --> ///Derek: "PAN ID" and "Ethertype" are preferred 25) <!-- [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. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. RFC Editor/st/rv *****IMPORTANT***** Updated 2022/12/23 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/rfc9354.xml https://www.rfc-editor.org/authors/rfc9354.html https://www.rfc-editor.org/authors/rfc9354.pdf https://www.rfc-editor.org/authors/rfc9354.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9354-diff.html https://www.rfc-editor.org/authors/rfc9354-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9354-xmldiff1.html Alt-diff of the text (allows you to more easily view changes where text has been deleted or moved): https://www.rfc-editor.org/authors/rfc9354-alt-diff.html The following files are provided to facilitate creation of your own diff files of the XML. Initial XMLv3 created using XMLv2 as input: https://www.rfc-editor.org/authors/rfc9354.original.v2v3.xml XMLv3 file that is a best effort to capture v3-related format updates only: https://www.rfc-editor.org/authors/rfc9354.form.xml Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9354 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9354 (draft-ietf-6lo-plc-11) Title : Transmission of IPv6 Packets over PLC Networks Author(s) : J. Hou, B. Liu, Y. Hong, X. Tang, C. Perkins WG Chair(s) : Shwetha Bhandari, Carles Gomez Area Director(s) : Erik Kline, Éric Vyncke
- [auth48] AUTH48: RFC-to-be 9354 <draft-ietf-6lo-p… rfc-editor
- [auth48] [AD] Re: AUTH48: RFC-to-be 9354 <draft-i… rfc-editor
- Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9354 <dra… Erik Kline
- Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9354 <dra… Liubing (Remy)
- Re: [auth48] [AD] AUTH48: RFC-to-be 9354 <draft-i… Rebecca VanRheenen
- [auth48] 答复: [AD] Re: AUTH48: RFC-to-be 9354 <dra… Houjianqiang (Derek)
- Re: [auth48] AUTH48: RFC-to-be 9354 <draft-ietf-6… Lynne Bartholomew
- [auth48] 答复: AUTH48: RFC-to-be 9354 <draft-ietf-6… Houjianqiang (Derek)
- Re: [auth48] AUTH48: RFC-to-be 9354 <draft-ietf-6… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9354 <draft-ietf-6… Liubing (Remy)
- Re: [auth48] AUTH48: RFC-to-be 9354 <draft-ietf-6… Charlie Perkins
- Re: [auth48] AUTH48: RFC-to-be 9354 <draft-ietf-6… Yong-Geun Hong
- Re: [auth48] AUTH48: RFC-to-be 9354 <draft-ietf-6… Rebecca VanRheenen
- Re: [auth48] AUTH48: RFC-to-be 9354 <draft-ietf-6… 汤效军
- Re: [auth48] AUTH48: RFC-to-be 9354 <draft-ietf-6… Rebecca VanRheenen
- [auth48] 答复: AUTH48: RFC-to-be 9354 <draft-ietf-6… Houjianqiang (Derek)