6TiSCH Minimal Scheduling Function (MSF)
draft-ietf-6tisch-msf-18
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-04
|
18 | Gunter Van de Velde | Request closed, assignment withdrawn: Nagendra Nainar Last Call OPSDIR review |
2024-01-04
|
18 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2021-04-23
|
18 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-04-20
|
18 | (System) | RFC Editor state changed to AUTH48 |
2021-02-16
|
18 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2021-02-15
|
18 | (System) | RFC Editor state changed to REF from EDIT |
2021-02-09
|
18 | (System) | RFC Editor state changed to EDIT from AUTH |
2021-02-09
|
18 | (System) | RFC Editor state changed to AUTH from EDIT |
2021-01-26
|
18 | (System) | RFC Editor state changed to EDIT from MISSREF |
2020-09-17
|
18 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-09-16
|
18 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-09-16
|
18 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-09-15
|
18 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-09-14
|
18 | (System) | RFC Editor state changed to MISSREF |
2020-09-14
|
18 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-09-14
|
18 | (System) | Announcement was received by RFC Editor |
2020-09-14
|
18 | (System) | IANA Action state changed to In Progress |
2020-09-14
|
18 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-09-14
|
18 | Amy Vezza | IESG has approved the document |
2020-09-14
|
18 | Amy Vezza | Closed "Approve" ballot |
2020-09-14
|
18 | Amy Vezza | Ballot writeup was changed |
2020-09-14
|
18 | Amy Vezza | Ballot approval text was generated |
2020-09-12
|
18 | Erik Kline | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2020-09-12
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-09-12
|
18 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-18.txt |
2020-09-12
|
18 | (System) | New version approved |
2020-09-12
|
18 | (System) | Request for posting confirmation emailed to previous authors: Tengfei Chang , Simon Duquennoy , Xavier Vilajosana , Malisa Vucinic , Diego Dujovne |
2020-09-12
|
18 | Tengfei Chang | Uploaded new revision |
2020-09-11
|
17 | Erik Kline | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2020-09-11
|
17 | Erik Kline | [Ballot comment] [[ nits ]] [ section 2 ] * "to do at each time slots" -> "to do at each time slot" * "there … [Ballot comment] [[ nits ]] [ section 2 ] * "to do at each time slots" -> "to do at each time slot" * "there is a frame to sent" -> "there is a frame to be sent" [ section 4.3 ] * "the pledge continue listening" -> "the pledge continues listening" [ section 4.4 ] * "After selected a JP" -> "After selecting a JP" or "After having selected a JP" [ section 4.8 ] * "AutRxCell" -> "AutoRxCell"? * "for new pledge" -> "for new pledges"? [ section 5.1 ] * "used to both type of" -> "used for both type of"? [ section 8 ] * "consequence of randomly cell selection" -> "consequence of random cell selection"? [ section 9 ] * "define din" -> "defined in" [ section 16 ] * "considrations" -> "considerations" * "to hand that packet" -> "to handle that packet", maybe |
2020-09-11
|
17 | Erik Kline | [Ballot Position Update] New position, Yes, has been recorded for Erik Kline |
2020-08-03
|
17 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-17.txt |
2020-08-03
|
17 | (System) | New version approved |
2020-08-03
|
17 | (System) | Request for posting confirmation emailed to previous authors: Simon Duquennoy , Xavier Vilajosana , Malisa Vucinic , Diego Dujovne , Tengfei Chang |
2020-08-03
|
17 | Tengfei Chang | Uploaded new revision |
2020-07-10
|
16 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Donald Eastlake. Submission of review completed at an earlier date. |
2020-07-05
|
16 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Donald Eastlake. |
2020-05-08
|
16 | Roman Danyliw | [Ballot comment] Thanks for addressing my DISCUSS and COMMENTs. |
2020-05-08
|
16 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2020-04-02
|
16 | Benjamin Kaduk | [Ballot comment] Thanks for clarifying the non-issue nature of my original Discuss points! Original COMMENT section preserved below (possibly stale). I support Roman's Discuss -- … [Ballot comment] Thanks for clarifying the non-issue nature of my original Discuss points! Original COMMENT section preserved below (possibly stale). I support Roman's Discuss -- we need more information for this to be a useful reference; even what seem to be the official DASFAA 1997 proceedings (https://dblp.org/db/conf/dasfaa/dasfaa97) do not have an associated document). Basing various scheduling aspects on (a hash of) the EUI64 ties functionality to a persistent identifier for a device. How significant a disruption would be incurred if a device periodically changes its presented EUI64 for anonymization purposes? There seems to be a general pattern of "if you don't have a 6P-negotiated Tx cell, install and AutoTxCell to send your one message and then remove it after sending"; I wonder if it would be easier on the reader to consolidate this as a general principle and not repeat the details every time it occurs. Requirements Language "NOT RECOMMENDED" is not in the RFC2119 boilerplate (but is a BCP 14 keyword). Section 1 the 6 steps described in Section 4. The end state of the join process is that the node is synchronized to the network, has mutually authenticated to the network, has identified a routing parent, and nit(?): I guess maybe "mutually authenticated with" is more correct for the bidirectional operation. It does so for 3 reasons: to match the link-layer resources to the traffic, to handle changing parent, to handle a schedule collision. nit: end the list with "or" (or "and"?). MSF works closely with RPL, specifically the routing parent defined in [RFC6550]. This specification only describes how MSF works with one routing parent, which is phrased as "selected parent". The nit: I suggest '''one routing parent; this parent is referred to as the "selected parent"'''. activity of MSF towards to single routing parent is called as a "MSF nit: "towards the" * We added sections on the interface to the minimal 6TiSCH configuration (Section 2), the use of the SIGNAL command (Section 6), the MSF constants (Section 14), the MSF statistics (Section 15). nit: end the list with "and". Section 2 In a TSCH network, time is sliced up into time slots. The time slots are grouped as one of more slotframes which repeat over time. The nit(?): should this be "one or more"? channel) is indicated as a cell of TSCH schedule. MSF is one of the policies defining how to manage the TSCH schedule. nit: if there is only one such policy active at a given time for a given network, I suggest "MSF is a policy for managing the TCSH schedule". (If multiple policies are active simultaneously, no change is needed.) MSF uses the minimal cell for broadcast frames such as Enhanced Beacons (EBs) [IEEE802154] and broadcast DODAG Information Objects (DIOs) [RFC6550]. Cells scheduled by MSF are meant to be used only for unicast frames. If this paragraph was moved before the previous paragraph, then EB and DIO would be defined before their first usage. bandwidth of minimal cell. One of the algorithm met the rule is the Trickle timer defined in [RFC6206] which is applied on DIO messages [RFC6550]. However, any such algorithm of limiting the broadcast nit(?): "One of the algorithms that fulfills this requirement"? MSF RECOMMENDS the use of 3 slotframes. MSF schedules autonomous cells at Slotframe 1 (Section 3) and 6P negotiated cells at Slotframe 2 (Section 5) , while Slotframe 0 is used for the bootstrap traffic as defined in the Minimal 6TiSCH Configuration. It is RECOMMENDED to use the same slotframe length for Slotframe 0, 1 and 2. Thus it is Perhaps this is just a question of writing style, but if an implementation is free to use an alternative SF or a variant of MSF, could we not say that "MSF uses 3 slotframts", "MSF uses the same slotframe length for", etc.? Section 3 Is there any risk of unwanted correlation between slot and channel offsets when using the same hash function and input for both calculations? hash function. Other optional parameters defined in SAX determine the performance of SAX hash function. Those parameters could be broadcasted in EB frame or pre-configured. For interoperability purposes, an example how the hash function is implemented is detailed in Appendix B. Given the lack of usable reference for [SAX-DASFAA], I assume that the content in Appendix B is going to be used as a specification, not just an example. * The AutoRxCell MUST always remain scheduled after synchronized. nit: s/synchronized/synchronization/ AutoRxCell. In case of conflicting with a negotiated cell, autonomous cells take precedence over negotiated cell, which is stated in [IEEE802154]. However, when the Slotframe 0, 1 and 2 use the same length value, it is possible for negotiated cell to avoid the collision with AutoRxCell. Presumably this factors in to the recommendation to have the three listed slotframes use the same length, but mentioning it explicitly (whether here or where the recommendation is made) might be nice. Section 4 network. Alternative behaviors may involved, for example, when alternative security solution is used for the network. Section 4.1 nit: singular/plural mismatch "behaviors"/"solution is used" Section 4.1 A node implementing MSF SHOULD implement the Minimal Security Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a Didn't this get renamed to CoJP? Section 4.2 I a little bit wonder if there is a better description than "available frequencies" but don't have one to offer. Section 4.3 While the exact behavior is implementation-specific, it is RECOMMENDED that after having received the first EB, a node keeps listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors, which is defined in [RFC8180]. nit(?): this phrasing implies that only NUM_NEIGHBOURS_TO_WAIT is defined in RFC 8180, but MAX_EB_DELAY is also defined there. not-nit: this phrasing is ambiguous as to whether one of MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT is sufficient to move to the next step or whether both are required. Section 4.4 After selected a JP, a node generates a Join Request and installs an AutoTxCell to the JP. The Join Request is then sent by the pledge to its JP over the AutoTxCell. The AutoTxCell is removed by the pledge editorial: I'd suggest s/its JP/its selected JP/ Response is sent out. The pledge receives the Join Response from its AutoRxCell, thereby learns the keying material used in the network, as well as other configurations, and becomes a "joined node". nit: maybe "other configuration values" or "other configuration settings"? Section 4.6 Once it has selected a routing parent, the joined node MUST generate a 6P ADD Request and install an AutoTxCell to that parent. The 6P ADD Request is sent out through the AutoTxCell with the following fields: * CellOptions: set to TX=1,RX=0,SHARED=0 * NumCells: set to 1 * CellList: at least 5 cells, chosen according to Section 8 Is this listing describing the contents of the ADD request or the AuthTxCell used to send it? (I presume the former, in which case I suggest to use "containing" or similar in preference to "with".) Section 5.1 The goal of MSF is to manage the communication schedule in the 6TiSCH schedule in a distributed manner. For a node, this translates into monitoring the current usage of the cells it has to the selected parent: Is this goal strictly limited to traffic "to the selected parent" vs. all traffic? * If the node determines that the number of link-layer frames it is attempting to exchange with the selected parent per unit of time is larger than the capacity offered by the TSCH negotiated cells it has scheduled with it, the node issues a 6P ADD command to that parent to add cells to the TSCH schedule. * If the traffic is lower than the capacity, the node issues a 6P DELETE command to that parent to delete cells from the TSCH schedule. As written, this would potentially lead to oscillation when demand is basically at capacity, due to the quantization of capacity. Perhaps some provisioning for hysteresis is appropriate? The cell option of cells listed in CellList in 6P Request frame SHOULD be either Tx=1 only or Rx=1 only. Both NumCellsElapsed and NumCellsUsed counters can be used to both type of negotiated cells. Would this be more clear as "(Tx=1,Rx=0) or (Tx=0,Rx=1)"? * NumCellsElapsed is incremented by exactly 1 when the current cell is AutoRxCell. This holds for all peers/parents we're keeping counters for, so the AutoRxCell can get "double counted"? In case that a node booted or disappeared from the network, the cell reserved at the selected parent may be kept in the schedule forever. A clean-up mechanism MUST be provided to resolve this issue. The clean-up mechanism is implementation-specific. It could either be a periodic polling to the neighbors the nodes have negotiated cells with, or monitoring the activities on those cells. The goal is to confirm those negotiated cells are not used anymore by the associated neighbors and remove them from the schedule. I'm not sure that "monitoring the activities on those cells" is safe with the current level of specification; if a node negotiates a 6P transmit cell to a parent and uses it only sparingly, with the parent eventually reclaiming it due to inactivity, I don't see a mechanism by which the node will reliably discover the negotiated cell to be nonfunctional and fall back to (e.g.) the corresponding AutoTxCell. It may be most prudent to just not mention that as an example (a "periodic polling" procedure does not seem to have the same potential for information skew) Section 5.3 schedule is executed and the node sends frames to that parent. When NumTx reaches MAX_NUMTX, both NumTx and NumTxAck MUST be divided by 2. For example, when MAX_NUMTX is set to 256, from NumTx=255 and NumTxAck=127, the counters become NumTx=128 and NumTxAck=64 if one frame is sent to the parent with an Acknowledgment received. This operation does not change the value of the PDR, but allows the counters to keep incrementing. The value of MAX_NUMTX is implementation-specific. Does MAX_NUMTX need to be a power of two (to avoid errors when the division occurs)? 4. For any other cell, it compares its PDR against that of the cell with the highest PDR. If the difference is larger than RELOCATE_PDRTHRES, it triggers the relocation of that cell using a 6P RELOCATE command. The recommended RELOCATE_PDRTHRES is given as "50 %". Is this "difference" performed as a subtraction (so that if the highest PDR is less than 50%, no cells can ever be relocated) or a ratio (a PDR that's half than the maximum PDR or smaller will trigger relocation)? Section 7 Maybe reference Section 17.1 where the allocation will occur? Section 8 * The slotOffset of a cell in the CellList SHOULD be randomly and uniformly chosen among all the slotOffset values that satisfy the restrictions above. * The channelOffset of a cell in the CellList SHOULD be randomly and uniformly chosen in [0..numFrequencies], where numFrequencies represents the number of frequencies a node can communicate on. Do these random selections need to be independent from each other? (I note that the selection for the autonomous cells are not.) Section 9 Is there a reference for these three parameters (MAXBE, MAXRETRIES, SLOTFRAME_LENGTH)? SLOTFRAME_LENGTH seems new in this document and is listed in the table in Section 14, but the other two are not listed there. Section 14 Why is MAX_NUMTX not listed in the table? Can we really give a recommended NUM_CH_OFFSET value, since this is in effect dependent on the number of channels available? KA_PERIOD is defined but not used elsewhere in the document. What are the considerations in using a power of 10 vs. a power of 2 as MAX_NUM_CELLS? Section 16 MSF defines a series of "rules" for the node to follow. It triggers several actions, that are carried out by the protocols defined in the following specifications: the Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration [RFC8180], the 6TiSCH Operation I'd suggest a brief note that the security considerations of those protocols continue to apply (even though it ought to be obvious); reading them could help a reader understand the behavior of this document as well. Sublayer Protocol (6P) [RFC8480], and the Minimal Security Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security]. In particular, MSF [CoJP again] prevent it from receiving the join response. This situation should be detected through the absence of a particular node from the network and handled by the network administrator through out-of-band means, e.g. by moving the node outside the radio range of the attacker. "the radio range of the attacker" is not exactly a fixed constant ... attackers are not in general bound by legal limits and can increase Tx power subject only to their equipment and budget. MSF adapts to traffics containing packets from IP layer. It is possible that the IP packet has a non-zero DSCP (Diffserv Code Point [RFC2597]) value in its IPv6 header. The decision whether to hand RFC 2597 is talking more about specifically assured forwarding PHB groups than "DSCP codepoint"s per se. Section 18.1 RFC 6206 seems to only be used as an example (Trickle), and could probably be informative. RFC 8505 might also not need to be normative. Appendix B In MSF, the T is replaced by the length slotframe 1. String s is nit: "length of" 2. sum the value of L_shift(h,l_bit), R_shift(h,r_bit) and ci Is this addition performed in "infinite precision" integer arithmetic or limited to the output width of h, e.g., by modular division? (It's not clear to me whether this is the role T plays or not.) 8. assign the result of Step 5 to h The value from step 5 *is* h, so taken literally this says "assign h to h" and is not needed. |
2020-04-02
|
16 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2020-04-02
|
16 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-16.txt |
2020-04-02
|
16 | (System) | New version approved |
2020-04-02
|
16 | (System) | Request for posting confirmation emailed to previous authors: Diego Dujovne , Xavier Vilajosana , Tengfei Chang , Malisa Vucinic , Simon Duquennoy |
2020-04-02
|
16 | Tengfei Chang | Uploaded new revision |
2020-03-31
|
15 | Benjamin Kaduk | [Ballot discuss] I'm concerned that the scheduling function for autonomous cells can cause an infinite loop in the case of hash collision -- Section 3 … [Ballot discuss] I'm concerned that the scheduling function for autonomous cells can cause an infinite loop in the case of hash collision -- Section 3 specifies that AutoTxCell always takes precedence over AutoRxCell, but if those two cells collide, the corresponding cells on the peer in question will also collide. If both peers try to send at the same time and the hashes collide, they will both attempt to transmit indefinitely and never be received. [I have been persuaded that the rate-limiting situation does not present an inconsistency between documents] |
2020-03-31
|
15 | Benjamin Kaduk | Ballot discuss text updated for Benjamin Kaduk |
2020-03-31
|
15 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-15.txt |
2020-03-31
|
15 | (System) | New version approved |
2020-03-31
|
15 | (System) | Request for posting confirmation emailed to previous authors: Xavier Vilajosana , Malisa Vucinic , Simon Duquennoy , Tengfei Chang , Diego Dujovne |
2020-03-31
|
15 | Tengfei Chang | Uploaded new revision |
2020-03-27
|
14 | Wesley Eddy | Request closed, assignment withdrawn: Jana Iyengar Telechat TSVART review |
2020-03-27
|
14 | Wesley Eddy | Closed request for Telechat review by TSVART with state 'Withdrawn' |
2020-03-25
|
14 | Suresh Krishnan | Shepherding AD changed to Erik Kline |
2020-03-24
|
14 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-14.txt |
2020-03-24
|
14 | (System) | New version approved |
2020-03-24
|
14 | (System) | Request for posting confirmation emailed to previous authors: Diego Dujovne , Malisa Vucinic , Simon Duquennoy , Xavier Vilajosana , Tengfei Chang |
2020-03-24
|
14 | Tengfei Chang | Uploaded new revision |
2020-03-24
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-03-24
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-03-24
|
13 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-13.txt |
2020-03-24
|
13 | (System) | New version approved |
2020-03-24
|
13 | (System) | Request for posting confirmation emailed to previous authors: Diego Dujovne , Tengfei Chang , Malisa Vucinic , Xavier Vilajosana , Simon Duquennoy |
2020-03-24
|
13 | Tengfei Chang | Uploaded new revision |
2020-03-17
|
12 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENTs and NITs. An answer will be appreciated. I … [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENTs and NITs. An answer will be appreciated. I hope that this helps to improve the document, Regards, -éric == COMMENTS == As Alissa's comment, please use RFC 8174 boiler plate. -- Section 3 -- Suggest to remove "The AutoRxCell MUST always remain scheduled after synchronized. * 6P CLEAR MUST NOT erase any autonomous cells." from the bulleted list and create a new paragraph for those 2 lines. -- Section 4 -- The whole section seems to assume that the events will work as expected. But, what if this is not the case? E.g., the JP does not send any reply ? -- Section 5.3 -- "we necessarily have NumTxAck <= NumTx" is only true is all nodes behave... "MUST be divided by 2", the example is about 127 divided by 2 giving the unexpected value (to me at least) of 64... The text should clarify how rounding is handled as it is not a plain right shift by 1. Step 2, is it also applicable to any value of MAX_NUMTX ? Including very small or very large ones ? == NITS == -- section 5.2 -- To be checked by a native speaker but s/can have a node switch parent/can have a node switching parent/ would make the text easier to parse. -- Section 14 -- Please order the rows of Figure 2. |
2020-03-17
|
12 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-03-12
|
12 | Cindy Morgan | Telechat date has been changed to 2020-03-19 from 2020-03-12 |
2020-03-12
|
12 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-03-12
|
12 | Alvaro Retana | [Ballot comment] (1) I support Roman's DISCUSS. (2) The datatracker should point at draft-chang-6tisch-msf being replaced by this document. (3) §2: "MSF RECOMMENDS the use … [Ballot comment] (1) I support Roman's DISCUSS. (2) The datatracker should point at draft-chang-6tisch-msf being replaced by this document. (3) §2: "MSF RECOMMENDS the use of 3 slotframes." Why isn't this REQUIRED? How does an implementation signal to a neighboring node that a different number of slotframes are being used (or a different length, which is also RECOMMENDED later)? It seems to me that RECOMMENDING may not be enough for an interoperable implementation...but I may also be missing something in 802.15.4 or rfc8180 (or somewhere else). [BTW, the rfc2119 keyword is RECOMMENDED (not RECOMMENDS).] I think the use of RECOMMENDED (vs REQUIRED) may be related to this text a couple of paragraphs before: A node implementing MSF SHOULD implement the Minimal 6TiSCH Configuration [RFC8180], which defines the "minimal cell", a single shared cell providing minimal connectivity between the nodes in the network. The MSF implementation provided in this specification is based on the implementation of the Minimal 6TiSCH Configuration. However, an implementor MAY implement MSF based on other specifications as long as the specification defines a way to advertise the EB/DIO among the network. I understand that a configuration other than rfc8180 is possible, but if this document is based on rfc8180, then it would be clearer if the language was stronger (s/SHOULD/MUST) with the understanding that the specification refers to that case. (4) §4.3: While the exact behavior is implementation-specific, it is RECOMMENDED that after having received the first EB, a node keeps listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors, which is defined in [RFC8180]. rfc8180/§6.2 says that "after having received the first EB, a node MAY listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors." The use of RECOMMENDED here is not consistent with the optional nature of the MAY. (5) Nits... s/represents node's preferred parent/represents the node's preferred parent s/no restrictions to go multiple MSF sessions/no restrictions to use (?) multiple MSF sessions s/One of the algorithm met the rule/One of the algorithms that meet the rule s/Alternative behaviors may involved/Alternative behaviors may be involved s/when alternative security/when an alternative security s/node keeps listen/node keeps listening s/pairs of following counters/pairs of the following counters |
2020-03-12
|
12 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-03-12
|
12 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-03-11
|
12 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2020-03-11
|
12 | Barry Leiba | [Ballot comment] I was going to ask that you expand “DODAG” in first use, because it’s not marked as sufficiently common in the RFC Editor’s … [Ballot comment] I was going to ask that you expand “DODAG” in first use, because it’s not marked as sufficiently common in the RFC Editor’s abbreviation list. But, really, I think the better answer is to ask the responsible AD to ask the RFC Editor to put that asterisk on both DAG and DODAG at this point. |
2020-03-11
|
12 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-03-11
|
12 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-03-11
|
12 | Alissa Cooper | [Ballot comment] Please use the RFC 8174 boilerplate rather than the RFC 2119 boilerplate. |
2020-03-11
|
12 | Alissa Cooper | Ballot comment text updated for Alissa Cooper |
2020-03-11
|
12 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-03-11
|
12 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-03-11
|
12 | Benjamin Kaduk | [Ballot discuss] I'm concerned that the scheduling function for autonomous cells can cause an infinite loop in the case of hash collision -- Section 3 … [Ballot discuss] I'm concerned that the scheduling function for autonomous cells can cause an infinite loop in the case of hash collision -- Section 3 specifies that AutoTxCell always takes precedence over AutoRxCell, but if those two cells collide, the corresponding cells on the peer in question will also collide. If both peers try to send at the same time and the hashes collide, they will both attempt to transmit indefinitely and never be received. There seems to be some "passing the buck" going on with respect to rate-limiting unauthenticated (join) traffic: draft-ietf-6tisch-minimal-security (Section 6.1.1) says that the SF "SHOULD NOT allocate additional cells as a result of traffic with code point AF43"; this document is implementing a SF, and yet we try to avoid the issue, saying that "[t]he at IPv6 layer SHOULD ensure that this join traffic is rate-limited before it is passed to 6top sublayer where MSF can observe it". I think we need a clear and consistent story about where this rate-limiting is supposed to happen. |
2020-03-11
|
12 | Benjamin Kaduk | [Ballot comment] I support Roman's Discuss -- we need more information for this to be a useful reference; even what seem to be the official … [Ballot comment] I support Roman's Discuss -- we need more information for this to be a useful reference; even what seem to be the official DASFAA 1997 proceedings (https://dblp.org/db/conf/dasfaa/dasfaa97) do not have an associated document). Basing various scheduling aspects on (a hash of) the EUI64 ties functionality to a persistent identifier for a device. How significant a disruption would be incurred if a device periodically changes its presented EUI64 for anonymization purposes? There seems to be a general pattern of "if you don't have a 6P-negotiated Tx cell, install and AutoTxCell to send your one message and then remove it after sending"; I wonder if it would be easier on the reader to consolidate this as a general principle and not repeat the details every time it occurs. Requirements Language "NOT RECOMMENDED" is not in the RFC2119 boilerplate (but is a BCP 14 keyword). Section 1 the 6 steps described in Section 4. The end state of the join process is that the node is synchronized to the network, has mutually authenticated to the network, has identified a routing parent, and nit(?): I guess maybe "mutually authenticated with" is more correct for the bidirectional operation. It does so for 3 reasons: to match the link-layer resources to the traffic, to handle changing parent, to handle a schedule collision. nit: end the list with "or" (or "and"?). MSF works closely with RPL, specifically the routing parent defined in [RFC6550]. This specification only describes how MSF works with one routing parent, which is phrased as "selected parent". The nit: I suggest '''one routing parent; this parent is referred to as the "selected parent"'''. activity of MSF towards to single routing parent is called as a "MSF nit: "towards the" * We added sections on the interface to the minimal 6TiSCH configuration (Section 2), the use of the SIGNAL command (Section 6), the MSF constants (Section 14), the MSF statistics (Section 15). nit: end the list with "and". Section 2 In a TSCH network, time is sliced up into time slots. The time slots are grouped as one of more slotframes which repeat over time. The nit(?): should this be "one or more"? channel) is indicated as a cell of TSCH schedule. MSF is one of the policies defining how to manage the TSCH schedule. nit: if there is only one such policy active at a given time for a given network, I suggest "MSF is a policy for managing the TCSH schedule". (If multiple policies are active simultaneously, no change is needed.) MSF uses the minimal cell for broadcast frames such as Enhanced Beacons (EBs) [IEEE802154] and broadcast DODAG Information Objects (DIOs) [RFC6550]. Cells scheduled by MSF are meant to be used only for unicast frames. If this paragraph was moved before the previous paragraph, then EB and DIO would be defined before their first usage. bandwidth of minimal cell. One of the algorithm met the rule is the Trickle timer defined in [RFC6206] which is applied on DIO messages [RFC6550]. However, any such algorithm of limiting the broadcast nit(?): "One of the algorithms that fulfills this requirement"? MSF RECOMMENDS the use of 3 slotframes. MSF schedules autonomous cells at Slotframe 1 (Section 3) and 6P negotiated cells at Slotframe 2 (Section 5) , while Slotframe 0 is used for the bootstrap traffic as defined in the Minimal 6TiSCH Configuration. It is RECOMMENDED to use the same slotframe length for Slotframe 0, 1 and 2. Thus it is Perhaps this is just a question of writing style, but if an implementation is free to use an alternative SF or a variant of MSF, could we not say that "MSF uses 3 slotframts", "MSF uses the same slotframe length for", etc.? Section 3 Is there any risk of unwanted correlation between slot and channel offsets when using the same hash function and input for both calculations? hash function. Other optional parameters defined in SAX determine the performance of SAX hash function. Those parameters could be broadcasted in EB frame or pre-configured. For interoperability purposes, an example how the hash function is implemented is detailed in Appendix B. Given the lack of usable reference for [SAX-DASFAA], I assume that the content in Appendix B is going to be used as a specification, not just an example. * The AutoRxCell MUST always remain scheduled after synchronized. nit: s/synchronized/synchronization/ AutoRxCell. In case of conflicting with a negotiated cell, autonomous cells take precedence over negotiated cell, which is stated in [IEEE802154]. However, when the Slotframe 0, 1 and 2 use the same length value, it is possible for negotiated cell to avoid the collision with AutoRxCell. Presumably this factors in to the recommendation to have the three listed slotframes use the same length, but mentioning it explicitly (whether here or where the recommendation is made) might be nice. Section 4 network. Alternative behaviors may involved, for example, when alternative security solution is used for the network. Section 4.1 nit: singular/plural mismatch "behaviors"/"solution is used" Section 4.1 A node implementing MSF SHOULD implement the Minimal Security Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a Didn't this get renamed to CoJP? Section 4.2 I a little bit wonder if there is a better description than "available frequencies" but don't have one to offer. Section 4.3 While the exact behavior is implementation-specific, it is RECOMMENDED that after having received the first EB, a node keeps listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors, which is defined in [RFC8180]. nit(?): this phrasing implies that only NUM_NEIGHBOURS_TO_WAIT is defined in RFC 8180, but MAX_EB_DELAY is also defined there. not-nit: this phrasing is ambiguous as to whether one of MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT is sufficient to move to the next step or whether both are required. Section 4.4 After selected a JP, a node generates a Join Request and installs an AutoTxCell to the JP. The Join Request is then sent by the pledge to its JP over the AutoTxCell. The AutoTxCell is removed by the pledge editorial: I'd suggest s/its JP/its selected JP/ Response is sent out. The pledge receives the Join Response from its AutoRxCell, thereby learns the keying material used in the network, as well as other configurations, and becomes a "joined node". nit: maybe "other configuration values" or "other configuration settings"? Section 4.6 Once it has selected a routing parent, the joined node MUST generate a 6P ADD Request and install an AutoTxCell to that parent. The 6P ADD Request is sent out through the AutoTxCell with the following fields: * CellOptions: set to TX=1,RX=0,SHARED=0 * NumCells: set to 1 * CellList: at least 5 cells, chosen according to Section 8 Is this listing describing the contents of the ADD request or the AuthTxCell used to send it? (I presume the former, in which case I suggest to use "containing" or similar in preference to "with".) Section 5.1 The goal of MSF is to manage the communication schedule in the 6TiSCH schedule in a distributed manner. For a node, this translates into monitoring the current usage of the cells it has to the selected parent: Is this goal strictly limited to traffic "to the selected parent" vs. all traffic? * If the node determines that the number of link-layer frames it is attempting to exchange with the selected parent per unit of time is larger than the capacity offered by the TSCH negotiated cells it has scheduled with it, the node issues a 6P ADD command to that parent to add cells to the TSCH schedule. * If the traffic is lower than the capacity, the node issues a 6P DELETE command to that parent to delete cells from the TSCH schedule. As written, this would potentially lead to oscillation when demand is basically at capacity, due to the quantization of capacity. Perhaps some provisioning for hysteresis is appropriate? The cell option of cells listed in CellList in 6P Request frame SHOULD be either Tx=1 only or Rx=1 only. Both NumCellsElapsed and NumCellsUsed counters can be used to both type of negotiated cells. Would this be more clear as "(Tx=1,Rx=0) or (Tx=0,Rx=1)"? * NumCellsElapsed is incremented by exactly 1 when the current cell is AutoRxCell. This holds for all peers/parents we're keeping counters for, so the AutoRxCell can get "double counted"? In case that a node booted or disappeared from the network, the cell reserved at the selected parent may be kept in the schedule forever. A clean-up mechanism MUST be provided to resolve this issue. The clean-up mechanism is implementation-specific. It could either be a periodic polling to the neighbors the nodes have negotiated cells with, or monitoring the activities on those cells. The goal is to confirm those negotiated cells are not used anymore by the associated neighbors and remove them from the schedule. I'm not sure that "monitoring the activities on those cells" is safe with the current level of specification; if a node negotiates a 6P transmit cell to a parent and uses it only sparingly, with the parent eventually reclaiming it due to inactivity, I don't see a mechanism by which the node will reliably discover the negotiated cell to be nonfunctional and fall back to (e.g.) the corresponding AutoTxCell. It may be most prudent to just not mention that as an example (a "periodic polling" procedure does not seem to have the same potential for information skew) Section 5.3 schedule is executed and the node sends frames to that parent. When NumTx reaches MAX_NUMTX, both NumTx and NumTxAck MUST be divided by 2. For example, when MAX_NUMTX is set to 256, from NumTx=255 and NumTxAck=127, the counters become NumTx=128 and NumTxAck=64 if one frame is sent to the parent with an Acknowledgment received. This operation does not change the value of the PDR, but allows the counters to keep incrementing. The value of MAX_NUMTX is implementation-specific. Does MAX_NUMTX need to be a power of two (to avoid errors when the division occurs)? 4. For any other cell, it compares its PDR against that of the cell with the highest PDR. If the difference is larger than RELOCATE_PDRTHRES, it triggers the relocation of that cell using a 6P RELOCATE command. The recommended RELOCATE_PDRTHRES is given as "50 %". Is this "difference" performed as a subtraction (so that if the highest PDR is less than 50%, no cells can ever be relocated) or a ratio (a PDR that's half than the maximum PDR or smaller will trigger relocation)? Section 7 Maybe reference Section 17.1 where the allocation will occur? Section 8 * The slotOffset of a cell in the CellList SHOULD be randomly and uniformly chosen among all the slotOffset values that satisfy the restrictions above. * The channelOffset of a cell in the CellList SHOULD be randomly and uniformly chosen in [0..numFrequencies], where numFrequencies represents the number of frequencies a node can communicate on. Do these random selections need to be independent from each other? (I note that the selection for the autonomous cells are not.) Section 9 Is there a reference for these three parameters (MAXBE, MAXRETRIES, SLOTFRAME_LENGTH)? SLOTFRAME_LENGTH seems new in this document and is listed in the table in Section 14, but the other two are not listed there. Section 14 Why is MAX_NUMTX not listed in the table? Can we really give a recommended NUM_CH_OFFSET value, since this is in effect dependent on the number of channels available? KA_PERIOD is defined but not used elsewhere in the document. What are the considerations in using a power of 10 vs. a power of 2 as MAX_NUM_CELLS? Section 16 MSF defines a series of "rules" for the node to follow. It triggers several actions, that are carried out by the protocols defined in the following specifications: the Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration [RFC8180], the 6TiSCH Operation I'd suggest a brief note that the security considerations of those protocols continue to apply (even though it ought to be obvious); reading them could help a reader understand the behavior of this document as well. Sublayer Protocol (6P) [RFC8480], and the Minimal Security Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security]. In particular, MSF [CoJP again] prevent it from receiving the join response. This situation should be detected through the absence of a particular node from the network and handled by the network administrator through out-of-band means, e.g. by moving the node outside the radio range of the attacker. "the radio range of the attacker" is not exactly a fixed constant ... attackers are not in general bound by legal limits and can increase Tx power subject only to their equipment and budget. MSF adapts to traffics containing packets from IP layer. It is possible that the IP packet has a non-zero DSCP (Diffserv Code Point [RFC2597]) value in its IPv6 header. The decision whether to hand RFC 2597 is talking more about specifically assured forwarding PHB groups than "DSCP codepoint"s per se. Section 18.1 RFC 6206 seems to only be used as an example (Trickle), and could probably be informative. RFC 8505 might also not need to be normative. Appendix B In MSF, the T is replaced by the length slotframe 1. String s is nit: "length of" 2. sum the value of L_shift(h,l_bit), R_shift(h,r_bit) and ci Is this addition performed in "infinite precision" integer arithmetic or limited to the output width of h, e.g., by modular division? (It's not clear to me whether this is the role T plays or not.) 8. assign the result of Step 5 to h The value from step 5 *is* h, so taken literally this says "assign h to h" and is not needed. |
2020-03-11
|
12 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-03-11
|
12 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-03-11
|
12 | Mirja Kühlewind | [Ballot comment] I agree with Roman's discuss that the relation to SAX-DASFAA should be clarified and if this is actually needed for interoperability (as stated … [Ballot comment] I agree with Roman's discuss that the relation to SAX-DASFAA should be clarified and if this is actually needed for interoperability (as stated at some point in the text) it seems this should be part of the body of the document. Or what are the requirements for interoperability? What can be changed in the "example" algorithm and what not? Two small technical points: 2) Sec 9; mostly double-checking as you probably know better than me: "6P timeout value is calculated as ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH" Often you calculate such a value and then multiply by 2 (or something) to be on the safe side, as there could be e.g. processing delays in the receiving node. I assume the assumption here is that you always need to get the response in the same/after one slot (?). If that is true, I guess the calculation is fine. But wanted to check that there cannot be any additional unknown delays here. Further, these values come a bit out of nothing. Where are MAXBE and MAXRETRIES defined? And if you have an exponential backoff that will stop retrying after MAXRETRIES why do you need also a timeout in addition to that? 2) Sec 16: " MSF adapts to traffics containing packets from IP layer. It is possible that the IP packet has a non-zero DSCP (Diffserv Code Point [RFC2597]) value in its IPv6 header. The decision whether to hand over that packet to MAC layer to transmit or to drop that packet belongs to the upper layer and is out of scope of MSF. As long as the decision is made to hand over to MAC layer to transmit, MSF will take that packet into account when adapting to traffic." Why should a packet be dropped based on it DSCP...? Maybe be a bit more neutral here like: " MSF adapts to traffics containing packets from IP layer. It is possible that the IP packet has a non-zero DSCP (Diffserv Code Point [RFC2597]) value in its IPv6 header. The decision how to handle belongs to the upper layer and is out of scope of MSF. As long as a decision is made to hand over to MAC layer to transmit, MSF will take that packet into account when adapting to traffic." Some small editorial nits/comments: 1) Sec 1: - Maybe expand RPL on first occurrence. - s/is called as a "MSF session"/is called a "MSF session"/ 2) Sec 2 - s/one of more slotframes/one or more slotframes/ 3) Sec 4.4 - Please expand JRC on first occurrence. Maybe add a glossary at the beginning? 4) Sec 5.1. " A node implementing MSF MUST implement the behavior described in this section." Not sure if that sentence brings any additional value because that's what specs are for. But I guess it also doesn't hurt. And respectively I find the statement in 5.3 rather confusing " A node implementing MSF SHOULD implement the behavior described in this section. The "MUST" statements in this section hence only apply if the node implements schedule collision handling." I'm not fully sure what this even means now. Can you explain? Can you maybe rather provide some text to explain when it could/MAY be appropriate to not implement it? 5) Sec 16: "The implementation at IPv6 layer SHOULD ensure that this join traffic is rate-limited before it is passed to 6top sublayer where MSF can observe it. " Maybe be less indirect here: "The implementation at IPv6 layer SHOULD rate-limited join traffic before it is passed to 6top sublayer where MSF can observe it." Also this wording is a bit unclear: " How this rate limit is set is out of scope of MSF." Maybe " How this rate limit is implemented is out of scope of MSF. 6) "Appendix A. Contributors" -> Usually Contributors is an own section in the body of the document and not part of the appendix but I'm sure the RFC editor will advise you correctly. |
2020-03-11
|
12 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2020-03-11
|
12 | Mirja Kühlewind | [Ballot comment] I agree with Roman's discuss that reaction to SAX-DASFAA should be clarified and if this is actually needed for interoperability (as stated at … [Ballot comment] I agree with Roman's discuss that reaction to SAX-DASFAA should be clarified and if this is actually needed for interoperability (as stated at some point in the text) it seems this should be part of the body of the document. Or what are the requirement for interoperability? What can be changes in the "example" algorithm and what not? Two small technical points: 2) Sec 9; mostly double-checking as you probably know better than me: "6P timeout value is calculated as ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH" Often you calculate such a value and then multiply by 2 (or something) to be on the safe side, as there could be e.g. processing delays in the receiving node. I assume the assumption here is that you always need to get the response in the same/after one slot (?). If that is true, I guess the calculation is fine. But wanted to check that there cannot be any additional unknown delays here. Further, these values come a bit out of nothing. Where are MAXBE and MAXRETRIES defined? And if you have an exponential backoff that will stop retrying after MAXRETRIES why do you need also a timeout in addition to that? 2) Sec 16: " MSF adapts to traffics containing packets from IP layer. It is possible that the IP packet has a non-zero DSCP (Diffserv Code Point [RFC2597]) value in its IPv6 header. The decision whether to hand over that packet to MAC layer to transmit or to drop that packet belongs to the upper layer and is out of scope of MSF. As long as the decision is made to hand over to MAC layer to transmit, MSF will take that packet into account when adapting to traffic." Why should a packet be dropped based on it DSCP...? Maybe be a bit more neutral here like: " MSF adapts to traffics containing packets from IP layer. It is possible that the IP packet has a non-zero DSCP (Diffserv Code Point [RFC2597]) value in its IPv6 header. The decision how to handle belongs to the upper layer and is out of scope of MSF. As long as a decision is made to hand over to MAC layer to transmit, MSF will take that packet into account when adapting to traffic." Some small editorial nits/comments: 1) Sec 1: - Maybe expand RPL on first occurrence. - s/is called as a "MSF session"/is called a "MSF session"/ 2) Sec 2 - s/one of more slotframes/one or more slotframes/ 3) Sec 4.4 - Please expand JRC on first occurrence. Maybe add a glossary at the beginning? 4) Sec 5.1. " A node implementing MSF MUST implement the behavior described in this section." Not sure if that sentence brings any additional value because that's what specs are for. But I guess it also doesn't hurt. And respectively I find the statement in 5.3 rather confusing " A node implementing MSF SHOULD implement the behavior described in this section. The "MUST" statements in this section hence only apply if the node implements schedule collision handling." I'm not fully sure what this even means now. Can you explain? Can you maybe rather provide some text to explain when it could/MAY be appropriate to not implement it? 5) Sec 16: "The implementation at IPv6 layer SHOULD ensure that this join traffic is rate-limited before it is passed to 6top sublayer where MSF can observe it. " Maybe be less indirect here: "The implementation at IPv6 layer SHOULD rate-limited join traffic before it is passed to 6top sublayer where MSF can observe it." Also this wording is a bit unclear: " How this rate limit is set is out of scope of MSF." Maybe " How this rate limit is implemented is out of scope of MSF. 6) "Appendix A. Contributors" -> Usually Contributors is an own section in the body of the document and not part of the appendix but I'm sure the RFC editor will advise you correctly. |
2020-03-11
|
12 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2020-03-09
|
12 | Roman Danyliw | [Ballot discuss] Section 3. Can the normative reference for the SAX algorithm be clarified. The text cites [SAX-DASFAA], but this is an informative reference (and … [Ballot discuss] Section 3. Can the normative reference for the SAX algorithm be clarified. The text cites [SAX-DASFAA], but this is an informative reference (and an academic paper with no URL). Appendix B, appears to also describe an algorithm but the introduction describes the text as “an example implementation SAX hash function”. |
2020-03-09
|
12 | Roman Danyliw | [Ballot comment] ** Section 4.2. of RFC8480 outlines requirements for a specification of an SF. One of those it that the SF “SHOULD clearly state … [Ballot comment] ** Section 4.2. of RFC8480 outlines requirements for a specification of an SF. One of those it that the SF “SHOULD clearly state the application domain the SF is created for.” Is there one for this draft? ** Section 5.1. Per “In case that a node booted or disappeared from the network, the cell reserved at the selected parent may be kept in the schedule forever. A clean-up mechanism MUST be provided to resolve this issue.”, is there an implicit DDoS being described here where rogue nodes could boot up and hold cells before the clean-up mechanism activates? ** Appendix B. Per step #8, what does this do? h should already have the final value of Step 4 assigned to h. ** Editorial Nits: -- Section 4.4. Typo. s/Neighbor Dicovery/Discovery/ -- Section 16. Typos. s/MSF adapts to traffics containing packets from IP layer/MSF adapts to traffic containing packet from the IP layer/ |
2020-03-09
|
12 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2020-03-07
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-03-07
|
12 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-12.txt |
2020-03-07
|
12 | (System) | New version approved |
2020-03-07
|
12 | (System) | Request for posting confirmation emailed to previous authors: Tengfei Chang , Diego Dujovne , Malisa Vucinic , Simon Duquennoy , Xavier Vilajosana |
2020-03-07
|
12 | Tengfei Chang | Uploaded new revision |
2020-03-06
|
11 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-03-05
|
11 | Vijay Gurbani | Request for Telechat review by GENART Completed: Ready. Reviewer: Vijay Gurbani. Sent review to list. |
2020-03-05
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Vijay Gurbani |
2020-03-05
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Vijay Gurbani |
2020-03-04
|
11 | Wesley Eddy | Request for Telechat review by TSVART is assigned to Jana Iyengar |
2020-03-04
|
11 | Wesley Eddy | Request for Telechat review by TSVART is assigned to Jana Iyengar |
2020-03-03
|
11 | Cindy Morgan | Placed on agenda for telechat - 2020-03-12 |
2020-03-03
|
11 | Suresh Krishnan | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-03-03
|
11 | Suresh Krishnan | Ballot has been issued |
2020-03-03
|
11 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2020-03-03
|
11 | Suresh Krishnan | Created "Approve" ballot |
2020-03-03
|
11 | Suresh Krishnan | Ballot writeup was changed |
2020-02-28
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2020-02-28
|
11 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-11.txt |
2020-02-28
|
11 | (System) | New version approved |
2020-02-28
|
11 | (System) | Request for posting confirmation emailed to previous authors: Simon Duquennoy , Malisa Vucinic , Tengfei Chang , Xavier Vilajosana , Diego Dujovne |
2020-02-28
|
11 | Tengfei Chang | Uploaded new revision |
2020-02-27
|
10 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-02-26
|
10 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2020-02-26
|
10 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-6tisch-msf-10. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-6tisch-msf-10. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the 6P Scheduling Function Identifiers registry on the IPv6 Over the TSCH Mode of IEEE 802.15.4e (6TiSCH) registry page located at: https://www.iana.org/assignments/_6tisch/ a single, new registration is to be made as follows: SFID: [ TBD-at-Registration ] Name: Minimal Scheduling Function (MSF) Reference: [ RFC-to-be ] IANA Question --> The authors supply a SFID of "IANA_6TISCH_SFID_MSF" but the registry allows for SFIDs in the range 0-255. Which of the two ranges in the registry should be used for this new registration? The IANA Functions Operator understands that this is the only action 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 |
2020-02-20
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2020-02-20
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2020-02-18
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Nagendra Kumar |
2020-02-18
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Nagendra Kumar |
2020-02-14
|
10 | Vijay Gurbani | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Vijay Gurbani. Sent review to list. |
2020-02-13
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2020-02-13
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
2020-02-13
|
10 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2020-02-13
|
10 | Amy Vezza | The following Last Call announcement was sent out (ends 2020-02-27): From: The IESG To: IETF-Announce CC: pthubert@cisco.com, Pascal Thubert , 6tisch-chairs@ietf.org, draft-ietf-6tisch-msf@ietf.org, … The following Last Call announcement was sent out (ends 2020-02-27): From: The IESG To: IETF-Announce CC: pthubert@cisco.com, Pascal Thubert , 6tisch-chairs@ietf.org, draft-ietf-6tisch-msf@ietf.org, 6tisch@ietf.org, suresh@kaloom.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (6TiSCH Minimal Scheduling Function (MSF)) 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: - '6TiSCH Minimal Scheduling Function (MSF)' 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 last-call@ietf.org mailing lists by 2020-02-27. 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 specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF is built upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3270/ The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-6tisch-architecture: An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4 (None - IETF stream) |
2020-02-13
|
10 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2020-02-13
|
10 | Suresh Krishnan | Last call was requested |
2020-02-13
|
10 | Suresh Krishnan | Last call announcement was generated |
2020-02-13
|
10 | Suresh Krishnan | Ballot approval text was generated |
2020-02-13
|
10 | Suresh Krishnan | Ballot writeup was generated |
2020-02-13
|
10 | Suresh Krishnan | IESG state changed to Last Call Requested from AD Evaluation |
2019-12-19
|
10 | Suresh Krishnan | IESG state changed to AD Evaluation from Publication Requested |
2019-12-13
|
10 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-10.txt |
2019-12-13
|
10 | (System) | New version approved |
2019-12-13
|
10 | (System) | Request for posting confirmation emailed to previous authors: Tengfei Chang , 6tisch-chairs@ietf.org, Diego Dujovne , Simon Duquennoy , Xavier Vilajosana , Malisa Vucinic |
2019-12-13
|
10 | Tengfei Chang | Uploaded new revision |
2019-12-13
|
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 … (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? This is a intended as proposed standard, and the document indictates Intended status: Standards Track. (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 specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF builds upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH. Other SFs may be defined in the future. Working Group Summary: The group work on Scheduling Functions (SF) for a long time, with work such as SF0 and ASF. The best ideas were merged in this simplified version. The methid was implemented and implementation feedback helped refining the details of it. Document Quality: There is at least one implementation by INRIA (Tengfei Chang). Tengfei reported on experimentations at IETF 106. There's also an implementation in te Kon Tiki simulator. Yasuyuki Tanaka performed extensive reviews as part of his work on the simulator. 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 shepherd performed an in depth review in parallel with an additional one by Yasuyuki Tanaka. The security section was enhanced, and the fact that all parents are managed individually was clarified. V-09 is the main outcome, with additions in v-10. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. The document appears ready. (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 such thing (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 such thing (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? All the authors responded that there's no IPR. (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 a disclosure by Cisco (https://datatracker.ietf.org/ipr/3253/) that was discussed in the thread "IPR Disclosure Cisco's Statement about IPR related to draft-chang-6tisch-msf". There was no opposition. Note that Cisco has IPR on key elements of 6TiSCH so this does not change the situation in any remarkable way. (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? The core of the 6TiSCH participants reviewed and supported the document. (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 thing (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nothing apart downrefs discussed below (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No such need (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? Nothing disquieting, on the contrary publication will help move cluster 130 on. (https://www.rfc-editor.org/cluster_info.php?cid=C310) This draft is actually already expected in C130 for a X-ref with the 6TiSCH Architecture. One reference, ietf-6tisch-enrollment-enhanced-beacon is passed WGLC. They other references are already queued at RFC editor in MISSREF for this and other drafts. (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. The NITs tool found one DOWNREF to be sorted out with A-D. This is the 6TiSCH architecture that was downgraded to INFO from an initial STD target. Interestingly RFC 7554 is also a DOWNREF, not caught by the tool. I asked the authors to move to informational references since it does not appear to be used normatively. (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 such thing (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 8126). IANA section checked, the proposed addition in an existing subregistry is correctly documented and matches the registration procedure. (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. No added (sub) registry (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, YANG modules, etc. No such thing (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No such thing |
2019-12-13
|
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 … (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? This is a intended as proposed standard, and the document indictates Intended status: Standards Track. (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 specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF builds upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH. Other SFs may be defined in the future. Working Group Summary: The group work on Scheduling Functions (SF) for a long time, with work such as SF0 and ASF. The best ideas were merged in this simplified version. The methid was implemented and implementation feedback helped refining the details of it. Document Quality: There is at least one implementation by INRIA (Tengfei Chang). Tengfei reported on experimentations at IETF 106. There's also an implementation in te Kon Tiki simulator. Yasuyuki Tanaka performed extensive reviews as part of his work on the simulator. 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 shepherd performed an in depth review in parallel with an additional one by Yasuyuki Tanaka. The security section was enhanced, and the fact that all parents are managed individually was clarified. V-09 is the main outcome, with additions in v-10. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. The document appears ready. (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 such thing (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 such thing (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? All the authors responded that there's no IPR, but one. Still chasing him. I do not expect there's IPR though, since the author was working with ri.se at the time. (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 a disclosure by Cisco (https://datatracker.ietf.org/ipr/3253/) that was discussed in the thread "IPR Disclosure Cisco's Statement about IPR related to draft-chang-6tisch-msf". There was no opposition. Note that Cisco has IPR on key elements of 6TiSCH so this does not change the situation in any remarkable way. (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? The core of the 6TiSCH participants reviewed and supported the document. (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 thing (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nothing apart downrefs discussed below (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No such need (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? Nothing disquieting, on the contrary publication will help move cluster 130 on. (https://www.rfc-editor.org/cluster_info.php?cid=C310) This draft is actually already expected in C130 for a X-ref with the 6TiSCH Architecture. One reference, ietf-6tisch-enrollment-enhanced-beacon is passed WGLC. They other references are already queued at RFC editor in MISSREF for this and other drafts. (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. The NITs tool found one DOWNREF to be sorted out with A-D. This is the 6TiSCH architecture that was downgraded to INFO from an initial STD target. Interestingly RFC 7554 is also a DOWNREF, not caught by the tool. I asked the authors to move to informational references since it does not appear to be used normatively. (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 such thing (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 8126). IANA section checked, the proposed addition in an existing subregistry is correctly documented and matches the registration procedure. (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. No added (sub) registry (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, YANG modules, etc. No such thing (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No such thing |
2019-12-13
|
09 | Pascal Thubert | Responsible AD changed to Suresh Krishnan |
2019-12-13
|
09 | Pascal Thubert | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2019-12-13
|
09 | Pascal Thubert | IESG state changed to Publication Requested from I-D Exists |
2019-12-13
|
09 | Pascal Thubert | IESG process started in state Publication Requested |
2019-12-13
|
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 … (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? This is a intended as proposed standard, and the document indictates Intended status: Standards Track. (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 specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF builds upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH. Other SFs may be defined in the future. Working Group Summary: The group work on Scheduling Functions (SF) for a long time, with work such as SF0 and ASF. The best ideas were merged in this simplified version. The methid was implemented and implementation feedback helped refining the details of it. Document Quality: There is at least one implementation by INRIA (Tengfei Chang). Tengfei reported on experimentations at IETF 106. There's also an implementation in te Kon Tiki simulator. Yasuyuki Tanaka performed extensive reviews as part of his work on the simulator. 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 shepherd performed an in depth review in parallel with an additional one by Yasuyuki Tanaka. The security section was enhanced, and the fact that all parents are managed individually was clarified. V-09 is the main outcome, with additions in v-10. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. The document appears ready. (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 such thing (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 such thing (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? All the authors responded that there's no IPR, but one. Still chasing him. I do not expect there's IPR though, since the author was working with ri.se at the time. (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 a disclosure by Cisco (https://datatracker.ietf.org/ipr/3253/) that was discussed in the thread "IPR Disclosure Cisco's Statement about IPR related to draft-chang-6tisch-msf". There was no opposition. Note that Cisco has IPR on key elements of 6TiSCH so this does not change the situation in any remarkable way. (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? The core of the 6TiSCH participants reviewed and supported the document. (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 thing (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nothing apart downrefs discussed below (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No such need (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? Nothing disquieting, on the contrary publication will help move cluster 130 on. (https://www.rfc-editor.org/cluster_info.php?cid=C310) This draft is actually already expected in C130 for a X-ref with the 6TiSCH Architecture. One reference, ietf-6tisch-enrollment-enhanced-beacon is passed WGLC. They other references are already queued at RFC editor in MISSREF for this and other drafts. (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. The NITs tool found one DOWNREF to be sorted out with A-D. This is the 6TiSCH architecture that was downgraded to INFO from an initial STD target. Interestingly RFC 7554 is also a DOWNREF, not caught by the tool. I asked the authors to move to informational references since it does not appear to be used normatively. (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 such thing (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 8126). IANA section checked, the proposed addition in an existing subregistry is correctly documented and matches the registration procedure. (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. No added (sub) registry (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, YANG modules, etc. No such thing (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No such thing |
2019-12-12
|
09 | Pascal Thubert | 9. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of … 9. (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? > This is a intended as proposed standard, and the document indictates Intended status: Standards Track. (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 specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF builds upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH. Other SFs may be defined in the future. Working Group Summary: The group work on Scheduling Functions (SF) for a long time, with work such as SF0 and ASF. The best ideas were merged in this simplified version. The methid was implemented and implementation feedback helped refining the details of it. Document Quality: There is at least one implementation by INRIA (Tengfei Chang). Tengfei reported on experimentations at IETF 106. There's also an implementation in te Kon Tiki simulator. Yasuyuki Tanaka performed extensive reviews as part of his work on the simulator. 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 shepherd performed an in depth review in parallel with an additional one by Yasuyuki Tanaka. The security section was enhanced, and the fact that all parents are managed individually was clarified. V-09 is the outcome. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concern. The document appears ready. (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 such thing (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 such thing (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? (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 a disclosure by Cisco (https://datatracker.ietf.org/ipr/3253/) that was discussed in the thread "IPR Disclosure Cisco's Statement about IPR related to draft-chang-6tisch-msf". (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? (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.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (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? (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. (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. (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 8126). (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. (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, YANG modules, etc. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? |
2019-12-12
|
09 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-09.txt |
2019-12-12
|
09 | (System) | New version approved |
2019-12-12
|
09 | (System) | Request for posting confirmation emailed to previous authors: Simon Duquennoy , Xavier Vilajosana , Diego Dujovne , Malisa Vucinic , Tengfei Chang |
2019-12-12
|
09 | Tengfei Chang | Uploaded new revision |
2019-12-12
|
09 | (System) | Request for posting confirmation emailed to previous authors: Simon Duquennoy , Xavier Vilajosana , Diego Dujovne , Malisa Vucinic , Tengfei Chang |
2019-12-12
|
09 | Tengfei Chang | Uploaded new revision |
2019-11-25
|
08 | Pascal Thubert | Changed consensus to Yes from Unknown |
2019-11-25
|
08 | Pascal Thubert | Intended Status changed to Proposed Standard from None |
2019-11-25
|
08 | Pascal Thubert | Notification list changed to Pascal Thubert <pthubert@cisco.com> |
2019-11-25
|
08 | Pascal Thubert | Document shepherd changed to Pascal Thubert |
2019-11-04
|
08 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-08.txt |
2019-11-04
|
08 | (System) | New version approved |
2019-11-04
|
08 | (System) | Request for posting confirmation emailed to previous authors: Simon Duquennoy , Xavier Vilajosana , Diego Dujovne , Malisa Vucinic , Tengfei Chang |
2019-11-04
|
08 | Tengfei Chang | Uploaded new revision |
2019-10-17
|
07 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-07.txt |
2019-10-17
|
07 | (System) | New version approved |
2019-10-17
|
07 | (System) | Request for posting confirmation emailed to previous authors: Simon Duquennoy , Xavier Vilajosana , Diego Dujovne , Malisa Vucinic , Tengfei Chang |
2019-10-17
|
07 | Tengfei Chang | Uploaded new revision |
2019-08-12
|
06 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-06.txt |
2019-08-12
|
06 | (System) | New version approved |
2019-08-12
|
06 | (System) | Request for posting confirmation emailed to previous authors: Simon Duquennoy , Xavier Vilajosana , Diego Dujovne , Malisa Vucinic , Tengfei Chang |
2019-08-12
|
06 | Tengfei Chang | Uploaded new revision |
2019-07-08
|
05 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-05.txt |
2019-07-08
|
05 | (System) | New version approved |
2019-07-08
|
05 | (System) | Request for posting confirmation emailed to previous authors: Simon Duquennoy , Xavier Vilajosana , Diego Dujovne , Malisa Vucinic , Tengfei Chang |
2019-07-08
|
05 | Tengfei Chang | Uploaded new revision |
2019-07-02
|
04 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-04.txt |
2019-07-02
|
04 | (System) | New version approved |
2019-07-02
|
04 | (System) | Request for posting confirmation emailed to previous authors: Simon Duquennoy , Xavier Vilajosana , Diego Dujovne , Malisa Vucinic , Tengfei Chang |
2019-07-02
|
04 | Tengfei Chang | Uploaded new revision |
2019-04-08
|
03 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-03.txt |
2019-04-08
|
03 | (System) | New version approved |
2019-04-08
|
03 | (System) | Request for posting confirmation emailed to previous authors: Simon Duquennoy , Xavier Vilajosana , Diego Dujovne , Malisa Vucinic , Tengfei Chang |
2019-04-08
|
03 | Tengfei Chang | Uploaded new revision |
2019-03-25
|
02 | Thomas Watteyne | Added to session: IETF-104: 6tisch Mon-1120 |
2019-03-11
|
02 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-02.txt |
2019-03-11
|
02 | (System) | New version approved |
2019-03-11
|
02 | (System) | Request for posting confirmation emailed to previous authors: Malisa Vucinic , Tengfei Chang , Diego Dujovne , 6tisch-chairs@ietf.org, Simon Duquennoy , Xavier Vilajosana |
2019-03-11
|
02 | Tengfei Chang | Uploaded new revision |
2018-11-07
|
01 | Thomas Watteyne | Added to session: IETF-103: 6tisch Thu-1610 |
2018-10-22
|
01 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-01.txt |
2018-10-22
|
01 | (System) | New version approved |
2018-10-22
|
01 | (System) | Request for posting confirmation emailed to previous authors: Malisa Vucinic , Simon Duquennoy , Xavier Vilajosana , Diego Dujovne , Tengfei Chang |
2018-10-22
|
01 | Tengfei Chang | Uploaded new revision |
2018-08-24
|
Jenny Bui | Posted related IPR disclosure: Cisco's Statement about IPR related to draft-ietf-6tisch-msf | |
2018-08-21
|
00 | Tengfei Chang | New version available: draft-ietf-6tisch-msf-00.txt |
2018-08-21
|
00 | (System) | WG -00 approved |
2018-08-21
|
00 | Tengfei Chang | Set submitter to "Tengfei Chang ", replaces to (none) and sent approval email to group chairs: 6tisch-chairs@ietf.org |
2018-08-21
|
00 | Tengfei Chang | Uploaded new revision |