Re: [Gen-art] Review of draft-ietf-6tisch-minimal-17

[Thomas Watteyne <[e-mail]>]

Brian, all,

We have discussed the possible resolutions to your comments with Xavi. I
have captured those in a slideset [1] to be presented at this Friday's
interim meeting [2].

Early comments about the discussions and proposed resoltuion in the
slideset, in preparation for their presentation on Friday, welcome.

Thomas

[1]
https://bitbucket.org/6tisch/meetings/src/master/170106_webex/slides_170106_webex_b_minimal_brian.ppt?fileviewer=file-view-default
[2] https://www.ietf.org/mail-archive/web/6tisch/current/msg05106.html

On Wed, Jan 4, 2017 at 1:38 PM, Thomas Watteyne <[e-mail]>
wrote:

> Brian,
> Just a quick admin update that the authors have taken your comments into
> account, which will be integrated in -18.
> We will discuss the proposed resolutions at an interim meeting this Friday
> and publish it next week.
> Thomas
>
> On Sat, Dec 10, 2016 at 11:39 PM, Brian Carpenter <
> [e-mail]> wrote:
>
>> Reviewer: Brian Carpenter
>> Review result: Almost Ready
>>
>> Gen-ART Last Call review of draft-ietf-6tisch-minimal-17
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-6tisch-minimal-17.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2016-12-11
>> IETF LC End Date: 2016-12-20
>> IESG Telechat date: 2017-01-05
>>
>> Summary: Almost Ready
>> --------
>>
>> Comment:
>> --------
>>
>> Although I found some issues, this is a good document which is mainly
>> very clear. I was not in a position to check IEEE802.15.4 details.
>>
>> It's too late now, but judging by the shepherd's writeup, this draft
>> would have been an excellent candidate for an Implementation Status
>> section under RFC 6982.
>>
>> Major Issues:
>> -------------
>>
>> I was very confused for several pages until I went back and read this
>> again:
>>
>> >   This specification defines operational parameters and procedures
>> for
>> >   a minimal mode of operation to build a 6TiSCH Network.  The
>> 802.15.4
>> >   TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and its Objective
>> >   Function 0 (OF0) [RFC6552], are used unmodified.
>>
>> Then I realised that there is some very basic information missing at
>> the beginning
>> of the Introduction. That little phrase "the 6LoWPAN framework" seems
>> to be the clue.
>> What is the 6LoWPAN framework? Which RFCs? I'm guessing it would be
>> RFC4944, RFC6282
>> and RFC6775, but maybe not. In any case, the very first sentence of
>> the Introduction
>> really needs to be a short paragraph that explains in outline, with
>> citations, how a
>> 6TiSCH network provides IPv6 connectivity over NBMA. With that, the
>> rest of the document
>> makes sense.
>>
>> But related to that, the Abstract is confusing in the same way:
>>
>> > Abstract
>> >
>> >   This document describes a minimal mode of operation for a 6TiSCH
>> >   Network.  It provides IPv6 connectivity over a Non-Broadcast
>> Multi-
>> >   Access (NBMA) mesh...
>>
>> "It" is confusing since it seems to refer to this document, which
>> hardly
>> mentions IPv6 connectivity. I suggest s/It/6TiSCH/.
>>
>> As far as I know a Security Considerations section is still always
>> required. I understand
>> that this document discusses security in detail, but that doesn't
>> cancel the
>> requirement (https://tools.ietf.org/html/rfc3552#section-5).
>>
>> Minor issues:
>> -------------
>>
>> > 4.4.  Timeslot Timing
>> ...
>> >   The RX node needs to send the first bit after the
>> >   SFD of the MAC acknowledgment exactly tsTxAckDelay after the end
>> of
>> >   the last byte of the received packet.
>>
>> I don't understand "exactly". Nothing is exact - there is always clock
>> jitter.
>> Shouldn't there be a stated tolerance rather than "exactly"?
>>
>> > 4.5.  Frame Formats
>> >
>> >   The following sections detail the RECOMMENDED format of link-layer
>> >   frames of different types.  A node MAY use a different formats
>> (bit
>> >   settings, etc)...
>>
>> Doesn't this create an interoperability issue for independent
>> implementations?
>> How can you mix and match implementations that use variants of the
>> frame format?
>> This seems particularly strange:
>>
>> >   The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames
>> >   SHOULD include the Source Address field and the Destination
>> Address
>> >   field.
>>
>> How will it work if some nodes omit the addresses?
>>
>> > 4.6.  Link-Layer Security
>> ...
>> >   For early interoperability testing, value 36 54 69 53 43 48 20 6D
>> 69
>> >   6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1.
>>
>> Shouldn't this also say that this value MUST NOT be used in
>> operational networks?
>>
>> Nits:
>> -----
>>
>> > 1.  Introduction
>> >
>> >   A 6TiSCH Network provides IPv6 connectivity...
>>
>> I would expect to see a reference to [RFC2460] right there.
>>
>> Outdated reference: draft-ietf-6lo-paging-dispatch has been published
>> as RFC 8025
>>
>>
>
>
> --
> _______________________________________
>
> Thomas Watteyne, PhD
> Research Scientist & Innovator, Inria
> Sr Networking Design Eng, Linear Tech
> Founder & co-lead, UC Berkeley OpenWSN
> Co-chair, IETF 6TiSCH
>
> www.thomaswatteyne.com
> _______________________________________
>



-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________