Hi Michael, Sorry for my late reply (but I guess you could have just went ahead and push a new version anyway…). Please see below.
> On 1. Nov 2019, at 22:15, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > <#secure method=pgpmime mode=sign> > > Mirja Kühlewind via Datatracker <nore...@ietf.org> wrote: >> 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. > > okay, how about: > > + The Join Proxy implements a data cap on outgoing join traffic by > implementing > + the <xref target="RFC8085" /> section 3.1.3 recommendation of 1 packet per 3 > + seconds. > + This can be achieved with the congestion control mechanism specified > + in <xref target="RFC7252" /> section 4.7. Great! Thanks! > > >> 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. > > I think you are saying that we should have a default PROBING_RATE, if the JRC > does not specify one. I think that we assumed that the RFC7257 section 4.8 > value of 1 byte/second would apply. please confirm? Yes, stating this explicitly would be good! > >> 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? > > Because RFC6282 (and friends) has specific encoding to omit DSCP if it is > zero. I understand what you want to do but saying “does not set” but “should set” seems to be contracting. I think this is only a wording issue though. I guess it could be something like this: "A Join Proxy that does not require a specific DSCP value on traffic forwarded should set it to zero so that it is compressed out.” > >> I would think it >> either sets it to AF43 or it does nothing about it because DSCP is not >> really used in that network. > > In 6tisch networks, different DSCP points can be used to get different > behaviours, see .... UHM. Let me get back to you on this, because the > reference has evaporated. A reference would be good (in the draft) :-) > >> 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? > > We got pushback about relying on 7252 defaults, because what if they changed. That’s fine but the you need to add all values! > >> 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). > > I guess since it's a MUST for the JRC, we need to do that. Good. Thanks! > >> ---------------------------------------------------------------------- >> 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... > > so like: > title: Constrained Join Protocol for 6TiSCH Do you propose to get rid of the “Minimal Security Framework” part and only call the document "Constrained Join Protocol (CoJP) for 6TiSCH”. I think this would be a more appropriate title, but maybe confirm with the rest of the group. Thanks! Mirja > >> 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."+ > > You are right. The last sentence does not belong. > During the join process, the network identifer, returned in the CoJP response > is a MUST (8.4.1) > >> 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. > > reference added. > >> 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." > > done. > >> 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 ..." ? > > done. > > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
