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

Jean Mahoney <jmahoney@amsl.com> Fri, 23 April 2021 16:20 UTC

Return-Path: <jmahoney@amsl.com>
X-Original-To: c310@rfc-editor.org
Delivered-To: c310@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 4E6A5F40782; Fri, 23 Apr 2021 09:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
X-Spam-Flag: NO
X-Spam-Score: -192.992
X-Spam-Level:
X-Spam-Status: No, score=-192.992 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.01, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=0.01, SPF_HELO_NONE=2, SPF_PASS=-0.001, SUBJECT_IN_WHITELIST=-100, T_FILL_THIS_FORM_SHORT=5, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0wN6PyvsK03; Fri, 23 Apr 2021 09:20:28 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) by rfc-editor.org (Postfix) with ESMTPS id 9DB5DF40775; Fri, 23 Apr 2021 09:20:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 4569838B4BD; Fri, 23 Apr 2021 09:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM8FSj8jHbCw; Fri, 23 Apr 2021 09:20:35 -0700 (PDT)
Received: from AMSs-MBP.localdomain (unknown [47.186.1.92]) by c8a.amsl.com (Postfix) with ESMTPSA id 9201D38B4BC; Fri, 23 Apr 2021 09:20:34 -0700 (PDT)
To: Simon Duquennoy <simon.duquennoy@gmail.com>, Xavi Vilajosana Guillen <xvilajosana@uoc.edu>
Cc: 6tisch-ads@ietf.org, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, 6tisch-chairs@ietf.org, Tengfei Chang <tengfei.chang@gmail.com>, c310@rfc-editor.org
References: <20210421064903.D13C4F40756@rfc-editor.org> <CAAdgstT4asOnH1TA9Hv4o1Md=z_TP49KkgOON_P=NBkPi7Md0Q@mail.gmail.com> <8cdd1222-50b2-13f9-275c-940563303199@amsl.com> <CAAdgstRTHx7_3CiASL2HFW0Etb44nrU9HV5Kdm8YDVoMNYSS5g@mail.gmail.com> <1ac3fc1e-232d-fba1-25df-af020b417b00@amsl.com> <CAAdgstS71nWSCD0Bi73O+gBR_EMeD8=_y=cxKib_qgd_6h+w3A@mail.gmail.com> <CAC9+vPiUCUhjGWV9nq9-NyH2Bos0=sWjUvqf5itj0a9X-xw9dg@mail.gmail.com> <181D95F6-DA63-4077-8D3D-437610413C69@gmail.com>
From: Jean Mahoney <jmahoney@amsl.com>
Message-ID: <76ded42a-7b55-4f52-203a-ebcdf9ede097@amsl.com>
Date: Fri, 23 Apr 2021 11:20:34 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <181D95F6-DA63-4077-8D3D-437610413C69@gmail.com>
Content-Type: multipart/alternative; boundary="------------CAB916545ABC47F6404A93BB"
Content-Language: en-US
Subject: Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC 9033 <draft-ietf-6tisch-msf-18.txt> NOW AVAILABLE
X-BeenThere: c310@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <c310.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/c310>, <mailto:c310-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/c310/>
List-Post: <mailto:c310@rfc-editor.org>
List-Help: <mailto:c310-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/c310>, <mailto:c310-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Apr 2021 16:20:33 -0000

Simon, Xavi, Tengfei,

Thank you for your responses. We have noted your approvals on the AUTH48 
status page:

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

As approvals are now complete, we will move this document forward in the 
publication process (along with the other documents in its cluster):

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

Best regards,

RFC Editor/jm


