Transmission of IPv6 Packets over Power Line Communication (PLC) Networks
draft-ietf-6lo-plc-11

[Ballot comment]
I'm not a big fan of using the "someone else did it already" excuse,
especially when there is a simple technical alternative available (do more
complicated bitslicing to avoid using bits whose semantics would be
overloaded), but the new discussion in §4.1 about the interaction with the
Universal/Local and Individual/Group bits does seem to provide an ample
discussion of the situation so as to let operators make an informed
choice.  Accordingly, I am (reluctantly) demoting this topic from the
DISCUSS section to the COMMENT section.

Going from the -06 to the -10 (I didn't peek within that range to see
exactly when the change occurred) the description of Source Address Mode
address compression in §4.5 had the prose change from describing 12 bits
carried in line to 16 bits carried in line (with corresponding change in
the number of bits elided).  It looks like this was done in response to
one of my comments about preserving byte alignment, and so the "new" four
bits are expected to be all zeros, which would justify using the "0XXX"
expression that is present in the -10.  However, it would probably be
worth stating explicitly that the four bits represented by the "0" are
indeed always zero.  Additionally, in the new chunk of text for
Destination Address Mode, we are inconsistent about whether it is "0XXX"
or "XXXX" that is carried in-line.  My recollection is that both stateless
and stateful compression in DAM should be copying the same set of bits.

Thank you for the vastly expanded security considerations section; it's a
big improvement.

Section 4

  A PLC node distinguishes between an IPv6 PDU and a non-IPv6 PDU based
  on the equivalent of a EtherType in a layer-2 PLC PDU.  [RFC7973]
  defines a Ethertype of "A0ED" for LoWPAN encapsulation, and this
  information can be carried in the IE field in the MAC header of
  [IEEE_1901.2] or [ITU-T_G.9903].  [...]

"Can be carried in the IE field", or "the IE field is defined to
carry..."?  Is this text subtly redefining the usage of the IEEE
specification's fields?


NITS

Section 4.1

  For privacy reasons, the IID derived from the MAC address (with
  padding and bits flipping) SHOULD only be used for link-local address

I would suggest s/padding and bits flipping/padding and bit clamping/ --
"flipping" has a connotation of changing the state of the bit, whatever
the current state is, whereas "clamping" implies forcing a speficic value
(as we do towards zero).  Also, "bit" singular is appropriate for the
abstract operation, even though we do specify that two bits are affected.

Section 4.5

  instead of 16 bits.  The only modification is the semantics of the
  "Source Address Mode" and the "Dstination Address Mode" when set as

s/Dstination/Destination/

Section 8

s/valide/valid/
s/more severer/more severe/

[Ballot discuss]
[updated for -09]
** Section 8. A few additional threats should be mentioned.  Note that a robust treatment is not needed here (and likely not possible due to the generality of this document).  However, they should be acknowledged.

-- This section mentions both availability (DoS) and confidentiality (eavesdropping) concerns.  Thank you. Wouldn’t there also be the possibility of significant integrity risks given that possible actuators or sensors being controlled?

[Ballot comment]
Thank you for the work put into this document.

Thank you also for addressing all my blocking points (except for the paywall for normative references) and most of my comments, either on the mailing list or in the document itself. I am therefore clearing up my DISCUSS ballot.

Special thanks to Carles Gomez for his shepherd's write-up, which contains a good summary of the WG consensus *BUT* it does not mention that the IEEE normative references are not free. Strange that Carles' email address, carlesgo@entel.upc.edu, is not in the datatracker status page.

Please find below some *archived* DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Please also address Dave Thaler's INT-DIR review at:
https://datatracker.ietf.org/doc/review-ietf-6lo-plc-06-intdir-telechat-thaler-2021-08-06/ (some of my DISCUSS points are coming from Dave's review)

I hope that this helps to improve the document,

Regards,

-éric


== DISCUSS (for archiving not more standing/blocking) ==

Is there any reason why the IETF Last Call https://mailarchive.ietf.org/arch/msg/6lo/f59y8rMg-p_aCKYSSEtBzoJK4qQ/ did not mention that the two IEEE normative references were behind a paywall ? It prevented some more detailed reviews and is an important fact.

How can a PLC node distinguish between an IPv6 PDU and a non-IPv6 PDU ? I.e., is there the equivalent of a EtherType in a layer-2 PLC PDU ? Then, this should be mentioned in this document else some text explaining why it is not required would be welcome. Especially when the normative IEEE references are not freely available.

-- Section 4.1 --
I am repeating here Dave Thaler's point 1) as it is completely unclear to me how the shared secret/version number are shared and provisioned, this could prevent interoperation hence my DISCUSS.

While I appreciate that the nodes are constrained, some warnings about having a *single global IPv6 address* should be written or if the spec supports more than one global IPv6 address per node, then the current text must be changed.


