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 mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch