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/ _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
