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

Ralph Droms <> Fri, 23 December 2016 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4E89129715; Fri, 23 Dec 2016 10:53:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I-2ZmAqIRzBZ; Fri, 23 Dec 2016 10:53:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5183A129704; Fri, 23 Dec 2016 10:53:42 -0800 (PST)
Received: by with SMTP id 3so8157725qtr.2; Fri, 23 Dec 2016 10:53:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N15NpBAhqeViNZtpNxLGEYsHw+aCwphddKmtsG8LPF0=; b=Os+erowfCB6sE7cozXrMBSqophsCSMd8VOYEx3CCsskoGBUEytkXtgdMYuKOc0ju7t PePI5co9UGl5MnL3a53icTwO+fWLwFBzPiJJ24LYct9Z7jBEigfIQLzulpD33VX7K3eE Js3cYQ3DV+UNCtutiy478dX1GGH6Rnwf2IPBOtiSMwfgiWPt6tB/itWSkzUU+SSY8jfX gni2AyLE+Z4Uf+8eqIa/AbTfUlM/eYGt04yTxud4GpxtJsuR539r8IPnpouCZnsBoki/ U6KmsO93gtZtZSqOD8l5/sahB+mKDsCjtI9ZgFV2nCHLjReU2SpL8GOp8FK2LPJRzASh qDsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N15NpBAhqeViNZtpNxLGEYsHw+aCwphddKmtsG8LPF0=; b=VsifyG2sTGsE1NvFQMU4THSkxogk3AVBZwFSjTCKf4Hew1CFEyTen22X20Xw6Qeiyu erU2+XCM0ttWULUO977SdI2lddtxqYI3fflooIelaxSDK9VXs+hUsic6dfeq0ar3JdQC Jbo/yVt6wS24fKlU7Vl5FjwYrxx7HYEbaACvEcNVrV9n1wEXVTgW4uqd3Voo5PW2aMns fFkB0iH5uHYQLj4WwMnu56y+3Qn79eylKbYhFBU+uDQDEkTTLChRsTWkG7PNDiaflsis MhjsadNcG2dy7EXRgWISvsl615sRz4vYcoIF9C1cWwL7B7x8FRdfoKd3Mf2O9LnchscO Tkfg==
X-Gm-Message-State: AIkVDXLH17eQidwItcL5X+XbTbn2/sQAXNblj8UxvAe8PDTBIJmJGvsXjj9JTiidOSyPdQ==
X-Received: by with SMTP id s26mr15951519qtc.114.1482519221367; Fri, 23 Dec 2016 10:53:41 -0800 (PST)
Received: from ?IPv6:2601:18f:801:600:1d9e:36e6:f4f1:7343? ([2601:18f:801:600:1d9e:36e6:f4f1:7343]) by with ESMTPSA id t62sm2123169qkh.26.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Dec 2016 10:53:40 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6tisch-minimal-17.txt> (Minimal 6TiSCH Configuration) to Best Current Practice
From: Ralph Droms <>
In-Reply-To: <>
Date: Fri, 23 Dec 2016 13:53:36 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc:, 6tisch <>,,, IETF-Announce <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Dec 2016 18:53:46 -0000

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

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

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.