Re: [6lo] Ben Campbell's No Objection on draft-ietf-6lo-6lobac-06: (with COMMENT)

[Kerry Lynn <[e-mail]>]

Hi Ben,

Thanks for your review.  Comments inline...

On Tue, Nov 29, 2016 at 6:28 PM, Ben Campbell <[e-mail]> 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