Skip to main content

Improving Awareness of Running Code: The Implementation Status Section
draft-sheffer-rfc6982bis-03

Revision differences

Document history

Date Rev. By Action
2016-07-07
03 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2016-06-29
03 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2016-06-29
03 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2016-06-13
03 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Eric Vyncke.
2016-06-06
03 (System) RFC Editor state changed to EDIT
2016-06-06
03 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-06-06
03 (System) Announcement was received by RFC Editor
2016-06-06
03 (System) IANA Action state changed to No IC from In Progress
2016-06-06
03 (System) IANA Action state changed to In Progress
2016-06-06
03 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2016-06-06
03 Amy Vezza IESG has approved the document
2016-06-06
03 Amy Vezza Closed "Approve" ballot
2016-06-06
03 Amy Vezza Ballot approval text was generated
2016-06-06
03 Amy Vezza Ballot writeup was changed
2016-06-02
03 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2016-06-02
03 Yaron Sheffer New version available: draft-sheffer-rfc6982bis-03.txt
2016-06-02
02 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-06-02
02 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-06-02
02 Yaron Sheffer IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2016-06-02
02 Yaron Sheffer New version available: draft-sheffer-rfc6982bis-02.txt
2016-06-02
01 Benoît Claise
[Ballot comment]
Editorial
OLD:

  We
  recommend that the Implementation Status section should be removed
  from Internet-Drafts before they are published as RFCs.  …
[Ballot comment]
Editorial
OLD:

  We
  recommend that the Implementation Status section should be removed
  from Internet-Drafts before they are published as RFCs.  As a result,
  we do not envisage changes to this section after approval of the
  document for publication, e.g., the RFC errata process does not
  apply.

NEW:
  We
  recommend that the Implementation Status section should be removed
  from Internet-Drafts before they are published as RFCs.  As a result,
  we do not envisage changes to this section after approval of the
  document for publication, while the document sits in the RFC-editor
  queue, e.g., the RFC errata process does not apply.

Editorial:
OLD:
  The inclusion of Implementation Status sections in Internet-Drafts is
  not mandatory, but the authors of this document wish to encourage
  authors of other Internet-Drafts to try out this simple mechanism to
  discover whether it is useful.

NEW:
 
Justification.
We passed the experimentation phase already (no need to try out this simple mechanism to discover whether it is useful), this is now a BCP.
Also, this is already covered by:
  This process is not mandatory.  Authors of Internet-Drafts are
  encouraged to consider using the process for their documents, and
  working groups are invited to think about applying the process to all
  of their protocol specifications.
2016-06-02
01 Benoît Claise [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise
2016-06-01
01 Suresh Krishnan
[Ballot comment]
* There are two fields I would have liked to see added into the implementation status section.

1) A datestamp for each implementation …
[Ballot comment]
* There are two fields I would have liked to see added into the implementation status section.

1) A datestamp for each implementation to denote when the implementation was added to the draft or was last updated (to determine freshness)
2) Draft version number that was implemented (as drafts can change significantly during the wg process)

