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:[email protected]] 发送时间: 2022年3月23日 1:24 收件人: The IESG <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; Carles Gomez <[email protected]>; [email protected] 主题: 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/ _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
