Hello Mirija, Thanks for the comments on the draft! I replied inline starting with '> '
On Wed, Mar 11, 2020 at 2:19 PM Mirja Kühlewind via Datatracker < nore...@ietf.org> wrote: > 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? > > The reference for SAX has been moved into normative reference section as suggested by Roman. > The requirements for interoperability are the identical parameters for the SAX algorithm > The proposed recommend values of those parameters are presented in the Appendix B. > We still believe put those those info in the Appendix B is proper. > If we put the SAX algorithm into the main content of the draft, it may read like jumping out from the main MSF content and going to a side knowledge of it. > We believe it is enough to like the reader knowing it's a hashing algorithm with node EUI64 address as input, used by MSF. > > 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. > > Thanks for the comments. The calculation of TIMEOUT is targeting to the worst case, not average. > So a multiply with 2 is not necessary. > In most case, the 6P response is sent by through the autonomous cell, which is the same slot, as you guessed. > > 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? > > When Mote A sent a 6P request to Mote B, the 6P Timeout timer starts on Mote A side. > On Mote B side, it will try to send out the 6P response within the MAXRETRIES. > Mote A does not know when the maxretires reached, hence it needs the 6P Timeout to be notified. > > 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." > > For quick response, yes, I like the propose to be neutral, will update it in the new revision. > To answer your question why the packet is dropped based on DSCP, I image a DoS attack make multiple of DSCP with non-zero value occupied in the sending queue and overwhelm the buffer. > However, it could be handle by some mechanism to quarantine them. > > 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"/ > > will integrate into next revision. > > 2) Sec 2 > - s/one of more slotframes/one or more slotframes/ > > will integrate into next revision. > > 3) Sec 4.4 > - Please expand JRC on first occurrence. Maybe add a glossary at the > beginning? > > will integrate into next revision. > > 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? > > Yes, we agree it is not clear. > The 'SHOULD' in the text is trying to state that the handling schedule collisions algorithm proposed in MSF draft is one of those algorithms. > Any implementer can choose other algorithm to handle the collision as an alternative. > The 'MUST' in the text is trying to state, if the implementer decides to implement the algorithm proposed in the draft, it must follow the description in the section. > I agree the 'MUST' in this case sounds redundant. The text will be replaced as following: > 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 > -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tchang.org/ ——————————————————————————————————————
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