== COMMENTS ==

A generic and probably naive question of mine: how can a PLC node (which has access to electrical power) can be qualified as 'low power' ?

-- Section 2 --

Please add references to the IEEE references before using them in the table 1.

-- Section 3.1 --

Is the I-D limited to TCP & UDP only ? (based on figure 1 even if later RPL is mentioned)

-- Section 3.4 --

While not required, an expansion of "LOAD" as in "LOADng" will probably be welcome by readers.

-- Section 4.1 --

Strongly suggest to show the 48-bit pseudo MAC address before showing the generated 64-bit address, which looks like the old EUI-64 generation. Should there be some explanation about the lack of U/L bit flapping in this algorithm ?

Same comment for the 12-bit address.

Should there be some explanations about NID and TEI? Notably about how they are provisioned and how can collision be prevented.

  "A PLC host SHOULD use
  the IID derived from the link-layer short address to configure the
  IPv6 address used for communication with the public network"
Is the above text about how to provision the IP address ? E.g., via stateful DHCPv6 ?

-- Section 4.3.1 --
  "In order to avoid the possibility of duplicated IPv6 addresses, the
  value of the NID MUST be chosen so that the 7th and 8th bits of the
  first byte of the NID are both zero."
I failed to understand the reasoning in the above text: how can a reduction of entropy decrease the risk of collision ?

Please also specify the receiver's behavior when the padding is not 0 (probably 'ignore').

Rather than using "7th and 8th bits" please use "bits 6 and 7".

-- Section 4.3.2 --
Same comments as for section 4.3.1

-- Section 4.4 --
  "Although PLC devices are electrically powered, sleeping mode SHOULD
  still be used for power saving."
Suggest to add some justification for the "SHOULD" or at least explain when a PLC device may not use the sleeping mode.

The logical flow is weird in §4 " Duplicate Address Detection (DAD) MUST NOT be utilized.  Otherwise, the DAD MUST", i.e., with a "MUST NOT" there should be no "Otherwise" :-) The "MUST NOT" is probably a "SHOULD NOT" ?

-- Section 5 --
Nice and interesting section, may I suggest to move it earlier in the document ? Just after the introduction for example.

Figure 6 does not have any node "A" or "B" while the § before mentions those node names.

== NITS ==

I find it strange that some acronyms are sometimes expanded in the text *and* in the terminology (e.g., MTU) while others are not (e.g., PANC).

-- Section 3.3 --
Is "adapt" the right word in "For this reason, fragmentation and reassembly is required for G.9903-based networks to adapt IPv6."

-- Section 3.4 --
My eyebrows raised when reading "L2 routing"... as "routing" for me is usually reserved for layer 3 and above.

-- Section 4.4 --
s/For IPv6 address prefix dissemination/For IPv6 network prefix dissemination/ ?

[Ballot comment]
I also support Roman's and Eric's DISCUSS positions.

Section 2 needs to be reviewed.  It defines "CID", "EV", "IPHC", "LAN", "MSDU", "OFDM", and "PSDU", but these terms are not used anywhere in the document.  It also defines "WAN" which is not used, though "LPWAN" is used yet not defined.

Please also define "6LR" someplace, or refer to its definition.  It first appears in Section 4.4, along with "6LBR" and "6BBR".  Perhaps there should be a mention of the 6LowPAN RFC in the Definitions section to import all of these definitions.

[Ballot discuss]
Further details in the COMMENT, but can we briefly discuss the apparent
requirement for the PANID/NID to have a couple bits set to zero (the
ones that would be U/L and Individual/Group in the resulting IID)?  It
seems like (but is not entirely clear to me) this is a new requirement
on the layer-2 behavior that is being imposed by the IPv6 adaptation
layer, and in particular that this is setting up a scenario where
certain existing layer-2 deployments would be unable to utilize the IPv6
adaptation layer, which would be a very surprising behavior for an IETF
Proposed Standard.  What alternatives were explored and rejected before
settling on this approach that introduces new limitations on the
underlying PLC deployments?

I mention in a few places in the COMMENT scenarios where we pull in part
of the functionality from RFC 6282 and RFC 4944, e.g., the IP header
compression scheme and the fragmentation format.  It seems to me that
the intent is that our payload always use the RFC 4944 "dispatch" scheme
and that we only use a subset of (and only sometimes?) the particular
functionality that RFC 4944/6282 can dispatch to.  But the current text
doesn't mention the dispatch behavior at all, so it's hard for me to be
certain that my understanding is correct.  It seems that some more
explicit treatment in the document of how what we are specifying
interacts with/uses the RFC 4944 dispatch layer would be important in
order for someone to be able to implement from this document.

I support Roman and Éric's Discusses.

