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 |