Hi Ben, Thanks for your review. Comments inline...
On Tue, Nov 29, 2016 at 6:28 PM, Ben Campbell <[email protected]> wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-6lo-6lobac-06: 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-6lobac/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive: > > - 1.3 Do I undertand correctly that this section is strictly an overview > of something described elsewhere? If so, I am surprised to find the MUSTs > in the the 5th paragraph from the end of the section. > > <kel> I failed to communicate to reviewers outside of 6lo wg that I can provide a copy of [BACnet] Clause 9, if requested. The issue is that Clause 9 describes different types implementations, so it's necessary to spell out in this ID which features are required to implement IPv6 over MS/TP (6LoBAC). I have recast section 2 as a profile for 6LoBAC, partly to answer the concerns of the OPSDIR review. The question is whether it can/should contain RFC 2119 language? For example, [BACnet] Clause 9 specifies that 9600 bps is mandatory and all other rates are optional, but 6LoBAC requires that 115.2 Kbps be supported. Having said that, I see that I missed removing a "must" from 1.3 and will do that next round. </kel> - 2 and 3 also have some MUSTs that seem to describe MS/TP nodes in > general--are those new requirements described in this spec, or existing > requirements? (If the later, please consider stating them without 2119 > keywords.) > > <kel> As above. If I understand your point, the correct division is between what is specified in the 6LoBAC adaptation layer and what is required below the MAC i/f. So sections 2 & 3 still have some 2119 keywords that should be eliminated. This just means lower-casing them where used, right? </kel> -6, 2nd paragraph: Why is the SHOULD NOT not a MUST NOT? What is the > consequences of ignoring the SHOULD NOT? > > <kel> This section was re-worked and the offending paragraph removed (at least one other reviewer found it confusing). </kel> - 12, 2nd paragraph: "MS/TP networks are by definition wired and not > susceptible to casual > eavesdropping. " > I think this depends on too many factors to state this broadly. It may be > easier to eves drop on an unprotected piece of wire than, say, an > encrypted wireless link. > > <kel> Point taken; easier to remove it than defend it. </kel> > - 14.2: [EUI-64] and [I-D.ietf-6lo-privacy-considerations] seem to be > cited normatively. > > <kel> The EUI-64 reference has been removed and the Section 12 reference to RFC 8064 has been reworked a bit. Is the latest version satisfactory? (I know it still says [I-D.ietf-6lo-privacy-considerations]; that will be fixed in the next version) </kel> Editorial: > - 4: Please expand MSDU > > Done. Thanks again, Kerry
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
