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

[Jean Mahoney <[e-mail]>]

Tengfei, Pascal, and *AD (Erik),

* Erik, please review the newly added one-paragraph section in the 
Introduction (Section 1.2, Related Documents), and let us know if you 
approve of the addition.

NEW:

1.2.  Related Documents

    This specification uses messages and variables defined in IEEE Std
    802.15.4-2015 [IEEE802154].  It is expected that those resources will
    remain in the future versions of IEEE Std 802.15.4; in which case,
    this specification also applies to those future versions.  In the
    remainder of the document, we use [IEEE802154] to refer to IEEE Std
    802.15.4-2015 as well as future versions of IEEE Std 802.15.4 that
    remain compatible.

https://www.rfc-editor.org/authors/rfc9033.html#name-related-documents


Tengfei and Pascal, thank you for your responses. We have updated the 
document with your feedback:

    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-diff.html (all changes)
    https://www.rfc-editor.org/authors/rfc9033-auth48diff.html (all 
AUTH48 changes)
    https://www.rfc-editor.org/authors/rfc9033-lastdiff.html (these changes)
    https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html (these 
changes side by side)

We will await further word from you and your coauthors regarding other 
AUTH48 changes and/or approval.

Best regards,

RFC Editor/jm


On 4/21/21 10:15 PM, Tengfei Chang wrote:
> Hi Jean,
>
> I replied inline:
>
> On Thu, Apr 22, 2021 at 12:32 AM Jean Mahoney <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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.txt>
>     https://www.rfc-editor.org/authors/rfc9033.pdf
>     <https://www.rfc-editor.org/authors/rfc9033.pdf>
>     https://www.rfc-editor.org/authors/rfc9033.html
>     <https://www.rfc-editor.org/authors/rfc9033.html>
>     https://www.rfc-editor.org/authors/rfc9033.xml
>     <https://www.rfc-editor.org/authors/rfc9033.xml>
>     https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html
>     <https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html>
>     (these changes side by side)
>     https://www.rfc-editor.org/authors/rfc9033-auth48diff.html
>     <https://www.rfc-editor.org/authors/rfc9033-auth48diff.html>
>     (changes made during AUTH48)
>     https://www.rfc-editor.org/authors/rfc9033-diff.html
>     <https://www.rfc-editor.org/authors/rfc9033-diff.html> (all
>     changes made to the text)
>     https://www.rfc-editor.org/authors/rfc9033-xmldiff.html
>     <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]>.
>
>
> */TC: Thanks for pointing this out. The email will not be available in 
> a few months, could you change to [e-mail] 
> <mailto:[e-mail]> for me? Thanks! /*
>
>
>
>     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).
>
>
> */ TC: Yes, you may. /*
> */
> /*
>
>         */  OLD:/*
>
>         */   This specification defines the 6TiSCH Minimal Scheduling
>         Function/*
>
>         */   (MSF). /*
>
>         */
>         /*
>
>         */NEW:/*
>
>         */   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.
>
>
> */TC: Go to #2 is correct. Just to clarify, #2 indicates this 
> sentence: When the value of NumCellsElapsed reaches MAX_NUM_CELLS:/*
>
>         */  OLD:/*
>
>         */Reset both NumCellsElapsed and NumCellsUsed to 0 and go to/*
>
>     */          #2. /*
>
>     */
>     /*
>
>         */NEW:/*
>
>         */   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 ...
>
>
> */TC:  Yes, you may. I think the first choice is good. IEEE802154 
> already indicates it's for LR-WPANs./*
>
>         */  OLD:/*
>
>         */   If [IEEE802154] transmissions are observed .../*
>
>         */
>         /*
>
>         */NEW:/*
>
>         */   If transmissions that rely on [IEEE802154] are observed
>         ... /*
>
>
>
>     And one more question inline marked with [JM] --
>
> */
> /*
> */TC: Sorry I missed that one. The comment 6) also pointed to the same 
> sentence and my response is nearly the same as JM suggested :-) /*
> */Please use JM's suggestion here./*
>
>         */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 frame
>             per [IEEE802.15.4] is received by the node from its parent. /*
>
>
>
>     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/>
>>     ——————————————————————————————————————
>>
>
>
> -- 
> ——————————————————————————————————————
> Stay healthy, stay optimistic!
>
> Dr. Tengfei, Chang
> Postdoctoral Research Engineer, Inria
>
> www.tchang.org/ <http://www.tchang.org/>
> ——————————————————————————————————————