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

[[e-mail]]

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


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


3) <!-- [rfced] Please insert any keywords (beyond those that appear in 
the title) for use on https://www.rfc-editor.org/search.
-->


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.

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


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


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


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


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


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


10) <!-- [rfced] In Figure 1, should "IPv6" be "IPv6 Layer"? The other fields
include "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.
-->


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


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


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


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


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


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


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


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


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


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


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


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


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


b) Please review instances of "Interface ID”. Should any of these read “IID”
or “IPv6 Interface Identifier”?


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) 


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.


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


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-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, 
       [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