Subject: [6lo] Benjamin Kaduk's No Objection on draft-ietf-6lo-plc-10: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 22 Mar 2022 10:23:39 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6lo-plc-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-plc/

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

---

From: Erik Kline <[email-masked]>
Date: Tue, 22 Mar 2022 15:27:47 -0700

Thank you, Ben!

If the authors can get an updated -11 addressing Ben's comments, or perhaps
discuss inline here, we can discuss what the next steps for the document
are.

Thanks all!

On Tue, Mar 22, 2022 at 10:23 AM Benjamin Kaduk via Datatracker <
[email-masked]> wrote:

> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/