[6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-6tisch-architecture-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-architecture/ -- DISCUSS: -- I only had a quick read of this document, however, it seems to me that there are strong dependencies on a whole bunch of drafts, that are only listed as informational. I don't have a deep enough understanding to make a final judgement of which draft would need to be listed as normative references, however, I wanted to raise this point on the discuss level in order to ensure that this is considered before publication. To give an example: Section 4.6.3 goes quite seep into details of what's described in [I-D.ietf-6lo-fragment-recovery]. However as long as [I-D.ietf-6lo-fragment-recovery] is not published yet, the 6tisch arch should probably not rely on the content of this draft that strongly. Putting [I-D.ietf-6lo-fragment-recovery] as a normative reference ensures that this draft will not be published before [I-D.ietf-6lo-fragment-recovery]. -- COMMENT: -- As I said, I only had a rather brief read, however, I had a bit of problems to follow exactly which parts of the architecture rely on existing protocols and mechanisms and where 6tsch actually needs to define new approaches. Maybe a short, even higher-level overview than section 3, could address this and help the reader. ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
[6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-6tisch-minimal-security-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ -- DISCUSS: -- 1) I hope this point can be resolved quickly as it seems to only need a bit more specifics but I think this part is not sufficient: Sec 6.1: "The Join Proxy implements a data cap on outgoing join traffic through CoAP's congestion control mechanism." I think this needs an normative requirement here. Congestion control is supposed to avoid network overload but also to make use available resources. The congestion control as currently defined for CoAP would probably limit the join traffic appropriately (to something like one packet per RTT likely) but CoAP could in theory use any time a different more aggrieve congestion and therefore just relying on congestion control generically doesn't seem to be sufficient. I recommend to define a hard limit, e.g. 1 packet per RTT or 1 packet per 3 seconds if RTT is unknown (as recommended in RFC8085) and say that this can be achieved by congestion control as specified in the base CoAP spec. Further on there seems to be an implicit requirement that the JP MUST implement rate limit using the PROBING_RATE parameter, however, that is never explicitly spelled out as a normative requirement. However, if this rate is not provided by the JRC, it doesn't seem that any rate limiting has to be enforced. So maybe it would be good to be more strict here. 2) Also, not sure if this editorial or a real issue but I'm not sure I fully understand this sentence: Sec 6.1.1: "A Join Proxy that does not set the DSCP on traffic forwarded should set it to zero so that it is compressed out." If the proxy does NOT SET DSCP, why should it SET it to zero? I would think it either sets it to AF43 or it does nothing about it because DSCP is not really used in that network. I guess it's not a big issue and setting to zero seems fine as well but I'm afraid I don't understand the intent here and when exactly the Proxy is supposed to set to AF43 or bleach. 3) This may also be mostly editorial but just to be sure: Section 7.2 provides default values for some of the CoAP transport parameter (where 2 of 3 are the same as defined in RFC7252) but not for all. Why is that? 4 ) And then finally on references (again): Given that use of I-D.ietf-core-stateless is recommend, I believe it should be normative (and wait for publication of that doc). -- COMMENT: -- I'm putting this one question in the comments section because there is no concern that it does not work as specified but I wonder about the design of the Parameter Update Response Message. Given the Parameter Update Message is a confirmable CoAP message that is transmitted reliable and the content of the Parameter Update Response Message is empty, why do you need to send the Parameter Update Response Message at all? And some minor comments (mostly editorial proposals): 0) I'd recommend to "Constrained Join Protocol (CoJP)" in the document title to make clear that this is a protocol spec and not "only" and abstract framework or something... 1) Sec 3: Maybe I'm missing something but this seems contradictory: "Provisioning the network identifier is RECOMMENDED." And then at the end of that paragraph: "This parameter MUST be provisioned to the 6LBR pledge."+ 2) Sec 4.3.2: Not sure I fully understand the context of this sentence: "The JP operates as the application-layer proxy." Maybe "... operates as an application-layer proxy" or probably even better "operates as application-layer proxy" ? Also at this part of the document it is not clear that the proxy actually interprets the CoAP message. I recommend to mention this earlier in the doc and maybe add a forward reference to section 7. 3) Sec 5: Maybe just to be absolutely clear: OLD: "When sending frames during the join process, the pledge sends unencrypted and unauthenticated frames." NEW: "When sending frames during the join process, the pledge sends unencrypted and unauthenticated frames at the link layer." 4) Sec 6: "As a special case, the 6LBR pledge is expected to have an additional network interface ..." MAYBE: "As a special case, the 6LBR pledge may have an additional network interface ..." ?
[6tisch] Mirja Kühlewind's No Objection on draft-ietf-6tisch-minimal-security-14: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-6tisch-minimal-security-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ -- COMMENT: -- Thanks for addressing my discuss points and also other editorial comments! Also great that you clarified/introduced COJP_MAX_JOIN_ATTEMPTS; I think that also a really good change! - I only leave this old comment in here because it wasn't further discussed: I'm putting this one question in the comments section because there is no concern that it does not work as specified but I wonder about the design of the Parameter Update Response Message. Given the Parameter Update Message is a confirmable CoAP message that is transmitted reliable and the content of the Parameter Update Response Message is empty, why do you need to send the Parameter Update Response Message at all? ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
[6tisch] Mirja Kühlewind's No Objection on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-6tisch-enrollment-enhanced-beacon-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/ -- COMMENT: -- One question: How is the proxy priority supposed to be calculated/set? Is there a default value? Is also support points raised in Roman's discuss points. More clarification is needed. Editorial comment: I would recommend to repeat the abstract in the intro as, as stated in the RFC style guide RFC7322 section 4.3, "[...] an Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract." Nit: sec 1.3: s/Although However/Although/ or s/Although However/However/ ? s/a unicast RS may be transmitted in response[RFC6775] reduces the amount of.../a unicast RS that may be transmitted in response [RFC6775] reduces the amount of.../ ? (Also note missing space before [) ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
[6tisch] Mirja Kühlewind's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-6tisch-msf-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6tisch-msf/ -- 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. ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
