Hi Eric,

Thanks for your comments!
I have responded inline :

On Tue, Mar 17, 2020 at 3:20 PM Éric Vyncke via Datatracker <
[email protected]> wrote:

> Éric Vyncke 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:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document.
>
> Please find below some non-blocking COMMENTs and NITs. An answer will be
> appreciated.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == COMMENTS ==
>
> As Alissa's comment, please use RFC 8174 boiler plate.
>
> -- Section 3 --
> Suggest to remove "The AutoRxCell MUST always remain scheduled after
> synchronized. *  6P CLEAR MUST NOT erase any autonomous cells." from the
> bulleted list and create a new paragraph for those 2 lines.
>

*RESPONSE*: Will update the text accordingly.

>
> -- Section 4 --
> The whole section seems to assume that the events will work as expected.
> But,
> what if this is not the case? E.g., the JP does not send any reply ?
>

*RESPONSE*: if JP does not send any reply, the node will retransmit another
Join request after a timeout.
However, the whole behavior is actually defined in CoJP. We repeat them
here is to make reader easy to understand the story line of a node once
bootup.

>
> -- Section 5.3 --
> "we necessarily have NumTxAck <= NumTx" is only true is all nodes behave...
>
> "MUST be divided by 2", the example is about 127 divided by 2 giving the
> unexpected value (to me at least) of 64... The text should clarify how
> rounding
> is handled as it is not a plain right shift by 1.
>
> Step 2, is it also applicable to any value of MAX_NUMTX ? Including very
> small
> or very large ones ?
>

*RESPONSE*:  thanks for the comments. We will state that the MAX_NUMTX
needs to be power of 2 to resolve the issue.
Also the recommended value of MAX_NUMTX is added in the draft.

>
> == NITS ==
>
> -- section 5.2 --
> To be checked by a native speaker but s/can have a node switch parent/can
> have
> a node switching parent/ would make the text easier to parse.
>
> -- Section 14 --
> Please order the rows of Figure 2.
>
> *RESPONSE*: it will be ordered as the time it appears in the text in
next version.

>
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——————————————————————————————————————
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to