Skip to main content

6TiSCH Operation Sublayer (6top) Protocol (6P)
draft-ietf-6tisch-6top-protocol-12

Revision differences

Document history

Date Rev. By Action
2018-10-29
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-09-27
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-09-21
12 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2018-09-20
12 (System) RFC Editor state changed to AUTH from EDIT
2018-08-22
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-08-22
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-08-22
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-08-20
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-08-20
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-08-17
12 (System) IANA Action state changed to Waiting on Authors
2018-08-16
12 (System) RFC Editor state changed to EDIT
2018-08-16
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-08-16
12 (System) Announcement was received by RFC Editor
2018-08-16
12 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-08-16
12 Cindy Morgan IESG has approved the document
2018-08-16
12 Cindy Morgan Closed "Approve" ballot
2018-08-16
12 Cindy Morgan Ballot approval text was generated
2018-08-16
12 Suresh Krishnan IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-07-17
12 Thomas Watteyne Added to session: IETF-102: 6tisch  Wed-1330
2018-07-17
12 Thomas Watteyne Removed from session: IETF-102: 6tisch  Wed-1330
2018-07-17
12 Thomas Watteyne Added to session: IETF-102: 6tisch  Wed-1330
2018-07-17
12 Thomas Watteyne Removed from session: IETF-102: 6tisch  Wed-1330
2018-07-17
12 Thomas Watteyne Added to session: IETF-102: 6tisch  Wed-1330
2018-07-03
12 Benjamin Kaduk
[Ballot comment]
Thank you for resolving my DISCUSS; original COMMENT section preserved below.

The CellList and CellOptions fields can effectively be redefined by the SF, …
[Ballot comment]
Thank you for resolving my DISCUSS; original COMMENT section preserved below.

The CellList and CellOptions fields can effectively be redefined by the SF, so the document only gives
interpretations for them that are referred to as "RECOMMENDED", which is a bit jarring since they seem
to be expected to be the default values.  Perhaps it would be better to say that the descriptions in this
document are the "default interpretation unless redefined by the SF in use".


In several places we see:

  CellList:  A list of 0, 1 or multiple candidate cells.

How about "0 or more"?  Also, the "Its length is [...]" is not
universally present as the next sentence.


As another general note, it might be useful to say a bit more about the fields in the Response and
Confirmation messages, i.e., give a list of fields which must match the ones in the corresponding Request.

Section 3.3.3

  Upon receiving the request, Node B checks if the length of the
  Candidate CellList is larger or equal to NumCells.  Node B's SF
  verifies that all the cells in the Relocation CellList are indeed
  scheduled with node A, and are associate the options specified in the
  CellOptions field.  If that check fails, node B MUST send a 6P
  Response to node A with return code RC_ERR_CELLLIST.  If that check
  passes,

I think this should be "if either check fails" and "if both checks
pass".


Section 3.3.6

If link-level access message protection is not in use, the ability to inject a CLEAR message
with no SeqNum checking seems a fairly powerful capability to give to an attacker.  I don't
immediately see a way around it, but this would be a candidate for inclusion in an expanded
Security Considerations.

Section 3.3.7

Do we need to explicitly say that the SIGNAL payload's length is determined by the length
of the IE header?

Section 3.4.3 is perhaps a bit underspecified.
In particular, does "consider it never happened" include reusing
that SeqNum for the next transaction?

Section 3.4.6
Is there value in using the term "lollipop counter" when the
behavior needs to be defined here anyway?

Section 3.4.6.2

I'd be interested to see an example where the node that has
power-cycled is the one sending the request that triggers
inconsistency detection.

Section 5

  [...] These cases
  SHOULD be handled by an appropriate policy, such as blacklisting the
  attacker after several attempts.

It's not clear that pure blacklisting is always an appropriate
policy.  Rate-limiting or time-limited blacklisting might be a more
appropriate example.

Though key management is out of scope, it may be worth explicitly mentioning
that forgery and misattribution attacks become more damaging when a single
key is shared amongst a group of more than 2 participants.


In the IANA considerations, should the new subregistries (e.g., message types and CellOptions
bitmap) be scoped down to just 6P version 0 or are they intended to be version-agnostic?
2018-07-03
12 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2018-06-27
12 Alexey Melnikov [Ballot comment]
Thank you for addressing my DISCUSS and some of the comments.
2018-06-27
12 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss
2018-06-20
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-06-20
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2018-06-20
12 Xavier Vilajosana New version available: draft-ietf-6tisch-6top-protocol-12.txt
2018-06-20
12 (System) New version approved
2018-06-20
12 (System) Request for posting confirmation emailed to previous authors: Qin Wang , Xavier Vilajosana , Thomas Watteyne
2018-06-20
12 Xavier Vilajosana Uploaded new revision
2018-06-08
11 Bernie Volz Closed request for Early review by INTDIR with state 'No Response'
2018-05-07
11 Gunter Van de Velde Closed request for Telechat review by OPSDIR with state 'No Response'
2018-04-19
11 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2018-04-05
11 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-04-05
11 Ignas Bagdonas [Ballot comment]
Have read through the document but did not perform a detailed review.
2018-04-05
11 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-04-05
11 Alexey Melnikov
[Ballot discuss]
Thank you for a well written document. I have a small list of questions/comments, which I would like to discuss before recommending approval …
[Ballot discuss]
Thank you for a well written document. I have a small list of questions/comments, which I would like to discuss before recommending approval of this document:

