Re: [C310] AUTH48 [JM]: RFC 9033 <draft-ietf-6tisch-msf-18.txt> NOW AVAILABLE

[Jean Mahoney <[e-mail]>]

Tengfei, Mališa, Diego, Xavi, and Pascal,

Thank you for your quick responses! We have updated the document based 
on your feedback, and we have a few more questions below:

    https://www.rfc-editor.org/authors/rfc9033.txt
    https://www.rfc-editor.org/authors/rfc9033.pdf
    https://www.rfc-editor.org/authors/rfc9033.html
    https://www.rfc-editor.org/authors/rfc9033.xml
    https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html (these 
changes side by side)
    https://www.rfc-editor.org/authors/rfc9033-auth48diff.html (changes 
made during AUTH48)
    https://www.rfc-editor.org/authors/rfc9033-diff.html (all changes 
made to the text)
    https://www.rfc-editor.org/authors/rfc9033-xmldiff.html (all changes 
made to the XML)


Tengfei, would you like to update your email address in the document? It 
is currently [e-mail] <mailto:[e-mail]>.


May we expand the 6TiSCH acronym in the abstract?

Current:
    This specification defines the 6TiSCH Minimal Scheduling Function
    (MSF).

Perhaps:
    This specification defines the "IPv6 over the TSCH mode of
    IEEE 802.15.4e" (6TiSCH) Minimal Scheduling Function (MSF).


In Section 5.1, the hyperlinked "Step 2" in the following sentence goes 
to numbered item "2.  When the value of NumCellsElapsed reaches 
MAX_NUM_CELLS:"

        *  Reset both NumCellsElapsed and NumCellsUsed to 0 and go to
           Step 2.