[Ballot comment]
Section 4.1

  Since the derived Interface ID is not global, the "Universal/Local"
  (U/L) bit (7th bit) and the Individual/Group bit (8th bit) MUST both
  be set to zero.  In order to avoid any ambiguity in the derived
  Interface ID, these two bits MUST NOT be used to generate the PANID
  (for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1).  In
  other words, the PANID or NID MUST always be chosen so that these
  bits are zeros.

Is this a new requirement on the PANID/NID not already imposed by the
underlying specifications?  If so, it seems that it presents a
limitation on the ability of already deployed PLC networks to adopt this
IPv6 adaptation layer.

  For privacy reasons, the IID derived from the MAC address SHOULD only
  be used for link-local address configuration.  A PLC host SHOULD use
  the IID derived from the link-layer short address to configure the
  IPv6 address used for communication with the public network;
  otherwise, the host's MAC address is exposed.  As per [RFC8065], when
  short addresses are used on PLC links, a shared secret key or version
  number from the Authoritative Border Router Option [RFC6775] can be
  used to improve the entropy of the hash input, thus the generated IID
  can be spread out to the full range of the IID address space while
  stateless address compression is still allowed.

The phrasing "derived from" is a little ambiguous to me, since it can
encompass procedures ranging from the "flip the U/L bit and append PLC
IID to the network's prefix" procedure to RFC 7217-style stable but
opaque IIDs that incorporate the MAC address into the pseudorandom
function's inputs.  Given the follow-up text about "host's MAC address
is exposed", it feels like this is implying more of the former
procedure.  Wouldn't the latter type of procedure be preferred, though
(as implied by the "hash input" in the last sentence)?  In particular,
the last sentence seems to imply that there is *always* a hash input,
which is at odds with the "former" interpretation that I present for
"derived from".  I'm not confident that I understand the intent of this
paragraph.

Section 4.3.1

  In order to avoid the possibility of duplicated IPv6 addresses, the
  value of the NID MUST be chosen so that the 7th and 8th bits of the
  first byte of the NID are both zero.

As above, it's not clear that the NID is something that this adaptation
layer can assert control over.

Section 4.3.2

  In order to avoid the possibility of duplicated IPv6 addresses, the
  value of the PAN ID MUST be chosen so that the 7th and 8th bits of
  the first byte of the PAN ID are both zero.

(likewise)

Section 4.5

  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.  For situations when PLC MAC MTU cannot support the 1280-octet
  IPv6 packet, headers MUST be compressed according to [RFC6282]
  encoding formats.

RFC 6282 refers to both a "Dispatch" value and the LOWPAN_IPHC header
compression encoding.  I strongly suggest clarifying whether both, or
just LOWPAN_IPHC, is used.

  For IEEE 1901.2 and G.9903, the IP header compression follows the
  instruction in [RFC6282].  However, additional adaptation MUST be
  considered for IEEE 1901.1 since it has a short address of 12 bits
  instead of 16 bits.  The only modification is the semantics of the
  "Source Address Mode" when set as "10" in the section 3.1 of
  [RFC6282], which is illustrated as following.

Is there anything useful to say about how carrying 12 vs 16 bits affects
byte alignment of the overal compressed message?  A quick survey of RFC
6282 finds many items that retain byte alignment, and I didn't actually
find anything that left the encoded bit stream in a non-aligned state.

  SAM: Source Address Mode:

I see that RFC 6282 also has procedures for Destination Address Mode
(DAM), including a scenario that involves conveying a 16-bit address
component.  Do we need to treat that DAM analogously to how we treat the
SAM here?  (This might also handle the byte alignment question from my
previous remark...)

Section 4.6

  In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as
  big as 2031 octets and 1576 octets respectively.  However when the
  channel condition is noisy, it is possible to configure smaller MTU
  at the MAC layer.  If the configured MTU is smaller than 1280
  octects, the fragmentation and reassembly defined in [RFC4944] MUST
  be used.

Does this imply that implementing the IPv6 adaptation layer
fragmentation+reassembly logic is mandatory for implementations of IPv6
over IEEE 1901.1 and 1901.2, since the implementation might be
configured in a way that requires that support?  Please be clear about
what is required of implementations and in what circumstances.

Also, as above, please be clear about the interaction with the RFC 4944
dispatch layer.

Section 5

  node; PAN Devices are typically PLC meters and sensors.  The PANC
  also serves as the Routing Registrar for proxy registration and DAD
  procedures, making use of the updated registration procedures in
  [RFC8505].  IPv6 over PLC networks are built as tree, mesh or star

If the PANC always serves as the Routing Registrar (and thus the RFC
8505 procedures are always used), why do we allow for both RFC 6775 and
8505 DAD procedures up in §4.4?

Section 8

