Re: [6tisch] Last Call: <draft-ietf-6tisch-minimal-17.txt> (Minimal 6TiSCH Configuration) to Best Current Practice

Ralph Droms <rdroms.ietf@gmail.com> Tue, 27 December 2016 02:44 UTC

Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6933F12956D; Mon, 26 Dec 2016 18:44:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZeOkbe2tz0F; Mon, 26 Dec 2016 18:44:29 -0800 (PST)
Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B6D129549; Mon, 26 Dec 2016 18:44:29 -0800 (PST)
Received: by mail-qk0-x241.google.com with SMTP id u25so26856618qki.2; Mon, 26 Dec 2016 18:44:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lAG6YTBudf5t+p7mUnzFK9UYV0RQJmEQlfvn7Nmv76w=; b=UyuE8gRFmquAS91ButpyH9D6V3IajrXq1+uQW59Sn047bFS52fw7AJoQbPl28F+NJG IereLrpjmqZPwIdipe5Ora0lN4GxLqabO6zHRlFKrKahQNSpssxBony3laEDnfV+w0+3 6qPzJHISWdH1kw4+Z0zMLUBcRFGYAwqQnccExqrVK64lnViV18SH5piSlOuYa1QEcSPe CP6tRKnQu3Zdd8NlNg5yY5IeVC/faxW4T5OGop9Rt2B+RCMDeMA5XJiMiYyl8M3wVObd y4Nc9UZzYgf3PTzY6CVpIdxoOQ4wFnaSzgmbYr7TlK16UFE8B/w/GsRQZl2LlerlcsDp S3ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lAG6YTBudf5t+p7mUnzFK9UYV0RQJmEQlfvn7Nmv76w=; b=KxnisaTh09zkVm2ZA6KLYP6Ar1KYGQI/yfx0m5WQvVw6HXgduy4yiSm1byvbFooaLd i1+8ikoqCXzU6x8LoaQlSuKX7OnbwplPCh1Oylwj8kQvBDALauwCTNFSRCyl04SqlGbq 7bGqY52wCvnPG2987uMXp5qwExxXIou9/R5eMQaf8de1siOXmso8xF1wGdbsxOPWHLw8 POuNgqmPCamCIHUV5Ph67M655ZSkGKYKEDuYmV0rASDJX/VxQYwlnvBkFN4saMAqy/AC oa/GXZRsy/qn8liBO7WcahayOb3lyCj1m80nad+P3WB/us3GOhcMSI0WA3R1BZ/xAGpy n9gA==
X-Gm-Message-State: AIkVDXI5W1RI5U1fqKOYZC/BmTijbf6IJO+X4QvvxeE4Eo/Ccr2ikqCjtXBfKKE4Gt8Rlg==
X-Received: by 10.55.9.15 with SMTP id 15mr28939124qkj.118.1482806668402; Mon, 26 Dec 2016 18:44:28 -0800 (PST)
Received: from ?IPv6:2601:18f:801:600:f149:b5c8:997f:84d0? ([2601:18f:801:600:f149:b5c8:997f:84d0]) by smtp.gmail.com with ESMTPSA id t62sm2081889qkc.33.2016.12.26.18.44.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Dec 2016 18:44:27 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [6tisch] Last Call: <draft-ietf-6tisch-minimal-17.txt> (Minimal 6TiSCH Configuration) to Best Current Practice
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <CAMsDxWQ1r5nVbjZBYnbSDZjuf4XFf0=63oLvFWcU=U-7Q1HpOw@mail.gmail.com>
Date: Mon, 26 Dec 2016 21:44:26 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <43CFAE07-24CA-48D5-BEE9-4EC5379B2F60@gmail.com>
References: <148103459764.1842.9947168180087183897.idtracker@ietfa.amsl.com> <D922CE22-B407-4B70-A9CB-D46DF81A338D@gmail.com> <CAMsDxWQ1r5nVbjZBYnbSDZjuf4XFf0=63oLvFWcU=U-7Q1HpOw@mail.gmail.com>
To: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/-7KPizJQmaSkE-G1wHaPBD5xOd4>
Cc: "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, IETF discussion list <ietf@ietf.org>, draft-ietf-6tisch-minimal@ietf.org, 6tisch-chairs@ietf.org, 6tisch <6tisch@ietf.org>, IETF-Announce <ietf-announce@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Dec 2016 02:44:31 -0000

Xavier - I hope the comments are helpful.

In my opinion, it would be useful for the WG as a whole to discuss the intention for the document, and review whether that intention is sufficiently well-described to guide the WG in determining the contents of the document and to guide readers in how to use the document. 

- Ralph
 
