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

[汤效军 <[e-mail]>]

Dear all,
I agree with all the modification.
Thanks for your efforts!
Xiaojun

---------------- 

---------- Origin message ----------
>From："Lynne Bartholomew" <[e-mail]>
>To："Houjianqiang (Derek)" <[e-mail]>
>Subject：Re: AUTH48: RFC-to-be 9354 <draft-ietf-6lo-plc-11> for your review
>Date：2023-01-07 02:07:16Hi, Derek.

We have further updated this document per your notes below.

The latest files are posted here (reminder that the erroneous "RFC Publisher" entries in the References sections are a known and reported bug that should be fixed shortly):

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

We have noted your approval (dated today) on the AUTH48 status page:

https://www.rfc-editor.org/auth48/rfc9354

Thank you again for your help!

RFC Editor/lb


> On Jan 6, 2023, at 2:23 AM, Houjianqiang (Derek) <[e-mail]> wrote:
>
> 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
>>
>