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

[Brian E Carpenter <[e-mail]>]

Hi Thomas,

The responses to my comments almost all look fine to me. Just one point,
on MINOR COMMENT 4 (slide 8):

"Shouldn't this also say that this value MUST NOT be used in operational networks?"

We've seen many cases over the years of informal values making it into shipped
products... generally a Bad Thing. But with my lack of IEEE802.15.4 expertise,
I really don't know whether it matters in this case. Whatever the WG decides
is good, as long as the point is considered.

I hope the interim goes well, it is too far out of my time zone to attend!

Thanks
   Brian

On 05/01/2017 03:43, Thomas Watteyne wrote:
> 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
>> _______________________________________
>>
> 
> 
>