We should probably incorporate by reference the security considerations
of the documents whose technologies we are adopting.

One might hope that it goes without saying, but it's nonetheless
probably worth noting that the PANC, being in a position to observe all
traffic, is necessarily a trusted entity.

  Due to the high accessibility of power grid, PLC might be susceptible
  to eavesdropping within its communication coverage, e.g., one
  apartment tenant may have the chance to monitor the other smart
  meters in the same apartment building.  Thus link layer security
  mechanisms are designed in the PLC technologies mentioned in this
  document.

Key management for these security mechanisms will of course be quite
important.  IoT devices are notoriously vulnerable to physical attacks
and key extraction, so there may be something useful to say about the
importance of key management and what is exposed if the key material
available to a single device is compromised.

It's quite hard to make an evaluation of the actual security properties
provided by the link-layer mechanisms without access to the actual
specification documents for those technologies.  I'd actually seriously
consider adding another clause that "and additional end-to-end security
services can be used for sensitive traffic and as additional
protection against compromised PLC nodes" (or something in that general
vein).

Additionally, it's often the case that the link-layer security
mechanisms involve group-shared symmetric keys, so that a compromise of
even a single device puts the entire network, or a large chunk of the
network, at risk.  If this is the case for the PLC link layers, it seems
imperative to mention that risk in this document.

  Malicious PLC devices could paralyze the whole network via DOS
  attacks, e.g., keep joining and leaving the network frequently, or
  multicast routing messages containing fake metrics.  A device may

Is there potential for interfering with/corrupting legitimate traffic as
a DoS vector, as well?
  illegal users.  Mutual authentication of network and new device can
  be conducted during the onboarding process of the new device.
  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] (which uses IDevID and
  MASA service).  It is also possible to use EAP methods such as
  [I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191].  No
  specific mechanism is specified by this document as an appropriate
  mechanism will depend upon deployment circumstances.

Would SZTP (RFC 8572) be applicable for these scenarios?
(Also, I would recognize "BRSKI" more than "IDevID and [a] MASA
service", though I don't know if I am the right population to be
sampling for readibility data.)

  scanning.  Schemes such as limited lease period in DHCPv6 [RFC3315],
  Cryptographically Generated Addresses (CGAs) [RFC3972], privacy
  extensions [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], or
  semantically opaque addresses [RFC7217] SHOULD be considered to
  enhance the IID privacy.

"SHOULD be considered" is a fairly weak guidance; I would think that
"SHOULD be used" would be more consistent with the IETF consensus
position, while still leaving ample space for other behaviors.

Section 10.2

I would consider classifying RFC 4291 as normative.

NITS

  meters for electricity.  The inherent advantage of existing
  electricity infrastructure facilitates the expansion of PLC
  deployments, and moreover, a wide variety of accessible devices
  raises the potential demand of IPv6 for future applications.  This

"Advantage" typically implies a comparison with some other thing or
things as measured on a particular axis or axes.  While one might
presume that this refers to the advantages of using existing wires over
new wires in terms of cost and ease of deployment, it's probably worth
stating it more clearly.

Section 1

  century.  With the advantage of existing power grid, Power Line
  Communication (PLC) is a good candidate for supporting various
  service scenarios such as in houses and offices, in trains and

As above, what is "the advantage of existing power grid"?

Section 2

  PANC: PAN Coordinator, a coordinator which also acts as the primary
        controller of a PAN.

PAN is not marked as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt (in fact, is
not even defined there), and thus should get its own expansion.

Section 4.4

  information in the replied Neighbor Advertisements from the 6LR.  If
  DHCPv6 is used to assign addresses or the IPv6 address is derived
  from unique long or short link layer address, Duplicate Address
  Detection (DAD) MUST NOT be utilized.  Otherwise, the DAD MUST be
  performed at the 6LBR (as per [RFC6775]) or proxied by the routing
  registrar (as per [RFC8505]).  The registration status is feedbacked
  via the DAC or EDAC message from the 6LBR and the Neighbor
  Advertisement (NA) from the 6LR.

A few words on how the 6LR+6LBR must know whether 6775 or 8505 is in use
on the network, and thus there is no ambiguity about which entity is
performing DAD, might be helpful.

Section 4.5

  10:  12 bits.  The first 116 bits of the address are elided.The
        value of the first 64 bits is the link-local prefix padded with

spaces after the sentence break.

Section 5

  [RFC8505].  IPv6 over PLC networks are built as tree, mesh or star
  according to the use cases.  Generally, each PLC network has one

I think "as a tree, mesh or star topology"

  the size of PLC networks.  A simple use case is the smart home
  scenario where the ON/OFF state of air conditioning is controlled by
  the state of home lights (ON/OFF) and doors (OPEN/CLOSE).  AODV-RPL