1) 3.3.2.  Deleting Cells

  o  The CellList in a 6P Request (2-step transaction) or 6P Response
      (3-step transaction) MUST either be empty, contain exactly
      NumCells cells, or more than NumCells cells.

What is the meaning of "more than NumCells cells" in case of DELETE?

      The case where the
      CellList is not empty but contains less than NumCells cells is not
      supported.

2) 3.4.7.  Handling Error Responses

How should unrecognized error codes be treated by recipients? For example if one of the nodes is implementing an extension and the other node doesn't support such extension.

I think adding some text to this section would help.

3) 4.2.  Requirements for an SF

  o  MAY redefine the format of the CellList field.
  o  MAY redefine the format of the CellOptions field.
  o  MAY redefine the meaning of the CellOptions field.

I am a concerned about interoperability problems that might result from these requirements. Can you elaborate on what kind of format changes you are expecting?
Wouldn't such changes require some sort of extension (e.g. use of a new extended ADD command)?
2018-04-05
11 Alexey Melnikov
[Ballot comment]
I am agreeing with Benjamin's DISCUSS about versioning. I think you need to describe in a bit more details which messages/parts of protocol …
[Ballot comment]
I am agreeing with Benjamin's DISCUSS about versioning. I think you need to describe in a bit more details which messages/parts of protocol should remain unchanged for forward compatibility with future versions.

Additionally:

3.2.2.  Generic 6P Message Format

  6P Version (Version):  The version of the 6P protocol.  Only version
        0 is defined in this document.  Future specifications MAY
        define further versions of the 6P protocol.

Use of MAY in the last sentence doesn't seem correct, as there is no way to test conformance to it.
I suggest you just change it to lowercase "may" and add boilerplate to reference RFC 8174 in addition to RFC 2119.


3.3.2.  Deleting Cells

  o  If the CellList in the 6P Request is empty, the SF on the
      receiving node SHOULD delete any cell from the sender, as long as

Did you mean "all" instead of "any"?

      it matches the CellOptions field.

3.3.5.  Listing Cells

  When node B receives a LIST request, the returned CellList in the 6P
  Response contains between 1 and MaxNumCells cells,

Here you say "between 1 and MaxNumCells".

  starting from the
  specified offset.  Node B SHOULD include as many cells as fit in the
  frame.  If the response contains the last cell, Node B MUST set the
  Code field in the response to RC_EOL ("End of List", as per
  Figure 37), indicating to Node A that there no more cells that match
  the request.  Node B MUST return at least one cell, unless the
  specified Offset is beyond the end of B's cell list in its schedule.
  If node B has less than Offset cells that match the request, node B
  returns an empty CellList and a Code field set to RC_EOL.

And here you say that 0 is allowed. You should update the above to say "between 0 and MaxNumCells".
2018-04-05
11 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from No Record
2018-04-05
11 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-04-04
11 Adam Roach
[Ballot comment]
Thanks to everyone who worked on this document. I have a handful of minor,
editorial suggestions.

---------------------------------------------------------------------------

Please expand TSCH and 2TiSCH in …
[Ballot comment]
Thanks to everyone who worked on this document. I have a handful of minor,
editorial suggestions.

---------------------------------------------------------------------------

Please expand TSCH and 2TiSCH in the Abstract.

---------------------------------------------------------------------------

§3.1.1:

>  5.  The SF running on node B selects 2 out of the 3 cells from the
>      CellList of the 6P ADD Request.  Node B locks those cells in it

nit: "its"

