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

[Tengfei Chang <[e-mail]>]

Hi Jean,

I replied inline:

On Thu, Apr 22, 2021 at 12:32 AM Jean Mahoney <[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.pdf
>    https://www.rfc-editor.org/authors/rfc9033.html
>    https://www.rfc-editor.org/authors/rfc9033.xml
>    https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html (these
> changes side by side)
>    https://www.rfc-editor.org/authors/rfc9033-auth48diff.html (changes
> made during AUTH48)
>    https://www.rfc-editor.org/authors/rfc9033-diff.html (all changes made
> to the text)
>    https://www.rfc-editor.org/authors/rfc9033-xmldiff.html (all changes
> made to the XML)
>
>
> Tengfei, would you like to update your email address in the document? It
> is currently [e-mail].
>

*TC: Thanks for pointing this out. The email will not be available in a few
months, could you change to [e-mail]
<[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]> 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. *
>
>
>> [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/>.
>>
>> 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/
> ——————————————————————————————————————
>
>

-- 
——————————————————————————————————————
Stay healthy, stay optimistic!

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——————————————————————————————————————