Almost all the other examples in the document refer to PLC meters or
sensors (mostly meters), so the "smart home" scenario sticks out as
being rather different when only mentioned in passing like this.  I
don't question the conclusion, but the overall writing style of the
document might be improved if we introduced this scenario earlier on so
that it was a more continual theme.

  enables direct PAN device to PAN device communication, without being
  obliged to transmit frames through the PANC, which is a requirement
  often cited for AMI infrastructure.

The only earlier mention of AODV-RPL was in §3.4; we might consider
repeating the reference here in case the reader missed it the previous
time.

Section 6

  self-managed.  The software or firmware is flushed into the devices

s/flushed/flashed/?

  before deployment by the vendor or operator.  And during the
  deployment process, the devices are bootstrapped, and no extra
  configuration is needed to get the device connected to each other.

s/device/devices/

  gateway.  The recently-formed iotops WG in IETF is aming to design
  more features for the management of IOT networks.

s/aming/aiming/
Also, a reference to the WG's datatracker page might be worthwhile.

Section 8

  Malicious PLC devices could paralyze the whole network via DOS
  attacks, e.g., keep joining and leaving the network frequently, or
  multicast routing messages containing fake metrics.  A device may

I think s/multicast/sending/multicast/

  also join a wrong or even malicious network, exposing its data to
  illegal users.  Mutual authentication of network and new device can

Maybe "inadvertently join"?

  IP addresses may be used to track devices on the Internet; such
  devices can in turn be linked to individuals and their activities.

I think s/can in turn/can often in turn/.  There are some IoT devices
that are basically uncorrelated to individual humans.

  Cryptographically Generated Addresses (CGAs) [RFC3972], privacy
  extensions [RFC4941], Hash-Based Addresses (HBAs) [RFC5535], or

RFC 4941 has been obsoleted by RFC 8981.

[Ballot comment]
I support Roman's and Eric's DISCUSS positions.

Otherwise, just a couple of nits:

s/which may includes/which may include

Expand DIO.

s/participate to RPL/participate in RPL

[Ballot discuss]
Thank you for the work put into this document.

Special thanks to Carles Gomez for his shepherd's write-up, which contains a good summary of the WG consensus *BUT* it does not mention that the IEEE normative references are not free. Strange that Carles' email address, carlesgo@entel.upc.edu, is not in the datatracker status page.

Please find below some blocking DISCUSS points (probably easy to address), some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Please also address Dave Thaler's INT-DIR review at:
https://datatracker.ietf.org/doc/review-ietf-6lo-plc-06-intdir-telechat-thaler-2021-08-06/ (some of my DISCUSS points are coming from Dave's review)

I hope that this helps to improve the document,

Regards,

-éric


== DISCUSS ==

Is there any reason why the IETF Last Call https://mailarchive.ietf.org/arch/msg/6lo/f59y8rMg-p_aCKYSSEtBzoJK4qQ/ did not mention that the two IEEE normative references were behind a paywall ? It prevented some more detailed reviews and is an important fact.

How can a PLC node distinguish between an IPv6 PDU and a non-IPv6 PDU ? I.e., is there the equivalent of a EtherType in a layer-2 PLC PDU ? Then, this should be mentioned in this document else some text explaining why it is not required would be welcome. Especially when the normative IEEE references are not freely available.

-- Section 4.1 --
I am repeating here Dave Thaler's point 1) as it is completely unclear to me how the shared secret/version number are shared and provisioned, this could prevent interoperation hence my DISCUSS.

While I appreciate that the nodes are constrained, some warnings about having a *single global IPv6 address* should be written or if the spec supports more than one global IPv6 address per node, then the current text must be changed.

[Ballot comment]
== COMMENTS ==

A generic and probably naive question of mine: how can a PLC node (which has access to electrical power) can be qualified as 'low power' ?

-- Section 2 --

Please add references to the IEEE references before using them in the table 1.

-- Section 3.1 --

Is the I-D limited to TCP & UDP only ? (based on figure 1 even if later RPL is mentioned)

-- Section 3.4 --

While not required, an expansion of "LOAD" as in "LOADng" will probably be welcome by readers.

-- Section 4.1 --

Strongly suggest to show the 48-bit pseudo MAC address before showing the generated 64-bit address, which looks like the old EUI-64 generation. Should there be some explanation about the lack of U/L bit flapping in this algorithm ?

Same comment for the 12-bit address.

Should there be some explanations about NID and TEI? Notably about how they are provisioned and how can collision be prevented.

  "A PLC host SHOULD use
  the IID derived from the link-layer short address to configure the
  IPv6 address used for communication with the public network"
Is the above text about how to provision the IP address ? E.g., via stateful DHCPv6 ?