>      schedule until the transmission is successfull (i.e. node B

nit: "successful"

---------------------------------------------------------------------------

§3.3.1:

>  be used), or partially succeed (less than NumCells cells from the

Nit: "fewer than" rather than "less than."

---------------------------------------------------------------------------

§3.3.2:

>  o  The CellList in a 6P Request (2-step transaction) or 6P Response
>    (3-step transaction) MUST either be empty, contain exactly
>    NumCells cells, or more than NumCells cells.  The case where the
>    CellList is not empty but contains less than NumCells cells is not
>    supported.

nit: "...fewer than..."

It would be a good idea to clearly indicate what a recipient of a message with a
non-empty CellList with fewer entries than NumCells requires should do. This is
also applicable for the "Candidate CellList" for RELOCATE. I can't find
equivalent language for ADD -- is it okay for a message to (for example) have a
NumCells value of 3, but include only 2 cells in its CellList?

---------------------------------------------------------------------------

§3.3.3:

>  verification on Candidate CellList can succeed (NumCells cells from
>  the Candidate CellList can be used), fail (none of the cells from the
>  Candidate CellList can be used) or partially succeed (less than
>  NumCells cells from the Candidate CellList can be used).  In all


nit: "...fewer than..."

---------------------------------------------------------------------------

§3.3.5:

>  MaxNumCells:  The maximum number of cells to be listed.  Node B MAY
>        return less than MaxNumCells cells, for example if MaxNumCells
>        cells do not fit in the frame.

nit: "...fewer than..."

>  If node B has less than Offset cells that match the request, node B
>  returns an empty CellList and a Code field set to RC_EOL.

nit: "...fewer than..."
2018-04-04
11 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2018-04-04
11 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-04-04
11 Eric Rescorla
[Ballot comment]
I support Ben's DISCUSS

As I read this document, this only works if two nodes are running the same SF. Do you think …
[Ballot comment]
I support Ben's DISCUSS

As I read this document, this only works if two nodes are running the same SF. Do you think you could make that point earlier in the document?
2018-04-04
11 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-04-04
11 Alexey Melnikov
[Ballot comment]
I haven't finished reading the document, so I am sending the comments I've accumulated so far.

I am agreeing with Benjamin's DISCUSS about …
[Ballot comment]
I haven't finished reading the document, so I am sending the comments I've accumulated so far.

I am agreeing with Benjamin's DISCUSS about versioning.

Additionally:

3.2.2.  Generic 6P Message Format

  6P Version (Version):  The version of the 6P protocol.  Only version
        0 is defined in this document.  Future specifications MAY
        define further versions of the 6P protocol.

Use of MAY in the last sentence doesn't seem correct, as there is no way to test conformance to it.
I suggest you just change it to lowercase "may" and add boilerplate to reference RFC 8174 in addition to RFC 2119.


3.3.2.  Deleting Cells

  o  If the CellList in the 6P Request is empty, the SF on the
      receiving node SHOULD delete any cell from the sender, as long as

Did you mean "all" instead of "any"?

      it matches the CellOptions field.

  o  The CellList in a 6P Request (2-step transaction) or 6P Response
      (3-step transaction) MUST either be empty, contain exactly
      NumCells cells, or more than NumCells cells.

What is the meaning of "more than NumCells cells" in case of DELETE?

      The case where the
      CellList is not empty but contains less than NumCells cells is not
      supported.


3.3.5.  Listing Cells

  When node B receives a LIST request, the returned CellList in the 6P
  Response contains between 1 and MaxNumCells cells,

Here you say "between 1 and MaxNumCells".

  starting from the
  specified offset.  Node B SHOULD include as many cells as fit in the
  frame.  If the response contains the last cell, Node B MUST set the
  Code field in the response to RC_EOL ("End of List", as per
  Figure 37), indicating to Node A that there no more cells that match
  the request.  Node B MUST return at least one cell, unless the
  specified Offset is beyond the end of B's cell list in its schedule.
  If node B has less than Offset cells that match the request, node B
  returns an empty CellList and a Code field set to RC_EOL.

And here you say that 0 is allowed. You should update the above to say "between 0 and MaxNumCells".
2018-04-04
11 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2018-04-04
11 Mirja Kühlewind
[Ballot comment]
Thanks for the well-written and easy to read document. Only section 3.2.3. is a bot confusing as TX, RX, and S show up …
[Ballot comment]
Thanks for the well-written and easy to read document. Only section 3.2.3. is a bot confusing as TX, RX, and S show up in the table but are not really explained at all (besides in the IANA considerations at the very end).

Some more, mostly editorial comment:

1) sec 3.2.3: "The CellOptions is an opaque set of bits, sent unmodified to the SF.
  The SF MAY redefine the format and meaning of the CellOptions field."
  Not sure you can say that the celloptions bits are opaque given you define them in this section...

2) In sec 3.3.1:
"NumCandidate MUST be larger or equal to NumCells."
What happens if that is not the case. Should node B assign the requested cells anyway, or send an error, or both?

and also in section 3.3.2:
"The case where the CellList is not empty but contains less than NumCells cells is not supported."
What does that mean? Should an error be sent or the message just ignored?

3) Not sure if the "6P Version Numbers" registry is really needed at this point of time. I guess if many new versions show up, it would still be time to create this registry with the next version.
2018-04-04
11 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-04-03
11 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2018-04-03
11 Ben Campbell
[Ballot comment]
Substantive Comments:

Requirements Language: The document contains at least a few instances of lower case "must". Please consider using the boilerplate from RFC …
[Ballot comment]
Substantive Comments:

Requirements Language: The document contains at least a few instances of lower case "must". Please consider using the boilerplate from RFC 8174.