On 4/23/21 3:07 AM, Simon Duquennoy wrote:
> Dear Jean,
>
> I approve the document for publication in its current state.
>
> Best regards,
> Simon
>
>> On 23 Apr 2021, at 05:13, Xavi Vilajosana Guillen 
>> <xvilajosana@uoc.edu <mailto:xvilajosana@uoc.edu>> wrote:
>>
>> Dear Jean,
>>
>> I also approve the publication of this document in its current state.
>>
>> kind regards
>>
>> Missatge de Tengfei Chang <tengfei.chang@gmail.com 
>> <mailto:tengfei.chang@gmail.com>> del dia dv., 23 d’abr. 2021 a les 2:38:
>>
>>     Hi Jean,
>>
>>     It reads good for me and I state that:
>>
>>     I approve the publication of this document in its current state.
>>
>>     Tengfei
>>
>>     On Thu, Apr 22, 2021 at 11:53 PM Jean Mahoney <jmahoney@amsl.com
>>     <mailto:jmahoney@amsl.com>> 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
>>>         <jmahoney@amsl.com <mailto:jmahoney@amsl.com>> 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 tengfei.chang@inria.fr
>>>             <mailto:tengfei.chang@inria.fr>.
>>>
>>>
>>>         */TC: Thanks for pointing this out. The email will not be
>>>         available in a few months, could you change to
>>>         tengfei.chang@gmail.com <mailto:tengfei.chang@gmail.com> 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
>>>>             <rfc-editor@rfc-editor.org
>>>>             <mailto:rfc-editor@rfc-editor.org>> 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,
>>>>                 beshr@chalmers.se <mailto:beshr@chalmers.se>)
>>>>                    *  Olaf Landsiedel (Chalmers University,
>>>>                 olafl@chalmers.se <mailto:olafl@chalmers.se>)
>>>>                    *  Yasuyuki Tanaka (Inria-Paris,
>>>>                 yasuyuki.tanaka@inria.fr
>>>>                 <mailto:yasuyuki.tanaka@inria.fr>)
>>>>
>>>>                 Current:
>>>>                    Beshr Al Nahas
>>>>                    Chalmers University
>>>>
>>>>                    Email: beshr@chalmers.se <mailto:beshr@chalmers.se>
>>>>
>>>>
>>>>                    Olaf Landsiedel
>>>>                    Chalmers University
>>>>
>>>>                    Email: olafl@chalmers.se <mailto:olafl@chalmers.se>
>>>>
>>>>
>>>>                    Yasuyuki Tanaka
>>>>                    Inria-Paris
>>>>
>>>>                    Email: yasuyuki.tanaka@inria.fr
>>>>                 <mailto:yasuyuki.tanaka@inria.fr>
>>>>                 -->
>>>>
>>>>             */TC: This looks good! Also please update the following
>>>>             contact info/*
>>>>             */
>>>>             /*
>>>>
>>>>                     */OLD: /*
>>>>
>>>>                     */
>>>>                     /*
>>>>
>>>>                     */ Yasuyuki Tanaka
>>>>                        Inria-Paris
>>>>
>>>>                        Email: yasuyuki.tanaka@inria.fr
>>>>                     <mailto:yasuyuki.tanaka@inria.fr>
>>>>                     /*
>>>>
>>>>                     */
>>>>                     /*
>>>>
>>>>                     */NEW: /*
>>>>                     */
>>>>                     /*
>>>>
>>>>                     */   Yasuyuki Tanaka/*
>>>>
>>>>                     */   Toshiba/*
>>>>
>>>>                     */
>>>>                     /*
>>>>
>>>>                     */   Email: yatch1.tanaka@toshiba.co.jp
>>>>                     <mailto:yatch1.tanaka@toshiba.co.jp>/*
>>>>
>>>>
>>>>                 Thank you.
>>>>
>>>>                 RFC Editor/jm/ar
>>>>
>>>>
>>>>                 On Apr 20, 2021, rfc-editor@rfc-editor.org
>>>>                 <mailto:rfc-editor@rfc-editor.org> 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/>
>>>         ——————————————————————————————————————
>>
>>
>>
>>     -- 
>>     ——————————————————————————————————————
>>     Stay healthy, stay optimistic!
>>
>>     Dr. Tengfei, Chang
>>     Postdoctoral Research Engineer, Inria
>>
>>     www.tchang.org/ <http://www.tchang.org/>
>>     ——————————————————————————————————————
>>     -- 
>>     c310 mailing list
>>     c310@rfc-editor.org <mailto:c310@rfc-editor.org>
>>     https://www.rfc-editor.org/mailman/listinfo/c310
>>     <https://www.rfc-editor.org/mailman/listinfo/c310>
>>
>>
>>
>> -- 
>> Dr. Xavier Vilajosana
>> Wireless Networks Lab
>> /Internet Interdisciplinary Institute (IN3)
>> Professor/
>> (+34) 646 633 681
>> xvilajosana@uoc.edu <mailto:usuari@uoc.edu>
>> http://xvilajosana.org <http://xvilajosana.org/>
>> http://wine.rdi.uoc.edu <http://wine.rdi.uoc.edu/>
>> Parc Mediterrani de la Tecnologia
>> Av Carl Friedrich Gauss 5, B3 Building
>> 08860 Castelldefels (Barcelona). Catalonia. Spain
>>
>> Universitat Oberta de Catalunya
>> ­
>>
>> INFORMACIÓ SOBRE PROTECCIÓ DE DADES DE LA UNIVERSITAT OBERTA DE 
>> CATALUNYA (UOC)
>> Us informem que les vostres dades identificatives i les contingudes 
>> en els missatges electrònics i fitxers adjunts es poden incorporar a 
>> les nostres bases de dades amb la finalitat de gestionar les 
>> relacions i comunicacions vinculades a la UOC, i que es poden 
>> conservar mentre es mantingui la relació. Si ho voleu, podeu exercir 
>> el dret a accedir a les vostres dades, rectificar-les i suprimir-les 
>> i altres drets reconeguts normativament adreçant-vos a l'adreça de 
>> correu emissora o a fuoc_pd@uoc.edu <mailto:fuoc_pd@uoc.edu>.
>> Aquest missatge i qualsevol fitxer que porti adjunt, si escau, tenen 
>> el caràcter de confidencials i s'adrecen únicament a la persona o 
>> entitat a qui s'han enviat.
>> Així mateix, posem a la vostra disposició un delegat de protecció de 
>> dades que no només s'encarregarà de supervisar tots els tractaments 
>> de dades de la nostra entitat, sinó que us podrà atendre per a 
>> qualsevol qüestió relacionada amb el tractament de dades. La seva 
>> adreça de contacte és dpd@uoc.edu <mailto:dpd@uoc.edu>.
>> ------------------------------------------------------------------------
>> INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE LA UNIVERSITAT OBERTA DE 
>> CATALUNYA (UOC)
>> Os informamos de que vuestros datos identificativos y los contenidos 
>> en los mensajes electrónicos y ficheros adjuntos pueden incorporarse 
>> a nuestras bases de datos con el fin de gestionar las relaciones y 
>> comunicaciones vinculadas a la UOC, y de que pueden conservarse 
>> mientras se mantenga la relación. Si lo deseáis, podéis ejercer el 
>> derecho a acceder a vuestros datos, rectificarlos y suprimirlos y 
>> otros derechos reconocidos normativamente dirigiéndoos a la dirección 
>> de correo emisora o a fuoc_pd@uoc.edu <mailto:fuoc_pd@uoc.edu>.
>> Este mensaje y cualquier fichero que lleve adjunto, si procede, 
>> tienen el carácter de confidenciales y se dirigen únicamente a la 
>> persona o entidad a quien se han enviado.
>> Así mismo, ponemos a vuestra disposición a un delegado de protección 
>> de datos que no solo se encargará de supervisar todos los 
>> tratamientos de datos de nuestra entidad, sino que podrá atenderos 
>> para cualquier cuestión relacionada con el tratamiento de datos. Su 
>> dirección de contacto es dpd@uoc.edu <mailto:dpd@uoc.edu>.
>> ------------------------------------------------------------------------
>> UNIVERSITAT OBERTA DE CATALUNYA (UOC) DATA PROTECTION INFORMATION
>> Your personal data and the data contained in your email messages and 
>> attached files may be stored in our databases for the purpose of 
>> maintaining relations and communications linked to the UOC, and the 
>> data may be stored for as long as these relations and communications 
>> are maintained. If you so wish, you can exercise your rights to 
>> access, rectification and erasure of your data, and any other legally 
>> held rights, by writing to the sender’s email address or to 
>> fuoc_pd@uoc.edu <http://fuoc_pd@uoc.edu/>.
>> This message and, where applicable, any attachments are confidential 
>> and addressed solely to the individual or organization they were sent to.
>> The UOC has a data protection officer who not only supervises the 
>> data processing carried out at the University, but who will also 
>> respond to any questions you may have about this data processing. You 
>> can contact our data protection officer by writing to dpd@uoc.edu 
>> <http://dpd@uoc.edu/>.
>>
>> -- 
>> c310 mailing list
>> c310@rfc-editor.org <mailto:c310@rfc-editor.org>
>> https://www.rfc-editor.org/mailman/listinfo/c310
>