I also agree with Alissa's and Ben's comments about the use of wikis.
2016-06-01
01 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2016-06-01
01 Alia Atlas [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas
2016-06-01
01 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2016-06-01
01 Ben Campbell
[Ballot comment]
I agree with Alissa's comment about wikis, etc. In addition to her reasoning, I think the wiki alternative has the advantage (mentioned in …
[Ballot comment]
I agree with Alissa's comment about wikis, etc. In addition to her reasoning, I think the wiki alternative has the advantage (mentioned in the draft) of preserving the information after RFC publication. Perhaps it would be useful to suggest that, when the implementation status is removed from an RFC at publication, it be preserved (and hopefully maintained) _somewhere_, whether a wiki or something else.
2016-06-01
01 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2016-05-31
01 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-05-31
01 Alissa Cooper
[Ballot comment]
I have a question and a comment.

I noticed that one item missing from the list in Section 2 is a link to …
[Ballot comment]
I have a question and a comment.

I noticed that one item missing from the list in Section 2 is a link to the implementation itself, if available. I guess this is sort of implied by the collection of the rest of the other elements listed, but seems like a strange omission nonetheless. Is there a reason for it not to be listed? I understand that this is the same text from RFC 6982.

I realize that documenting implementation status in the way this document recommends is better than some alternatives (like not documenting it, or doing so haphazardly), but I'm not convinced that this really is the best way to feed implementation status information into the IETF process and vice versa. At a minimum a wiki where implementors can make their own updates seems preferable to a document controlled by its authors, yet the wiki option here is described as an alternative rather than the default approach.
2016-05-31
01 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2016-05-30
01 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2016-05-30
01 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2016-05-30
01 Mirja Kühlewind [Ballot Position Update] New position, Yes, has been recorded for Mirja Kühlewind
2016-05-27
01 Kathleen Moriarty [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty
2016-05-26
01 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2016-05-26
01 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2016-05-21
01 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2016-05-17
01 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2016-05-13
01 Stephen Farrell Placed on agenda for telechat - 2016-06-02
2016-05-13
01 Stephen Farrell IESG state changed to IESG Evaluation from Waiting for Writeup
2016-05-13
01 Stephen Farrell Ballot has been issued
2016-05-13
01 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2016-05-13
01 Stephen Farrell Created "Approve" ballot
2016-05-13
01 Stephen Farrell Ballot writeup was changed
2016-05-13
01 Yaron Sheffer IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2016-05-13
01 Yaron Sheffer New version available: draft-sheffer-rfc6982bis-01.txt
2016-05-13
00 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-05-05
00 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Adam Montville.
2016-04-28
00 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-sheffer-rfc6982bis-00.txt, which is currently in Last Call, and has the following comments:

We understand that this …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-sheffer-rfc6982bis-00.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN
2016-04-28
00 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2016-04-21
00 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2016-04-21
00 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2016-04-18
00 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2016-04-18
00 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2016-04-18
00 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Eric Vyncke
2016-04-18
00 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Eric Vyncke
2016-04-15
00 Amy Vezza IANA Review state changed to IANA - Review Needed
2016-04-15
00 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-sheffer-rfc6982bis@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Improving Awareness …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-sheffer-rfc6982bis@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Improving Awareness of Running Code: The Implementation Status Section) to Best Current Practice


The IESG has received a request from an individual submitter to consider
the following document:
- 'Improving Awareness of Running Code: The Implementation Status
Section'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-05-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a simple process that allows authors of
  Internet-Drafts to record the status of known implementations by
  including an Implementation Status section.  This will allow
  reviewers and working groups to assign due consideration to documents
  that have the benefit of running code, which may serve as evidence of
  valuable experimentation and feedback that have made the implemented
  protocols more mature.

  This process is not mandatory.  Authors of Internet-Drafts are
  encouraged to consider using the process for their documents, and
  working groups are invited to think about applying the process to all
  of their protocol specifications.  This document obsoletes RFC 6982,
  advancing it to a Best Current Practice.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-sheffer-rfc6982bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-sheffer-rfc6982bis/ballot/


No IPR declarations have been submitted directly on this I-D.


2016-04-15
00 Amy Vezza
6TSCH                                                  …
6TSCH                                                  T. Watteyne, Ed.
Internet-Draft                                        Linear Technology
Intended status: Informational                        February 21, 2013
Expires: August 25, 2013

              Using IEEE802.15.4e TSCH in an LLN context:
                Overview, Problem Statement and Goals
                draft-watteyne-6tsch-tsch-lln-context-01

Abstract

  This document describes the environment, problem statement, and goals
  for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs.
  The set of goals enumerated in this document form an initial set
  only.

Status of this Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF).  Note that other groups may also distribute
  working documents as Internet-Drafts.  The list of current Internet-
  Drafts is at http://datatracker.ietf.org/drafts/current/.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  This Internet-Draft will expire on August 25, 2013.

Copyright Notice

  Copyright (c) 2013 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect
  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.

Watteyne                Expires August 25, 2013                [Page 1]
Internet-Draft          6tsch-tsch-lln-context            February 2013

Table of Contents

  1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.  TSCH in the LLN Context  . . . . . . . . . . . . . . . . . . .  5
  3.  Problems and Goals . . . . . . . . . . . . . . . . . . . . . .  7
    3.1.  Network Formation  . . . . . . . . . . . . . . . . . . . .  7
    3.2.  Network Maintenance  . . . . . . . . . . . . . . . . . . .  7
    3.3.  Multi-Hop Topology . . . . . . . . . . . . . . . . . . . .  8
    3.4.  Routing and Timing Parents . . . . . . . . . . . . . . . .  8
    3.5.  Resource Management  . . . . . . . . . . . . . . . . . . .  8
    3.6.  Dataflow Control . . . . . . . . . . . . . . . . . . . . .  9
    3.7.  Deterministic Behavior . . . . . . . . . . . . . . . . . .  9
    3.8.  Path Computation Engine  . . . . . . . . . . . . . . . . .  9
    3.9.  Secure Communication . . . . . . . . . . . . . . . . . . . 10
  4.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
  5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
  6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
    6.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
    6.2.  Informative References . . . . . . . . . . . . . . . . . . 13
    6.3.  External Informative References  . . . . . . . . . . . . . 15
  Appendix A.  TSCH Protocol Highlights  . . . . . . . . . . . . . . 19
    A.1.  Timeslots  . . . . . . . . . . . . . . . . . . . . . . . . 19
    A.2.  Slotframes . . . . . . . . . . . . . . . . . . . . . . . . 19
    A.3.  Mote Communication Schedule  . . . . . . . . . . . . . . . 19
    A.4.  Links and Paths  . . . . . . . . . . . . . . . . . . . . . 20
    A.5.  Dedicated vs. Shared Slots . . . . . . . . . . . . . . . . 20
    A.6.  Absolute Slot Number . . . . . . . . . . . . . . . . . . . 21
    A.7.  Channel Hopping  . . . . . . . . . . . . . . . . . . . . . 21
    A.8.  Time Synchronization . . . . . . . . . . . . . . . . . . . 22
    A.9.  Power Consumption  . . . . . . . . . . . . . . . . . . . . 23
    A.10. Network Communication Schedule . . . . . . . . . . . . . . 23
    A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . . 23
    A.12. Information Elements . . . . . . . . . . . . . . . . . . . 24
    A.13. Extensibility  . . . . . . . . . . . . . . . . . . . . . . 24
  Appendix B.  TSCH Gotchas  . . . . . . . . . . . . . . . . . . . . 25
    B.1.  Collision Free Communication . . . . . . . . . . . . . . . 25
    B.2.  Multi-Channel vs. Channel Hopping  . . . . . . . . . . . . 25
    B.3.  Cost of (continuous) Synchronization . . . . . . . . . . . 25
    B.4.  Topology Stability . . . . . . . . . . . . . . . . . . . . 26
    B.5.  Multiple Concurrent Slotframes . . . . . . . . . . . . . . 26
  Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27