§3.1.1, figure 4: Did I miss an explanation of why A sends 3 candidate cells when it needs 2 new cells? I can guess why, but it would be best to explicitly explain it.

§6.2.2 and §6.2.3: Do you really expect new message types and commands to be added routinely enough to justify
a registry?

Editorial Comments and Nits:

Abstract: Please expand 6top on first mention.  You do so later in the paragraph, but not the first time. (This pattern repeats in the document body)

§1: Please expand 6TiSCH on first mention.

§3.1.1, Figure 4, step 2: "Node A locks the candidate cells in it schedule until..." doesn't parse. Should "it" be "its"?

§4: This section seems to be about 6top scheduling function _specification_, not the functions themselves. Is this correct?

Appendix A: Seems like this should be part of the IANA considerations.
2018-04-03
11 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-04-03
11 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-04-03
11 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-04-03
11 Alvaro Retana
[Ballot comment]
(1) S3.2.2: "The value of SeqNum MUST be different at each new 6P Request issued to the same neighbor." Should that be "...different...to …
[Ballot comment]
(1) S3.2.2: "The value of SeqNum MUST be different at each new 6P Request issued to the same neighbor." Should that be "...different...to the same neighbor and SF"?  S3.4.6 talks about maintaining independent SeqNums per neighbor, per SF.

(2) S3.2.3: "The SF MAY redefine the format and meaning of the CellOptions field."  If the "RECOMMENDED" values are expected to be the default, how are changes to the formatting/meaning communicated between A and B?

(3) S3.2.4: "The CellList is an opaque set of bytes, sent unmodified to the SF."  Given that A and B don't really know what the contents of the CellList are, or even if the "RECOMMENDED format" is followed, I don't see the need to Normatively define the Cell Format.  IOW, s/RECOMMENDED/recommended
2018-04-03
11 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-04-03
11 Alvaro Retana This document now replaces draft-wang-6tisch-6top-protocol instead of None
2018-04-02
11 Benjamin Kaduk
[Ballot discuss]
Section 3.5 states:

  [...] When link-layer
  security is enabled, the 6P messages MUST be secured.

but Section 5 (the Security Considerations) …
[Ballot discuss]
Section 3.5 states:

  [...] When link-layer
  security is enabled, the 6P messages MUST be secured.

but Section 5 (the Security Considerations) says:

  6P messages are carried inside 802.15.4 Payload Information Elements
  (IEs).  Those Payload IEs are encrypted and authenticated at the link
  layer through CCM* [CCM-Star].

implying that this message protection is always enabled.  So, which is it -- always-on, or (application)-controlled?
If use of link-layer security is optional, then the security considerations for the case without link-layer security
should be documented.


Separately, Section 3.2.2 describes the generic message format, but only for version 0.
Some indication should be given as to which aspects of the format are required to be invariant
across all versions of 6P (and thus which aspects are potentially specific to version 0).
Some readers might assume that only the version nybble is invariant (though there also seems to
be a requirement in Section 3.4.1 that the RC_ERR_VERSION response remain invariant to some extent).
2018-04-02
11 Benjamin Kaduk
[Ballot comment]
The CellList and CellOptions fields can effectively be redefined by the SF, so the document only gives
interpretations for them that are referred …
[Ballot comment]
The CellList and CellOptions fields can effectively be redefined by the SF, so the document only gives
interpretations for them that are referred to as "RECOMMENDED", which is a bit jarring since they seem
to be expected to be the default values.  Perhaps it would be better to say that the descriptions in this
document are the "default interpretation unless redefined by the SF in use".


In several places we see:

  CellList:  A list of 0, 1 or multiple candidate cells.

How about "0 or more"?  Also, the "Its length is [...]" is not
universally present as the next sentence.


As another general note, it might be useful to say a bit more about the fields in the Response and
Confirmation messages, i.e., give a list of fields which must match the ones in the corresponding Request.

Section 3.3.3

  Upon receiving the request, Node B checks if the length of the
  Candidate CellList is larger or equal to NumCells.  Node B's SF
  verifies that all the cells in the Relocation CellList are indeed
  scheduled with node A, and are associate the options specified in the
  CellOptions field.  If that check fails, node B MUST send a 6P
  Response to node A with return code RC_ERR_CELLLIST.  If that check
  passes,

I think this should be "if either check fails" and "if both checks
pass".


Section 3.3.6

If link-level access message protection is not in use, the ability to inject a CLEAR message
with no SeqNum checking seems a fairly powerful capability to give to an attacker.  I don't
immediately see a way around it, but this would be a candidate for inclusion in an expanded
Security Considerations.

Section 3.3.7

Do we need to explicitly say that the SIGNAL payload's length is determined by the length
of the IE header?

Section 3.4.3 is perhaps a bit underspecified.
In particular, does "consider it never happened" include reusing
that SeqNum for the next transaction?

