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

[Jean Mahoney <[e-mail]>]

Erik,

Thank you for your response. We have noted your approval on the AUTH48 
status page:

    https://www.rfc-editor.org/auth48/rfc9033

Best regards,

RFC Editor/jm

On 4/23/21 1:09 AM, Erik Kline wrote:
> Jean,
>
> Thanks for this (weirdly, many emails on this thread keep ending up in 
> my spam folder).
>
> I just reviewed rfc9033-auth48diff and everything looks good to me, 
> including this new paragraph.
>
> Thanks again!
>
> On Thu, Apr 22, 2021 at 8:53 AM Jean Mahoney <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>     <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.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-diff.html
>     <https://www.rfc-editor.org/authors/rfc9033-diff.html> (all changes)
>     https://www.rfc-editor.org/authors/rfc9033-auth48diff.html
>     <https://www.rfc-editor.org/authors/rfc9033-auth48diff.html> (all
>     AUTH48 changes)
>     https://www.rfc-editor.org/authors/rfc9033-lastdiff.html
>     <https://www.rfc-editor.org/authors/rfc9033-lastdiff.html> (these
>     changes)
>     https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html
>     <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/>
>>     ——————————————————————————————————————
>