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

[Tengfei Chang <[e-mail]>]

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]> 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
> -->
>
> * 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.
> -->
>
> * 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. *


> 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/>.
>
> 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>.
> -->
>
> *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])
>    *  Olaf Landsiedel (Chalmers University, [e-mail])
>    *  Yasuyuki Tanaka (Inria-Paris, [e-mail])
>
> Current:
>    Beshr Al Nahas
>    Chalmers University
>
>    Email: [e-mail]
>
>
>    Olaf Landsiedel
>    Chalmers University
>
>    Email: [e-mail]
>
>
>    Yasuyuki Tanaka
>    Inria-Paris
>
>    Email: [e-mail]
> -->
>
> *TC: This looks good! Also please update the following contact info*

*OLD: *






*   Yasuyuki Tanaka    Inria-Paris    Email: [e-mail]
<[e-mail]>*


*NEW: *

*   Yasuyuki Tanaka*

*   Toshiba*


*    Email: [e-mail] <[e-mail]>*


> Thank you.
>
> RFC Editor/jm/ar
>
>
> On Apr 20, 2021, [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/).
>
> 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/).
>
> *  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>.
>
> *  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.html
>   https://www.rfc-editor.org/authors/rfc9033.pdf
>   https://www.rfc-editor.org/authors/rfc9033.txt
>
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9033-diff.html
>
> Diff of the XML:
>   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
>
> 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/
——————————————————————————————————————