> On Dec 24, 2016, at 12:27 AM, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> wrote:
> 
> Dear Ralph,
> 
> thanks so much for your comments. We will go through them and also will consider Jonathan, Brian and Tero's comments sent some days back and provide and updated version of the document asap. 
> 
> kind regards,
> Xavi
> 
> 
> 2016-12-23 19:53 GMT+01:00 Ralph Droms <rdroms.ietf@gmail.com>om>:
> My review of draft-ietf-6tisch-minimal-17 is included below.  I recognize
> that the IETF last call has ended, and I apologize for missing the
> deadline.  I hope this review will still be useful.
> 
> In my opinion, draft-ietf-6tisch-minimal-17 has several major issues
> and is not ready for publication.
> 
> Most importantly, this document needs to explain its
> intended use.  From the Abstract: "This document describes a minimal
> mode of operation for a 6TiSCH Network."  Exactly what is a "minimal
> mode of operation"?  Is the document intended to describe:
> 
> 1) a starting point for design and deployment of a "6TiSCH network"?
> 
> 2) a baseline set of required protocols and modes of operation, which
> will be extended by future specifications (as suggested in section 1)?
> 
> 3) initial behavior that will guarantee out of the box
> interoperability among devices from, say, different vendors?
> 
> 4) something else?
> 
> As an example, if I were reading the document for point 1, I can see
> the value of pointing out, as in this rev of the document, various
> operational choices.  However, if I were reading the document for
> point 3, I don't see how interoperability can be guaranteed given the
> variety of specific choices a vendor might make in the production of a device.
> 
> Major issues regarding the document as a whole:
> 
> If this document is concerned with "IPv6 connectivity", why is there
> no mention of address selection, prefix advertisement, use of ND,
> etc.?  Similarly, why is there no advice about 6LoWPAN compression
> modes?
> 
> What is the relationship between the recommended configuration in this
> document and protocol semantics that provide the same configuration
> parameters?  For example, there are operational parameters provided in
> EBs that are also specified in this document.  How does a node choose
> which parameters to use?
> 
> A document such as this one that specifies the use of protocols
> specified elsewhere should use pointers to the other specifications
> wherever possible and should avoid repeating a description of those
> other protocols.  The danger is getting the specifications out of sync
> or describing them in a misleading or incorrect way.  In the case of
> this document, in my opinion there is text that repeats the
> description of aspects of the IEEE 802.15.4 and RPL specifications
> that should be elided.  For example, section 4.2 and 4.3 describe
> details of cell transmission that appear to be redundant relative to
> the IEEE 802.15.4 specification.
> 
> Specific issues:
> 
> From the Introduction: "a node learns the schedule of the network when
> joining, the schedule is static and the same for all nodes".  This
> statement of operational behavior seems important.  How does a node
> learn the schedule?  Is it up to the network administrator to
> configure all the nodes so that the schedule is "static and the same
> for all nodes"?  What happens if different nodes advertise different
> schedules (or other operational parameters) in EBs?  Is that situation
> considered an administrative error?
> 
> In a related issue, I found the text in section 4.1 about future use
> of unscheduled cells confusing, after the assertion that "There is
> only a single scheduled cell in the slotframe".
> 
> Similarly, in section 4.2, if the schedule is static, why is it
> necessary to state that "The scheduled cell... cannot be moved or
> relocated by any dynamic scheduling mechanism"?
> 
> Section 4.4 seems to me to be a rewording of the IEEE 802.15.4
> specification.  Is there some specific reason that the text is
> included here?
> 
> In section 5.1.1, the description of ETX computation "ETX is computed
> using the reception/non-reception of link-layer ACKs" doesn't seem to
> give enough information, while RFC 6551 specifically "does not mandate
> the use of a specific formula to compute the ETX value".  RFC 6551
> describes ETX as a constraint or as a path metric; in the latter case,
> ETX is cumulative from the node to the DAG root.  How is ETX
> computed for this application?
> 
> In section 5.2, what does the word "supported" mean?  Which mode of
> operation should be implemented according to this specification?
> 
> I don't understand the relation between sections 6.2, "Initial Time
> Source Neighbor Selection", 6.4, "Time Source Neighbor Selection" and
> section 6.5, "Hysteresis".  In particular, section 6.4 seems to give
> only a requirement that a node must have a selected time source
> neighbor, but gives no advice on how the node makes the selection.
> 
> Editorial issues:
> 
> In the Introduction, why is RPL called out specifically as a "natural
> choice" without any justification?  Why not just give the explicit
> explanation that RPL is specified to provide the framework for
> IEEE802.15.4 time sync?
> 
> Check for consistency of parameter names and protocol fields; e.g., I
> assume macTsRxAckDelay and tsRxAckDelay refer to the same information
> element.
> 
> In section 4.1, this instance of "MAY" is not an RFC 2119 usage:
> "Dynamic scheduling solutions MAY be defined in the future [...]"
> 
> In section 4.5.1, the first and third sentences seem to be redundant.
> 
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>