[auth48] 答复: AUTH48: RFC-to-be 9354 <draft-ietf-6lo-plc-11> for your review

["Houjianqiang (Derek)" <[e-mail]>]

Hi Lynne and editors, 

Thank you for taking my comments and updating the draft. And regarding your follow-up comments, please see my feedback as below:

= = = = = = = == = = = = = = =

Would you like to use alphanumeric order ("6lo" before "6LoWPAN" and "RA" before "RPL")?

///Derek: Yes, it's better to use alphanumeric order. Thanks!

= = = = = = = =

Would this text convey your intended meaning?

IPv6 header compression in PLC is based on [RFC6282] (which updates [RFC4944]).  [RFC6282] specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4; therefore, this format is used for compression of IPv6 datagrams within PLC MAC frames.

///Derek: Yes, this text looks good to me.

= = = = = = = =

We would like further clarification for this text, which we see twice in Section 4.5.  Does "the 16-bit short address to the IID mapping" intend to say "the mapping between the 16-bit short address and the IID", "the 16-bit short address to the IID mapping", or something else?  (We ask because we are not sure that "IID mapping" is the correct term here.)

Possibly:
Any IID bits not covered by
context information are taken directly from their corresponding bits in the mapping between the 16-bit short address and the IID as provided by 0000:00ff:fe00:0XXX, where 0XXX are the 16 bits carried inline, in which the first 4 bits are zero.

If the "Possibly" text is incorrect, we will update per the "Perhaps" text.  Please advise.

///Derek: the "Possibly" text is correct, thanks!

= = = = = = = == = = = = = = =

Thank you for your valuable comments and support!

Kind regards,
Derek

-----邮件原件-----
发件人: Lynne Bartholomew [mailto:[e-mail]] 
发送时间: 2023年1月5日 7:13
收件人: Houjianqiang (Derek) <[e-mail]>
抄送: [e-mail]; Liubing (Remy) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
主题: Re: AUTH48: RFC-to-be 9354 <draft-ietf-6lo-plc-11> for your review

Hi, Derek.  Happy New Year to you and your colleagues as well!

Thank you for your reply.  We have updated this document per your notes below.

Some follow-up questions for you:

We see that the list of acronyms and terms in Section 2 is mostly in alphanumeric order.  Would you like to use alphanumeric order ("6lo" before "6LoWPAN" and "RA" before "RPL")?

= = = = = = = =

Regarding this question and your reply:

>> 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.


Would this text convey your intended meaning?

IPv6 header compression in PLC is based on [RFC6282] (which updates [RFC4944]).  [RFC6282] specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4; therefore, this format is used for compression of IPv6 datagrams within PLC MAC frames.

= = = = = = = =

Regarding this question and your reply:

> 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


We would like further clarification for this text, which we see twice in Section 4.5.  Does "the 16-bit short address to the IID mapping" intend to say "the mapping between the 16-bit short address and the IID", "the 16-bit short address to the IID mapping", or something else?  (We ask because we are not sure that "IID mapping" is the correct term here.)

Possibly:
Any IID bits not covered by
context information are taken directly from their corresponding bits in the mapping between the 16-bit short address and the IID as provided by 0000:00ff:fe00:0XXX, where 0XXX are the 16 bits carried inline, in which the first 4 bits are zero.

If the "Possibly" text is incorrect, we will update per the "Perhaps" text.  Please advise.

= = = = = = = =

The latest files are posted below (please refresh your browser).
*Please note* that we are aware of the erroneous "RFC Publisher" entries in the References sections; this bug has been reported.

   https://www.rfc-editor.org/authors/rfc9354.txt
   https://www.rfc-editor.org/authors/rfc9354.pdf
   https://www.rfc-editor.org/authors/rfc9354.html
   https://www.rfc-editor.org/authors/rfc9354.xml
   https://www.rfc-editor.org/authors/rfc9354-diff.html
   https://www.rfc-editor.org/authors/rfc9354-rfcdiff.html
   https://www.rfc-editor.org/authors/rfc9354-auth48diff.html
   https://www.rfc-editor.org/authors/rfc9354-lastdiff.html
   https://www.rfc-editor.org/authors/rfc9354-lastrfcdiff.html

   https://www.rfc-editor.org/authors/rfc9354-xmldiff1.html
   https://www.rfc-editor.org/authors/rfc9354-xmldiff2.html
   https://www.rfc-editor.org/authors/rfc9354-alt-diff.html

Because we still have some pending questions for you, we will note your approval after the remaining questions are resolved.

Thanks again!

RFC Editor/lb


> On Jan 2, 2023, at 1:22 AM, Houjianqiang (Derek) <houjianqiang=[e-mail]> wrote:
> 
> 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
> 
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]]
> 发送时间: 2022年12月24日 4:23
> 收件人: Houjianqiang (Derek) <[e-mail]>; Liubing (Remy) 
> <[e-mail]>; [e-mail]; 
> [e-mail]; [e-mail]
> 抄送: [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; 
> [e-mail]
> 主题: [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
> 
>  *  [e-mail] (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).
> 
>  *  [e-mail], 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-4Q9l2USxI
> Ae6P8O4Zc
> 
>    *  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, 
>       [e-mail] 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
>