Should it instead go to Section 4.3 ("Step 2 - Receiving EBs")? If the 
link is correct (go to #2), then perhaps it should be
rephrased as "restart #2"?

        *  Reset both NumCellsElapsed and NumCellsUsed to 0 and restart
           #2.


May we move the following citation tag in Section 8 to improve readability?

Current:
    If [IEEE802154] transmissions are observed ...

Perhaps:
    If transmissions that rely on [IEEE802154] are observed ... or
    If transmissions that rely on LR-WPANs [IEEE802154] are observed ...


And one more question inline marked with [JM] --


On 4/21/21 4:15 AM, Tengfei Chang wrote:
> Dear all,
>
> Thanks for the quick responses!
>
> Dear RFC editor,
>
> Thanks for editing the document!
> I have response each questions inline below starting with */TC: (in/* 
> */bold and Italic) /*
> */
> /*
> Please let me know if there are any further questions regarding to the 
> document.
> Thanks!
>
> Tengfei
>
> On Wed, Apr 21, 2021 at 2:49 PM <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Authors,
>
>     While reviewing this document during AUTH48, please resolve (as
>     necessary) the following questions, which are also in the XML file.
>
>     1) <!-- [rfced] We note that the sortRefs attribute is missing in
>     rfc element. Would you like the citations in the References sorted
>     alphabetically or by first use in the document?
>     -->
>
> */ TC: We would like the citations in the References sorted 
> alphabetically. Thanks!/*
>
>
>     2) <!--[rfced] Mališa, do you prefer that your name appear as
>     "Malisa Vucinic" or "Mališa Vučinić" in this document (and other
>     documents in this cluster)? We note the latter appears on this page:
>     https://datatracker.ietf.org/person/Mali%C5%A1a%20Vu%C4%8Dini%C4%87
>     <https://datatracker.ietf.org/person/Mali%C5%A1a%20Vu%C4%8Dini%C4%87>
>     -->
>
> */ TC: please refer to Malisa's response./*
>
>
>     3) <!-- [rfced] Please insert any keywords (beyond those that appear
>     in the title) for use on https://www.rfc-editor.org/search
>     <https://www.rfc-editor.org/search>.
>     -->
>
> */ TC: please insert the following keywords, thanks!/*
> */
> /*
>
>         */TSCH, communication schedule, 6P/*
>
>
>     4) <!-- [rfced] Does the following improve the readability of
>      the sentence?
>
>     Current:
>        In case of a slot to transmit or receive, a channel is
>        assigned to the time slot.
>
>     Perhaps:
>        For time slots for transmitting or receiving, a channel is
>        assigned to the time slot.
>     -->
>
> */TC: Yes, please use the rephrased sentence: /*
> */
> /*
>
>         */OLD:/*
>
>         */   In case of a slot to transmit or receive, a channel is/*
>
>         */   assigned to the time slot. /*
>
>         */
>         /*
>
>         */NEW:/*
>
>         */   For time slots for transmitting or receiving, a channel is/*
>
>         */   assigned to the time slot. /*
>
>
>     5) <!-- [rfced]  We are having difficulty parsing the following:
>
>     Current:
>        For interoperability purposes, the values of those parameters
>        can be referred from Appendix A.
>
>     Purhaps:
>        For interoperability purposes, Appendix A provides guidance
>        on calculating the values of those parameters.
>     -->
>
> /*TC: Please apply the following changes. The parameters' values are 
> not calculated but arbitrary values, which are defined in Appendix A. */
> /*So that two different implementations of MSF can interoperate by 
> agreeing on same parameters values.*/
>
>         /*
>         */
>
>         /*OLD:*/
>
>         /*   For interoperability purposes, the values of those
>         parameters */
>
>         /*   can be referred from Appendix A.*/
>
>         /*
>         */
>
>         /*NEW:*/
>
>         /*   For interoperability purposes, Appendix A provides the
>         reference values of those parameters. */
>
>
>     6) <!-- [rfced] Please consider rephrasing to make this more precise.
>     -->
>
> */TC: It's rephrased as following./*
>
>         */OLD: /*
>
> */                                The node receives a valid frame from 
> the parent.
>                                 The counter increments only when the 
> frame is a valid [IEEE802.15.4] frame.
> /*
>
>         */NEW:/*
>
>             */The counter increments, only when a valid [IEEE802.15.4]
>             frame is received by the node form its parent. /*
>
>
[JM]  We have incorporated the new text but have moved the citation tag 
to improve readability. Please let us know if any other changes are 
necessary.

    The counter increments only when a valid frame per [IEEE802154]
    is received by the node from its parent.


Best regards,

RFC Editor/jm


>     7) <!-- [rfced] We are having difficulty parsing this passage.
>     Specifically, may the first sentence be rephrased as follows?
>     And, in the later sentence, should "absolved" be "alleviated"?
>
>     Current:
>        The 6P traffic overhead using a larger value of MAX_NUM_CELLS
>     could
>        be reduced as well... The latency caused by slight changes of
>     traffic
>        load can be absolved by the additional scheduled cells.
>
>     Perhaps:
>        By using a larger value of MAX_NUM_CELLS, the 6P traffic
>     overhead could
>        be reduced as well... The latency caused by slight changes of
>     traffic
>        load can be alleviated by the additional scheduled cells.
>     -->
>
> /*TC: The suggested sentence read good.*/
> /*
> */
>
>         /*  OLD:*/
>
>         /*   The 6P traffic overhead using a larger value of
>         MAX_NUM_CELLS could */
>
>         /*   be reduced as well... The latency caused by slight
>         changes of traffic */
>
>         /*   load can be absolved by the additional scheduled cells.*/
>
>         /*
>         */
>
>         /*NEW:*/
>
>         /*   By using a larger value of MAX_NUM_CELLS, the 6P traffic
>         overhead could */
>
>         /*   be reduced as well... The latency caused by slight
>         changes of traffic */
>
>         /*   load can be alleviated by the additional scheduled cells. */
>
>
>     8) <!-- [rfced]  FYI, we have applied superscript formatting to
>     the following.
>     Please let us know if you would like to add a space on either side
>     of the
>     operators to improve readability.
>
>     Current:
>        ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH
>
>     Perhaps:
>        ((2^MAXBE) - 1) * MAXRETRIES * SLOTFRAME_LENGTH
>     -->
>
> /*TC: We prefer add a space on */ */either side /*/* of the operators 
> to improve readability.*/
>
>         /*
>         */
>
>         /*OLD:*/
>
>         /*  ((2^MAXBE)-1)*MAXRETRIES*SLOTFRAME_LENGTH */
>
>         /*
>         */
>
>         /*NEW: */
>
>         /*((2^MAXBE) - 1) * MAXRETRIES * SLOTFRAME_LENGTH */
>
>
>     9) <!--[rfced] FYI, we have updated this reference as follows, as
>     the DOI
>     provided in the original is not functional, and it seems your
>     intention
>     was to refer to IEEE 802.15.4-2015. (Please note that it was
>     "Superseded by IEEE Std 802.15.4-2020" as detailed at the provided
>     URL.)
>
>     Please review and let us know any updates; we will follow up
>     on this topic as this reference appears in several documents
>     in this cluster (C310).
>
>     Original:
>        [IEEE802154]
>                   IEEE standard for Information Technology, "IEEE Std
>                   802.15.4 Standard for Low-Rate Wireless Personal Area
>                   Networks (WPANs)", DOI 10.1109/IEEE P802.15.4-REVd/D01,
>                   <http://ieeexplore.ieee.org/document/7460875/
>     <http://ieeexplore.ieee.org/document/7460875/>>.
>
>     Current:
>        [IEEE802154]
>                   IEEE, "IEEE Standard for Low-Rate Wireless
>     Networks", IEEE
>                   Standard 802.15.4-2015, DOI
>     10.1109/IEEESTD.2016.7460875,
>                   April 2016,
>                   <https://ieeexplore.ieee.org/document/7460875
>     <https://ieeexplore.ieee.org/document/7460875>>.
>     -->
>
> /*TC: Thanks for updating the link. We prefer to use the IEEE 
> 802.15.4-2015, which are referred during developing MSF.*/
>
>
>     10) <!-- [rfced]  In the appendix, the term "mote" is used instead
>     of "node".
>     Is this intentional?
>     -->
>
> /*TC: No. Please replace "mote" by "node".*/
> /*
> */
>
>         /*OLD: */
>
>         /*String s is replaced by the mote EUI-64 address. The
>         characters of the string, c0 through c7, are the eight bytes
>         of the EUI-64 address.*/
>
>         /*NEW: */
>
>         /*String s is replaced by the node EUI-64 address. The
>         characters of the string, c0 through c7, are the eight bytes
>         of the EUI-64 address.*/
>
>         /*
>         */
>
>         /*OLD: */
>
>         /*The appropriate values of l_bit and r_bit could vary
>         depending on the set of motes' EUI-64 address.*/
>
>         /*NEW: */
>
>         /*The appropriate values of l_bit and r_bit could vary
>         depending on the set of nodes' EUI-64 address.*/
>
>
>     11) <!-- [rfced] FYI, we have updated the formatting of the
>     Contributors
>     section to use <contact/> elements:
>
>     Original:
>        *  Beshr Al Nahas (Chalmers University, [e-mail]
>     <mailto:[e-mail]>)
>        *  Olaf Landsiedel (Chalmers University, [e-mail]
>     <mailto:[e-mail]>)
>        *  Yasuyuki Tanaka (Inria-Paris, [e-mail]
>     <mailto:[e-mail]>)
>
>     Current:
>        Beshr Al Nahas
>        Chalmers University
>
>        Email: [e-mail] <mailto:[e-mail]>
>
>
>        Olaf Landsiedel
>        Chalmers University
>
>        Email: [e-mail] <mailto:[e-mail]>
>
>
>        Yasuyuki Tanaka
>        Inria-Paris
>
>        Email: [e-mail] <mailto:[e-mail]>
>     -->
>
> */TC: This looks good! Also please update the following contact info/*
> */
> /*
>
>         */OLD: /*
>
>         */
>         /*
>
>         */   Yasuyuki Tanaka
>            Inria-Paris
>
>            Email: [e-mail]
>         <mailto:[e-mail]>
>         /*
>
>         */
>         /*
>
>         */NEW: /*
>         */
>         /*
>
>         */   Yasuyuki Tanaka/*
>
>         */   Toshiba/*
>
>         */
>         /*
>
>         */   Email: [e-mail]
>         <mailto:[e-mail]>/*
>
>
>     Thank you.
>
>     RFC Editor/jm/ar
>
>
>     On Apr 20, 2021, [e-mail]
>     <mailto:[e-mail]> wrote:
>
>     *****IMPORTANT*****
>
>     Updated 2021/04/20
>
>     RFC Author(s):
>     --------------
>
>     Instructions for Completing AUTH48
>
>     Your document has now entered AUTH48.  Once it has been reviewed and
>     approved by you and all coauthors, it will be published as an RFC.
>     If an author is no longer available, there are several remedies
>     available as listed in the FAQ (https://www.rfc-editor.org/faq/
>     <https://www.rfc-editor.org/faq/>).
>
>     You and you coauthors are responsible for engaging other parties
>     (e.g., Contributors or Working Group) as necessary before providing
>     your approval.
>
>     Planning your review
>     ---------------------
>
>     Please review the following aspects of your document:
>
>     *  RFC Editor questions
>
>       Please review and resolve any questions raised by the RFC Editor
>       that have been included in the XML file as comments marked as
>       follows:
>
>       <!-- [rfced] ... -->
>
>       These questions will also be sent in a subsequent email.
>
>     *  Changes submitted by coauthors
>
>       Please ensure that you review any changes submitted by your
>       coauthors.  We assume that if you do not speak up that you
>       agree to changes submitted by your coauthors.
>
>     *  Content
>
>       Please review the full content of the document, as this cannot
>       change once the RFC is published. Please pay particular
>     attention to:
>       - IANA considerations updates (if applicable)
>       - contact information
>       - references
>
>     *  Copyright notices and legends
>
>       Please review the copyright notice and legends as defined in
>       RFC 5378 and the Trust Legal Provisions
>       (TLP – https://trustee.ietf.org/license-info/
>     <https://trustee.ietf.org/license-info/>).
>
>     *  Semantic markup
>
>       Please review the markup in the XML file to ensure that elements of
>       content are correctly tagged.  For example, ensure that
>     <sourcecode>
>       and <artwork> are set correctly.  See details at
>       <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html
>     <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>>.
>
>     *  Formatted output
>
>       Please review the PDF, HTML, and TXT files to ensure that the
>       formatted output, as generated from the markup in the XML file, is
>       reasonable.  Please note that the TXT will have formatting
>       limitations compared to the PDF and HTML.
>
>
>     Submitting changes
>     ------------------
>
>     To submit changes, please reply to this email with one of the
>     following,
>     using ‘REPLY ALL’ as all the parties CC’ed on this message need to
>     see
>     your changes:
>
>     An update to the provided XML file
>     — OR —
>     An explicit list of changes in this format
>
>     Section # (or indicate Global)
>
>     OLD:
>     old text
>
>     NEW:
>     new text
>
>     You do not need to reply with both an updated XML file and an
>     explicit
>     list of changes, as either form is sufficient.
>
>     We will ask a stream manager to review and approve any changes
>     that seem
>     beyond editorial in nature, e.g., addition of new text, deletion
>     of text,
>     and technical changes.  Information about stream managers can be
>     found in
>     the FAQ.  Editorial changes do not require approval from a stream
>     manager.
>
>
>     Approving for publication
>     --------------------------
>
>     To approve your RFC for publication, please reply to this email s
>     tating that you approve this RFC for publication.  Please use
>     ‘REPLY ALL’
>     as all the parties CC’ed on this message need to see your approval.
>
>
>     Files
>     -----
>
>     The files are available here:
>     https://www.rfc-editor.org/authors/rfc9033.xml
>     <https://www.rfc-editor.org/authors/rfc9033.xml>
>     https://www.rfc-editor.org/authors/rfc9033.html
>     <https://www.rfc-editor.org/authors/rfc9033.html>
>     https://www.rfc-editor.org/authors/rfc9033.pdf
>     <https://www.rfc-editor.org/authors/rfc9033.pdf>
>     https://www.rfc-editor.org/authors/rfc9033.txt
>     <https://www.rfc-editor.org/authors/rfc9033.txt>
>
>     Diff file of the text:
>     https://www.rfc-editor.org/authors/rfc9033-diff.html
>     <https://www.rfc-editor.org/authors/rfc9033-diff.html>
>
>     Diff of the XML:
>     https://www.rfc-editor.org/authors/rfc9033-xmldiff.html
>     <https://www.rfc-editor.org/authors/rfc9033-xmldiff.html>
>
>     Tracking progress
>     -----------------
>
>     The details of the AUTH48 status of your document are here:
>     https://www.rfc-editor.org/auth48/rfc9033
>     <https://www.rfc-editor.org/auth48/rfc9033>
>
>     Please let us know if you have any questions.
>
>     Thank you for your cooperation,
>
>     RFC Editor
>
>     --------------------------------------
>     RFC9033 (draft-ietf-6tisch-msf-18)
>
>     Title            : 6TiSCH Minimal Scheduling Function (MSF)
>     Author(s)        : T. Chang, Ed., M. Vucinic, X. Vilajosana, S.
>     Duquennoy, D. Dujovne
>     WG Chair(s)      : Pascal Thubert, Thomas Watteyne
>     Area Director(s) : Erik Kline, Éric Vyncke
>
>
>
> -- 
> ——————————————————————————————————————
> Stay healthy, stay optimistic!
>
> Dr. Tengfei, Chang
> Postdoctoral Research Engineer, Inria
>
> www.tchang.org/ <http://www.tchang.org/>
> ——————————————————————————————————————
>