Section 3.4.6
Is there value in using the term "lollipop counter" when the
behavior needs to be defined here anyway?

Section 3.4.6.2

I'd be interested to see an example where the node that has
power-cycled is the one sending the request that triggers
inconsistency detection.

Section 5

  [...] These cases
  SHOULD be handled by an appropriate policy, such as blacklisting the
  attacker after several attempts.

It's not clear that pure blacklisting is always an appropriate
policy.  Rate-limiting or time-limited blacklisting might be a more
appropriate example.

Though key management is out of scope, it may be worth explicitly mentioning
that forgery and misattribution attacks become more damaging when a single
key is shared amongst a group of more than 2 participants.


In the IANA considerations, should the new subregistries (e.g., message types and CellOptions
bitmap) be scoped down to just 6P version 0 or are they intended to be version-agnostic?
2018-04-02
11 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2018-04-02
11 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-04-01
11 Suresh Krishnan IESG state changed to IESG Evaluation from Waiting for Writeup
2018-04-01
11 Suresh Krishnan Ballot has been issued
2018-04-01
11 Suresh Krishnan [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan
2018-04-01
11 Suresh Krishnan Created "Approve" ballot
2018-04-01
11 Suresh Krishnan Ballot writeup was changed
2018-03-31
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2018-03-31
11 Thomas Watteyne New version available: draft-ietf-6tisch-6top-protocol-11.txt
2018-03-31
11 (System) New version approved
2018-03-31
11 (System) Request for posting confirmation emailed to previous authors: Qin Wang , Xavier Vilajosana , Thomas Watteyne
2018-03-31
11 Thomas Watteyne Uploaded new revision
2018-03-26
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-03-23
10 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-03-23
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-6tisch-6top-protocol-09. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-6tisch-6top-protocol-09. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are seven actions which we must complete.

First, in the IEEE Std 802.15.4 IETF IE Subtype IDs registry located at:

https://www.iana.org/assignments/ieee-std-802.15.4-ietf-ie-subtype-ids/

a single, new value is to be added to the registry as follows:

Value: 6P
SubType ID: IANA_6TOP_SUBIE_ID
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, the authors make the following request in Section 6.2 in the current document:

"This section defines sub-registries within the "IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) parameters" registry, hereafter referred to as the "6TiSCH parameters" registry. Each sub-registry is described in a subsection."

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

A new registry is to be created called the 6P Version Numbers registry. The new registry will be located on a registry page (the "6TiSCH parameters" registry page) to be identified as an answer to the question above.

A Note included in this registry should say: "In the 6top Protocol (6P) [ RFC-to-be ] there is a field to identify the version of the protocol. This field is 4 bits in size."

The registration procedure for the new registry is "IETF Review or IESG Approval" as defined in [RFC8126].

There is an initial registration in the enw registry as follows:

Version Reference
------------+---------------------
0 [ RFC-to-be ]
1-15 Unassigned

Third, a new registry is to be created called the 6P Message Types registry. The new registry will be located on a registry page (the "6TiSCH parameters" registry page) to be identified as an answer to the question above.

A Note included in this registry should say: "In the 6top Protocol (6P) version 0 [ RFC-to-be ], there is a field to identify the type of message. This field is 2 bits in size."

The registration procedure for the new registry is "IETF Review or IESG Approval" as defined in [RFC8126].

There are initial registrations in the new registry as follows:

Type Name Reference
---------+------------------+----------------------
b00 REQUEST [ RFC-to-be ]
b01 RESPONSE [ RFC-to-be ]
b10 CONFIRMATION [ RFC-to-be ]
b11 Unassigned

Fourth, a new registry is to be created called the 6P Command Identifiers registry. The new registry will be located on a registry page (the "6TiSCH parameters" registry page) to be identified as an answer to the question above.

A Note included in this registry should say: "In the 6top Protocol (6P) version 0 [ RFC-to-be ], there is a Code field which is 8 bits in size. In a 6P Request, the value of this Code field is used to identify the command."

The registration procedure for the new registry is "IETF Review or IESG Approval" as defined in [RFC8126].

There are initial registrations in the new registry as follows:

Identifier Name Refernce
-----------+-----------------+------------------
0 Reserved
1 ADD [ RFC-to-be ]
2 DELETE [ RFC-to-be ]
3 RELOCATE [ RFC-to-be ]
4 COUNT [ RFC-to-be ]
5 LIST [ RFC-to-be ]
6 SIGNAL [ RFC-to-be ]
7 CLEAR [ RFC-to-be ]
8-254 Unassigned
255 Reserved

Fifth, a new registry is to be created called the 6P Return Codes registry. The new registry will be located on a registry page (the "6TiSCH parameters" registry page) to be identified as an answer to the question above.

A Note included in this registry should say: "In the 6top Protocol (6P) version 0 [ RFC-to-be ], there is a Code field which is 8 bits in size. In a 6P Response or 6P Confirmation, the value of this Code field is used to identify the return code."

