[6tisch] Mirja Kühlewind's No Objection on draft-ietf-6tisch-msf-12: (with COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

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.