-- Section 4.3.1 --
  "In order to avoid the possibility of duplicated IPv6 addresses, the
  value of the NID MUST be chosen so that the 7th and 8th bits of the
  first byte of the NID are both zero."
I failed to understand the reasoning in the above text: how can a reduction of entropy decrease the risk of collision ?

Please also specify the receiver's behavior when the padding is not 0 (probably 'ignore').

Rather than using "7th and 8th bits" please use "bits 6 and 7".

-- Section 4.3.2 --
Same comments as for section 4.3.1

-- Section 4.4 --
  "Although PLC devices are electrically powered, sleeping mode SHOULD
  still be used for power saving."
Suggest to add some justification for the "SHOULD" or at least explain when a PLC device may not use the sleeping mode.

The logical flow is weird in §4 " Duplicate Address Detection (DAD) MUST NOT be utilized.  Otherwise, the DAD MUST", i.e., with a "MUST NOT" there should be no "Otherwise" :-) The "MUST NOT" is probably a "SHOULD NOT" ?

-- Section 5 --
Nice and interesting section, may I suggest to move it earlier in the document ? Just after the introduction for example.

Figure 6 does not have any node "A" or "B" while the § before mentions those node names.

== NITS ==

I find it strange that some acronyms are sometimes expanded in the text *and* in the terminology (e.g., MTU) while others are not (e.g., PANC).

-- Section 3.3 --
Is "adapt" the right word in "For this reason, fragmentation and reassembly is required for G.9903-based networks to adapt IPv6."

-- Section 3.4 --
My eyebrows raised when reading "L2 routing"... as "routing" for me is usually reserved for layer 3 and above.

-- Section 4.4 --
s/For IPv6 address prefix dissemination/For IPv6 network prefix dissemination/ ?

[Ballot discuss]
** Section 8. A few additional threats should be mentioned.  Note that a robust treatment is not needed here (and likely not possible due to the generality of this document).  However, they should be acknowledged.

-- This section mentions both availability (DoS) and confidentiality (eavesdropping) concerns.  Thank you. Wouldn’t there also be the possibility of significant integrity risks given that possible actuators or sensors being controlled?  Note if the referenced link layer security mechanisms would be useful.

-- Figures 5 – 7 seems to present architectures which connects operational technology to the Internet via the PANC.  However, this section doesn’t acknowledgement of that risk outright or by citation.

** Section 8.  Per “Thus link layer security mechanisms are designed in the PLC technologies mentioned in this document”, which specific mechanisms were being cited is not clear.  Is their use required or are they use case dependent?

[Ballot comment]
Thank you to Robert Sparks for the SECDIR review.

** Section 6.  Per “The onboard status of the devices and the topology of the PLC network can be  visualized via the gateway”, this is the first the architectural element of a “gateway” is mentioned.  What does it mean to “visualize via the gateway”?

** Section 6.  Per “The recently-formed iotops WG in IETF is aming to design more features for the management of IOT networks”, I don’t follow the intent of this sentence as IOTOPS is not chartered for new protocol work (only requirements and operational practices).

** Editorial nits

-- Section 1.  Typo. s/efficent/efficient/

-- Section 4.4.  Typo. s/Solicitaitons/ Solicitations/

-- Section 4.5. s/elided.The/elided. The/

-- Section 4.6.  Typo. s/octects/octets/

-- Section 4.6. Typo. s/constranied/constrained/

-- Section 4.6.  Typo. s/fragements/fragments/

-- Section 6.  s/aming/aiming/

[Ballot comment]
Section 3.1. , paragraph 4, comment:
>                        Figure 1: PLC Protocol Stack

Since this says "TCP/UDP", are other transport protocols not supported? Or else
should this say "Transport Layer" instead?

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "master"; alternatives might be "active", "central", "initiator",
  "leader", "main", "orchestrator", "parent", "primary", "server".

* Term "natively"; alternatives might be "built-in", "fundamental",
  "ingrained", "intrinsic", "original".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 3, nit:
-    been fully adapted for IPv6 based constrained networks.  The
-                              ^
-    resource-constrained IoT related scenarios lie in the low voltage PLC
-                            ^
+    been fully adapted for IPv6-based constrained networks.  The
+                              ^
+    resource-constrained IoT-related scenarios lie in the low voltage PLC
+                            ^

Section 1. , paragraph 3, nit:
-    networks, due to its large address space and efficent address auto-
+    networks, due to its large address space and efficient address auto-
+                                                      +

Section 1. , paragraph 4, nit:
-    them have LLN (low power and lossy network) characteristics, i.e.
+    them have LLN (low power and lossy network) characteristics, i.e.,
+                                                                    +

Section 3.3. , paragraph 4, nit:
-    MTU in high-noise communication environment.  Thus the 6lo functions,
+    MTU in high-noise communication environments.  Thus, the 6lo functions,
+                                              +      +

