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 |