The registration procedure for the new registry is "IETF Review or IESG Approval" as defined in [RFC8126].

There are initial registrations in the new registry as follows:

+------+-----------------+---------------------------+-----------+--------------+
| Code | Name | Description | Is Error? | Reference |
+------+-----------------+---------------------------+-----------+--------------+
| 0 | RC_SUCCESS | operation succeeded | No | [ RFC-to-be ]|
| 1 | RC_EOL | end of list | No | [ RFC-to-be ]|
| 2 | RC_ERR | generic error | Yes | [ RFC-to-be ]|
| 3 | RC_RESET | critical error, reset | Yes | [ RFC-to-be ]|
| 4 | RC_ERR_VERSION | unsupported 6P version | Yes | [ RFC-to-be ]|
| 5 | RC_ERR_SFID | unsupported SFID | Yes | [ RFC-to-be ]|
| 6 | RC_ERR_SEQNUM | schedule inconsistency | Yes | [ RFC-to-be ]|
| 7 | RC_ERR_CELLLIST | cellList error | Yes | [ RFC-to-be ]|
| 8 | RC_ERR_BUSY | busy | Yes | [ RFC-to-be ]|
| 9 | RC_ERR_LOCKED | cells are locked | Yes | [ RFC-to-be ]|
|10-255| Unassigned | | | |
+------+-----------------+---------------------------+-----------+--------------+

Sixth, a new registry is to be created called the 6P Scheduling Function Identifiers registry. The new registry will be located on a registry page (the "6TiSCH parameters" registry page) to be identified as an answer to the question above.

A Note included in this registry should say: "In the 6top Protocol (6P) version 0 [ RFC-to-be ], there is a field to identify the scheduling function to handle the message. This field is 8 bits in size."

The registration procedure for the new registry is as follows, as defined in [RFC8126]:

+-----------+------------------------------+
| Range | Registration Procedures |
+-----------+------------------------------+
| 0-127 | IETF Review or IESG Approval |
| 128-255 | Expert Review |
+-----------+------------------------------+

There are initial registrations in the new registry as follows:

+-----+---------------------------------+----------------------------+
|SFID | Name | Reference |
+------+---------------------------------+----------------------------+
| 0 | Minimal Scheduling Function | draft-chang-6tisch-msf |
| | (MSF) | |
+------+---------------------------------+----------------------------+
| 1 | Experimental Scheduling Function| draft-ietf-6tisch-6top-sfx |
| | (SFX) | |
+------+---------------------------------+----------------------------+
|2-255 | Unassigned |
+------+---------------------------------+----------------------------+

Seventh, a new registry is to be created called the 6P CellOptions bitmap registry. The new registry will be located on a registry page (the "6TiSCH parameters" registry page) to be identified as an answer to the question above.

A Note included in this registry should say: "In the 6top Protocol (6P) version 0 [ RFC-to-be ], there is an optional CellOptions field which is 8 bits in size."

The registration procedure for the new registry is "IETF Review or IESG Approval" as defined in [RFC8126].

There are initial registrations in the new registry as follows:

+-----+---------------+-----------------+
| bit | Name | Reference |
+-----+---------------+-----------------+
| 0 | TX (Transmit) | [ RFC-to-be ] |
| 1 | RX (Receive) | [ RFC-to-be ] |
| 2 | SHARED | [ RFC-to-be ] |
| 3-7 | Reserved | |
+-----+---------------+-----------------+

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-03-10
10 Brian Carpenter Request for Last Call review by GENART Completed: Ready. Reviewer: Brian Carpenter. Sent review to list.
2018-03-08
10 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2018-03-08
10 Jean Mahoney Request for Last Call review by GENART is assigned to Brian Carpenter
2018-03-05
10 Thomas Watteyne Added -10 to session: IETF-101: 6tisch  Wed-1330
2018-03-05
10 Thomas Watteyne New version available: draft-ietf-6tisch-6top-protocol-10.txt
2018-03-05
10 (System) New version approved
2018-03-05
10 (System) Request for posting confirmation emailed to previous authors: Qin Wang , Xavier Vilajosana , Thomas Watteyne
2018-03-05
10 Thomas Watteyne Uploaded new revision
2018-03-02
09 Thomas Watteyne Added to session: interim-2018-6tisch-03
2018-02-23
09 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-02-23
09 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-03-26):

From: The IESG
To: IETF-Announce
CC: pthubert@cisco.com, Pascal Thubert , 6tisch-chairs@ietf.org, draft-ietf-6tisch-6top-protocol@ietf.org, …
The following Last Call announcement was sent out (ends 2018-03-26):

From: The IESG
To: IETF-Announce
CC: pthubert@cisco.com, Pascal Thubert , 6tisch-chairs@ietf.org, draft-ietf-6tisch-6top-protocol@ietf.org, 6tisch@ietf.org, suresh@kaloom.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (6top Protocol (6P)) to Proposed Standard