Section 3.3. , paragraph 5, nit:
-    required for G.9903-based networks to adapt IPv6.
-                                          ^^^^
+    required for G.9903-based networks to carry IPv6.
+                                          + ^^^

Section 3.4. , paragraph 3, nit:
-      is a layer 3 routing protocol.  AODV-RPL [I-D.ietf-roll-aodv-rpl]
-                ^
+      is a layer-3 routing protocol.  AODV-RPL [I-D.ietf-roll-aodv-rpl]
+                ^

Section 3.4. , paragraph 4, nit:
-    o  IEEE 1901.1 supports L2 routing.  Each PLC node maintains a L2
+    o  IEEE 1901.1 supports L2 routing.  Each PLC node maintains an L2
+                                                                  +

Section 4. , paragraph 2, nit:
-    [RFC8505] provides useful functionality including link-local IPv6
-                    -
+    [RFC8505] provide useful functionality including link-local IPv6

Section 4.4. , paragraph 3, nit:
-    layer 3 routing protocol, such as RPL, which may includes the prefix
-        ^
+    layer-3 routing protocol, such as RPL, which may includes the prefix
+        ^

Section 4.4. , paragraph 5, nit:
-    sending Neighbor Solicitaitons in order to extract the status
-                              -
+    sending Neighbor Solicitations in order to extract the status
+                            +

Section 4.6. , paragraph 3, nit:
-    octects, the fragmentation and reassembly defined in [RFC4944] MUST
-        -
+    octets, the fragmentation and reassembly defined in [RFC4944] MUST

Section 4.6. , paragraph 5, nit:
-    frequent incorrectly assembled IP fragments.  For constranied PLC,
-                                                              -
+    frequent incorrectly assembled IP fragments.  For constrained PLC,
+                                                            +

Section 4.6. , paragraph 5, nit:
-    thus the 16-bit tag is sufficient to assemble the fragements
-                                                          -
+    thus the 16-bit tag is sufficient to assemble the fragments

Section 4.4. , paragraph 6, nit:
> ets and 1576 octets respectively. However when the channel condition is nois
>                                  ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Document references draft-ietf-emu-eap-noob-03, but -05 is the latest available
revision.

Document references draft-ietf-6tisch-minimal-security, but that has been
published as RFC9031.

Obsolete reference to RFC4941, obsoleted by RFC8981 (this may be on purpose).

Document references draft-ietf-roll-aodv-rpl-08, but -10 is the latest
available revision.

Document references draft-ietf-roll-unaware-leaves, but that has been published
as RFC9010.

Obsolete reference to RFC3315, obsoleted by RFC8415 (this may be on purpose).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-6lo-plc-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-15):

From: The IESG
To: IETF-Announce
CC: 6lo-chairs@ietf.org, 6lo@ietf.org, Carles Gomez , carlesgo@entel.upc.edu, draft-ietf-6lo-plc@ietf.org, ek.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Transmission of IPv6 Packets over PLC Networks) to Proposed Standard


The IESG has received a request from the IPv6 over Networks of
Resource-constrained Nodes WG (6lo) to consider the following document: -
'Transmission of IPv6 Packets over PLC Networks'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Power Line Communication (PLC), namely using the electric-power lines
  for indoor and outdoor communications, has been widely applied to
  support Advanced Metering Infrastructure (AMI), especially smart
  meters for electricity.  The inherent advantage of existing
  electricity infrastructure facilitates the expansion of PLC
  deployments, and moreover, a wide variety of accessible devices
  raises the potential demand of IPv6 for future applications.  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6lo-plc/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

[Shepherd response] Proposed Standard (the title page header reads “Standards Track”). This is the proper type of RFC because the document specifies the adaptation layer to support IPv6  over various Power Line Communication (PLC) technologies.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  Power Line Communication (PLC), namely using the electric-power lines
  for indoor and outdoor communications, has been widely applied to
  support Advanced Metering Infrastructure (AMI), especially smart
  meters for electricity.  The inherent advantage of existing
  electricity infrastructure facilitates the expansion of PLC
  deployments, and moreover, a wide variety of accessible devices
  raises the potential demand of IPv6 for future applications.  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.

Working Group Summary:
There has been no particular WG controversy regarding this document. The document has progressed with WG consensus.

Document Quality:
There exists a production-quality implementation of this specification from a large vendor.
Michael Richardson provided a detailed review during the WGLC (which led to revisions -03 and -04), with a particular focus on security. His comments were satisfactorily addressed.

