[6tisch] Roman Danyliw's Discuss on draft-ietf-6tisch-msf-12: (with DISCUSS and COMMENT)

[Tengfei Chang <[e-mail]>]

Hello Roman, 

Thanks for the comments on the draft! 
I replied inline starting with '> ' 

=============================================================== 
Roman Danyliw has entered the following ballot position for 
draft-ietf-6tisch-msf-12: 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-msf/ 


---------------------------------------------------------------------- 
DISCUSS: 
---------------------------------------------------------------------- 

Section 3. Can the normative reference for the SAX algorithm be clarified. 
The text cites [SAX-DASFAA], but this is an informative reference (and an 
academic paper with no URL). Appendix B, appears to also describe an algorithm 
but the introduction describes the text as “an example implementation SAX hash 
function”. 

> Considering the interoperability, the SAX algorithm MUST be implemented which indicates SAX is a normative reference. 
> So to your question, yes. 
> The Appendix B describes how the SAX algorithm works also it defines the value of parameters used 
> In SAX, for interoperability consideration as well. 
> The DOI of this SAX paper is at https://doi.org/10.1142/9789812819536_0023 
> For action, we will move the SAX citation to normative reference along with the DOI address. 

---------------------------------------------------------------------- 
COMMENT: 
---------------------------------------------------------------------- 

** Section 4.2. of RFC8480 outlines requirements for a specification of an SF. 
One of those it that the SF “SHOULD clearly state the application domain the SF 
is created for.” Is there one for this draft? 

> Yes, in Section 1, the application domain is declared as wide range of domain 
> but optimized for applications with upstream traffic (from the nodes to the DODAG root). 

MSF is designed to operate in a wide range of application domains.
   It is optimized for applications with regular upstream traffic (from
   the nodes to the DODAG root). 


** Section 5.1. Per “In case that a node booted or disappeared from the 
network, the cell reserved at the selected parent may be kept in the schedule 
forever. A clean-up mechanism MUST be provided to resolve this issue.”, is 
there an implicit DDoS being described here where rogue nodes could boot up and 
hold cells before the clean-up mechanism activates? 

> For this paragraph, we are actually trying to describe more generic situation such as: 
> The maintainer of the network manually switched off the node and on later or just because out of battery. 
> The clean-up mechanism happens on the parent of the node who is booted or disappeared. 

> May I understand it wrong, but when a node boots up, its schedule should be reset as well, hence it won't be 
> hold the previous cells to the parent. 

** Appendix B. Per step #8, what does this do? h should already have the 
final value of Step 4 assigned to h. 

> Yes, that's a redundant step. It will be removed from next re-version of MSF. 
> Thanks for pointing out! 

** Editorial Nits: 
-- Section 4.4. Typo. s/Neighbor Dicovery/Discovery/ 

> Will be fixed in next re-version, 

-- Section 16. Typos. s/MSF adapts to traffics containing packets from IP 
layer/MSF adapts to traffic containing packet from the IP layer/ 

> Will be fixed in next re-version ,