The IESG has received a request from the IPv6 over the TSCH mode of IEEE
802.15.4e WG (6tisch) to consider the following document: - '6top Protocol
(6P)'
  as Proposed Standard

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 2018-03-26. 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 defines the 6top Protocol (6P), which enables
  distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes
  to add/delete TSCH cells to one another.  6P is part of the 6TiSCH
  Operation Sublayer (6top), the next higher layer to the IEEE Std
  802.15.4 TSCH medium access control layer.  The 6P layer is formed by
  the 6top Protocol defined in this document and 6top Scheduling
  Function(s).  A 6top Scheduling Function (SF) decides when to add/
  delete cells, and triggers 6P Transactions.  This document lists the
  requirements for an SF, but leaves the definition of SFs out of
  scope.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-6tisch-6top-sf0: 6TiSCH 6top Scheduling Function Zero (SF0) (None - IETF stream)



2018-02-23
09 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-02-23
09 Suresh Krishnan Last call was requested
2018-02-23
09 Suresh Krishnan Ballot approval text was generated
2018-02-23
09 Suresh Krishnan Ballot writeup was generated
2018-02-23
09 Suresh Krishnan IESG state changed to Last Call Requested from AD Evaluation::External Party
2018-02-23
09 Suresh Krishnan Last call announcement was changed
2018-02-22
09 Alexander Pelov Request for Early review by IOTDIR Completed: Ready with Issues. Reviewer: Alexander Pelov. Sent review to list.
2018-02-22
09 Suresh Krishnan Telechat date has been changed to 2018-04-05 from 2018-03-08
2018-02-19
09 Brian Carpenter Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. Sent review to list.
2018-02-15
09 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2018-02-15
09 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2018-02-08
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Ben Laurie
2018-02-08
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Ben Laurie
2018-02-05
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Jon Mitchell
2018-02-05
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Jon Mitchell
2018-02-05
09 Suresh Krishnan Placed on agenda for telechat - 2018-03-08
2018-02-05
09 Samita Chakrabarti Request for Early review by IOTDIR is assigned to Alexander Pelov
2018-02-05
09 Samita Chakrabarti Request for Early review by IOTDIR is assigned to Alexander Pelov
2018-01-29
09 Suresh Krishnan Waiting for IoT Directorate review.
2018-01-29
09 Suresh Krishnan IESG state changed to AD Evaluation::External Party from AD Evaluation
2018-01-14
09 Samita Chakrabarti Request for Early review by IOTDIR is assigned to Robert Cragie
2018-01-14
09 Samita Chakrabarti Request for Early review by IOTDIR is assigned to Robert Cragie
2017-11-12
09 Suresh Krishnan IESG state changed to AD Evaluation from Publication Requested
2017-11-11
09 Bernie Volz Request for Early review by INTDIR is assigned to Donald Eastlake
2017-11-11
09 Bernie Volz Request for Early review by INTDIR is assigned to Donald Eastlake
2017-11-11
09 Bernie Volz Request for Early review by INTDIR is assigned to Ralph Droms
2017-11-11
09 Bernie Volz Request for Early review by INTDIR is assigned to Ralph Droms
2017-11-11
09 Suresh Krishnan Requested Early review by IOTDIR
2017-11-11
09 Suresh Krishnan Requested Early review by INTDIR
2017-11-11
09 Thomas Watteyne Added to session: IETF-100: 6tisch  Mon-1550
2017-10-31
09 Pascal Thubert

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  …

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

 Proposed Standard; this is properly indicated in the draft.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document defines the 6top Protocol (6P), which enables
  distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes
  to add/delete TSCH cells to one another.  6P is part of the 6TiSCH
  Operation Sublayer (6top), the next higher layer to the IEEE Std
  802.15.4 TSCH medium access control layer.  The 6P layer is formed by
  the 6top Protocol defined in this document and 6top Scheduling
  Function(s).  A 6top Scheduling Function (SF) decides when to add/
  delete cells, and triggers 6P Transactions.  This document lists the
  requirements for an SF, but leaves the definition of SFs out of
  scope.

Working Group Summary

No controversy.
The design was complex due to the need to save exchanges and yet provide transactional outcomes.
The next generation of the work may be done at IEEE, e.g. within IEEE Std. 802.12

Document Quality

This specification was implemented in openWSN and contiki.
It was interop tested at the 6TiSCH F-interop in Prague:
http://www.etsi.org/news-events/events/1197-6tisch-interop-prague-2017
Return from experimentation is implemented in the draft


Personnel

  Document Shepherd: Pascal Thubert
  Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document was ready for publication.
  The shepherd most asked for clarifying  information, in order to make the reading smoother for a first comer.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concern. The document is implementable.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No, this is a self-contained document

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concern. Just awareness that the work may be migrated to IEEE after this RFC.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes, there is no known IPR on this document

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There is no known IPR on this document

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  Full consensus

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such problem

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  There is a downref to RFC8137. Maybe RFC8137 should have been std track.
  The downref seems harmless though.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  The document has a IANA requirements.
  IANA policies are indicated are described in [RFC8126]