Personnel:
The document shepherd is Carles Gomez. The responsible AD is Erik Kline.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
[Shepherd response] The shepherd reviewed version -04 of the draft. The shepherd’s comments were mostly editorial, although a few technical points were found as well. The authors updated the draft to address the shepherd’s comments, and produced revision -05. The shepherd believes that, in its current version (-05), the document is ready for being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
[Shepherd response] No such concerns. The document has been discussed and presented at many IETF meetings, with significant progress happening through numerous updates even happening before the document became a WG document. Michael Richardson provided a detailed and comprehenseive review during WGLC, which led to updates -03 and -04.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
[Shepherd response] No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
[Shepherd response] No such concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
[Shepherd response] All authors have confirmed that they are not aware of any IPR that applies to this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
[Shepherd response] No IPR disclosure referencing this document has been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
[Shepherd response] There is good WG consensus behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
[Shepherd response] No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
[Shepherd response] The Idnits tool indicates no errors or flaws. There are a few warnings and comments. A summary of the Idnits tool output is shown next:
  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

    (The document does seem to have the reference to RFC 2119 which the
    ID-Checklist requires).
  -- The document date (October 28, 2020) is 68 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-03) exists of
    draft-ietf-emu-eap-noob-02

  -- Unexpected draft version: The latest known version of
    draft-ietf-roll-aodv-rpl is -07, but you're referring to -08.

  == Outdated reference: A later version (-28) exists of
    draft-ietf-roll-unaware-leaves-22

  -- Obsolete informational reference (is this intentional?): RFC 3315
    (Obsoleted by RFC 8415)


    Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
[Shepherd response]  N/A.

(13) Have all references within this document been identified as either normative or informative?
[Shepherd response] Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
[Shepherd response] All normative references have already been published.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
[Shepherd response] There are no downward normative references in this document.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
[Shepherd response] This document does not update or change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
[Shepherd response]  This document requires no IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
[Shepherd response] N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
[Shepherd response] N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
[Shepherd response] The document does not contain a YANG module.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

[Shepherd response] Proposed Standard (the title page header reads “Standards Track”). This is the proper type of RFC because the document specifies the adaptation layer to support IPv6  over various Power Line Communication (PLC) technologies.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  Power Line Communication (PLC), namely using the electric-power lines
  for indoor and outdoor communications, has been widely applied to
  support Advanced Metering Infrastructure (AMI), especially smart
  meters for electricity.  The inherent advantage of existing
  electricity infrastructure facilitates the expansion of PLC
  deployments, and moreover, a wide variety of accessible devices
  raises the potential demand of IPv6 for future applications.  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.

Working Group Summary:
There has been no particular WG controversy regarding this document. The document has progressed with WG consensus.

Document Quality:
There exists a production-quality implementation of this specification from a large vendor.
Michael Richardson provided a detailed review during the WGLC (which led to revisions -03 and -04), with a particular focus on security. His comments were satisfactorily addressed.

Personnel:
The document shepherd is Carles Gomez. The responsible AD is Erik Kline.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
[Shepherd response] The shepherd reviewed version -04 of the draft. The shepherd’s comments were mostly editorial, although a few technical points were found as well. The authors updated the draft to address the shepherd’s comments, and produced revision -05. The shepherd believes that, in its current version (-05), the document is ready for being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
[Shepherd response] No such concerns. The document has been discussed and presented at many IETF meetings, with significant progress happening through numerous updates even happening before the document became a WG document. Michael Richardson provided a detailed and comprehenseive review during WGLC, which led to updates -03 and -04.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
[Shepherd response] No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
[Shepherd response] No such concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
[Shepherd response] All authors have confirmed that they are not aware of any IPR that applies to this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
[Shepherd response] No IPR disclosure referencing this document has been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
[Shepherd response] There is good WG consensus behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
[Shepherd response] No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
[Shepherd response] The Idnits tool indicates no errors or flaws. There are a few warnings and comments. A summary of the Idnits tool output is shown next:
  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

    (The document does seem to have the reference to RFC 2119 which the
    ID-Checklist requires).
  -- The document date (October 28, 2020) is 68 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-03) exists of
    draft-ietf-emu-eap-noob-02

  -- Unexpected draft version: The latest known version of
    draft-ietf-roll-aodv-rpl is -07, but you're referring to -08.

  == Outdated reference: A later version (-28) exists of
    draft-ietf-roll-unaware-leaves-22

  -- Obsolete informational reference (is this intentional?): RFC 3315
    (Obsoleted by RFC 8415)


    Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--).

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
[Shepherd response]  N/A.

(13) Have all references within this document been identified as either normative or informative?
[Shepherd response] Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
[Shepherd response] All normative references have already been published.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
[Shepherd response] There are no downward normative references in this document.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
[Shepherd response] This document does not update or change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
[Shepherd response]  This document requires no IANA actions.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
[Shepherd response] N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
[Shepherd response] N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
[Shepherd response] The document does not contain a YANG module.