Watteyne                Expires August 25, 2013                [Page 2]
Internet-Draft          6tsch-tsch-lln-context            February 2013

1.  Introduction

  The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an
  amendment to the Medium Access Control (MAC) protocol defined by the
  IEEE802.15.4-2011 [IEEE802154] standard.  The Timeslotted Channel
  Hopping (TSCH) mode of IEEE802.15.4e is the object of this document.

  TSCH was designed to "allow IEEE802.15.4 devices to support a wide
  range of industrial applications" [IEEE802154e].  At its core is a
  medium access technique which uses time synchronization to achieve
  ultra low-power operation and channel hopping to enable high
  reliability.  This is very different from the "legacy" IEEE802.15.4
  MAC protocol, and is therefore better described as a "redesign".
  TSCH does not amend the physical layer; i.e., it can operate on any
  IEEE802.15.4-compliant hardware.

  IEEE802.15.4e can be seen as the latest generation of ultra-lower
  power and reliable networking solutions for LLNs.  Its core
  technology is similar to the one used in industrial networking
  technologies such as WirelessHART [WHART] or ISA100.11a [ISA100].
  These protocol solutions have been targeted essentially at the
  industrial market.  WirelessHART is for example the wireless
  extension of HART, a long standing protocol suite for networking
  industrial equipment.

  [RFC5673] discusses industrial applications, and highlights the harsh
  operating conditions as well as the stringent reliability,
  availability, and security requirements for an LLN to operate in an
  industrial environment.  Industrial protocols such as WirelessHART
  satisfy those requirements, and with tens of thousands of networks
  deployed [Emerson], these types of networks have a large impact on
  industrial applications.  Commercial networking solutions are
  available today in which motes consume 10's of micro-amps on average
  [CurrentCalculator] with end-to-end packet delivery ratios over
  99.999% [doherty07channel].

  IEEE802.15.4e builds on the same foundations as WirelessHART, and
  therefore exhibits similar performance.  Yet, unlike an industrial
  protocol which is, by nature, application-specific, IEEE802.15.4e
  TSCH focuses on the MAC layer only.  This clean layering allows for
  TSCH to fit under an IPv6 enabled protocol stack for LLNs, running
  6LoWPAN [RFC6282], RPL [RFC6550] and CoAP [I-D.ietf-core-coap].

  Bringing industrial-like performance into the LLN stack developed by
  the 6LoWPAN, ROLL and CORE working groups opens up new application
  domains for these networks.  Sensors deployed in smart cities
  [RFC5548] will be able to be installed for years without needing
  battery replacement.  "Umbrella" networks will interconnect smart

Watteyne                Expires August 25, 2013                [Page 3]
2016-04-15
00 Stephen Farrell Notification list changed to yaronf.ietf@gmail.com, adrian@olddog.co.uk
2016-04-15
00 Stephen Farrell Last call was requested
2016-04-15
00 Stephen Farrell Ballot approval text was generated
2016-04-15
00 Stephen Farrell Ballot writeup was generated
2016-04-15
00 Stephen Farrell IESG state changed to Last Call Requested from Publication Requested
2016-04-15
00 Stephen Farrell Last call announcement was generated
2016-04-15
00 Stephen Farrell IESG process started in state Publication Requested
2016-04-15
00 Stephen Farrell Shepherding AD changed to Stephen Farrell
2016-04-15
00 Stephen Farrell Changed consensus to Yes from Unknown
2016-04-15
00 Stephen Farrell Intended Status changed to Best Current Practice from None
2016-04-15
00 Stephen Farrell Stream changed to IETF from None
2016-04-14
00 Yaron Sheffer New version available: draft-sheffer-rfc6982bis-00.txt