(13) Have all references within this document been identified as
either normative or informative?

  Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  Downref to RFC8137

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


  The document has a IANA requirements conforming the above.
  IANA policies are indicated are described in [RFC8126]


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  The 6P Scheduling Function Identifiers registry requires expert review for the second half of the range.
  Expertise required would be the general art of 6TiSCH and existing SFs to avoid duplication.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  N/A

2017-10-31
09 Pascal Thubert Responsible AD changed to Suresh Krishnan
2017-10-31
09 Pascal Thubert IETF WG state changed to Submitted to IESG for Publication from WG Document
2017-10-31
09 Pascal Thubert IESG state changed to Publication Requested
2017-10-31
09 Pascal Thubert IESG process started in state Publication Requested
2017-10-31
09 Pascal Thubert Changed consensus to Yes from Unknown
2017-10-31
09 Pascal Thubert This document defines a protocol between 6TiSCH peers
2017-10-31
09 Pascal Thubert Intended Status changed to Proposed Standard from None
2017-10-31
09 Pascal Thubert Changed document writeup
2017-10-25
09 Xavier Vilajosana New version available: draft-ietf-6tisch-6top-protocol-09.txt
2017-10-25
09 (System) New version approved
2017-10-25
09 (System) Request for posting confirmation emailed to previous authors: Qin Wang , Xavier Vilajosana , Thomas Watteyne
2017-10-25
09 Xavier Vilajosana Uploaded new revision
2017-09-26
08 Pascal Thubert Notification list changed to Pascal Thubert <pthubert@cisco.com>
2017-09-26
08 Pascal Thubert Document shepherd changed to Pascal Thubert
2017-09-22
08 Xavier Vilajosana New version available: draft-ietf-6tisch-6top-protocol-08.txt
2017-09-22
08 (System) New version approved
2017-09-22
08 (System) Request for posting confirmation emailed to previous authors: Thomas Watteyne , Qin Wang , Xavier Vilajosana , 6tisch-chairs@ietf.org
2017-09-22
08 Xavier Vilajosana Uploaded new revision
2017-07-18
07 Thomas Watteyne Added to session: IETF-99: 6tisch  Mon-1330
2017-06-27
07 Thomas Watteyne New version available: draft-ietf-6tisch-6top-protocol-07.txt
2017-06-27
07 (System) New version approved
2017-06-27
07 (System) Request for posting confirmation emailed to previous authors: Thomas Watteyne , Qin Wang , Xavier Vilajosana
2017-06-27
07 Thomas Watteyne Uploaded new revision
2017-06-22
06 Xavier Vilajosana New version available: draft-ietf-6tisch-6top-protocol-06.txt
2017-06-22
06 (System) New version approved
2017-06-22
06 (System) Request for posting confirmation emailed to previous authors: Thomas Watteyne , Qin Wang , Xavier Vilajosana
2017-06-22
06 Xavier Vilajosana Uploaded new revision
2017-05-24
05 Xavier Vilajosana New version available: draft-ietf-6tisch-6top-protocol-05.txt
2017-05-24
05 (System) New version approved
2017-05-24
05 (System) Request for posting confirmation emailed to previous authors: Thomas Watteyne , Qin Wang , Xavier Vilajosana
2017-05-24
05 Xavier Vilajosana Uploaded new revision
2017-03-29
04 Xavier Vilajosana New version available: draft-ietf-6tisch-6top-protocol-04.txt
2017-03-29
04 (System) New version approved
2017-03-29
04 (System) Request for posting confirmation emailed to previous authors: Qin Wang , Xavier Vilajosana , 6tisch-chairs@ietf.org
2017-03-29
04 Xavier Vilajosana Uploaded new revision
2017-03-27
03 Pascal Thubert Added to session: IETF-98: 6tisch  Tue-0900
2016-11-15
03 Thomas Watteyne Added to session: IETF-97: 6tisch  Thu-0930
2016-10-31
03 Xavier Vilajosana New version available: draft-ietf-6tisch-6top-protocol-03.txt
2016-10-31
03 (System) New version approved
2016-10-31
02 (System) Request for posting confirmation emailed to previous authors: "Qin Wang" , "Xavier Vilajosana"
2016-10-31
02 Xavier Vilajosana Uploaded new revision
2016-07-25
02 Xavier Vilajosana New version available: draft-ietf-6tisch-6top-protocol-02.txt
2016-06-27
01 Xavier Vilajosana New version available: draft-ietf-6tisch-6top-protocol-01.txt
2016-04-27
00 Xavier Vilajosana New version available: draft-ietf-6tisch-6top-protocol-00.txt