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 protected]> wrote: > 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
