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

["Liubing (Remy)" <[e-mail]>]

Hello Benjamin,

Sorry for this late reply. Many thanks to your detailed review.

Please find my response inline.

Best regards,
Remy

-----邮件原件-----
发件人: Benjamin Kaduk via Datatracker [mailto:[e-mail]] 
发送时间: 2022年3月23日 1:24
收件人: The IESG <[e-mail]>
抄送: [e-mail]; [e-mail]; [e-mail]; Carles Gomez <[e-mail]>; [e-mail]
主题: Benjamin Kaduk's No Objection on draft-ietf-6lo-plc-10: (with COMMENT)

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.
[Remy] Thanks for the comment. As a fact, the original semantics of the U/L and I/G bits are not always kept in IETF. And in the draft we give two options with one of them complies to the original semantics. The operator can decide to reduce the PANID/NID's entropy by four times (in practice, the reduced entropy is still sufficient) while keep the semantics of the two bits, or keep the entropy while violating the original semantics of the two bits. "Do more complicated bitslicing" may work, but it is more complicated (just like you mentioned) for device processing and related packet parsing tools. The design does not affect the other functionalities defined in the draft, such as stateless address configuration/compression. When the original semantics are not kept, even the IID cannot be transformed back into a short link layer address via a reverse operation of the mechanism presented in section 4.1, the short address can still be obtained by the Unicast Address Mapping mechanism in section 4.3.

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.
[Remy] We've added related descriptions in version 11.

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?

[Remy] IE or information element is like a TLV, but in Layer 2. Thus it is not dedicated to carry ethertype. 

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/