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

[Erik Kline <[e-mail]>]

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]> 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
>
>
> Tengfei and Pascal, thank you for your responses. We have updated the
> document with your feedback:
>
>    https://www.rfc-editor.org/authors/rfc9033.txt
>    https://www.rfc-editor.org/authors/rfc9033.pdf
>    https://www.rfc-editor.org/authors/rfc9033.html
>    https://www.rfc-editor.org/authors/rfc9033.xml
>    https://www.rfc-editor.org/authors/rfc9033-diff.html (all changes)
>    https://www.rfc-editor.org/authors/rfc9033-auth48diff.html (all AUTH48
> changes)
>    https://www.rfc-editor.org/authors/rfc9033-lastdiff.html (these
> changes)
>    https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html (these
> changes side by side)
>
> We will await further word from you and your coauthors regarding other
> AUTH48 changes and/or approval.
>
> Best regards,
>
> RFC Editor/jm
>
>
> On 4/21/21 10:15 PM, Tengfei Chang wrote:
>
> Hi Jean,
>
> I replied inline:
>
> On Thu, Apr 22, 2021 at 12:32 AM Jean Mahoney <[e-mail]> 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/
> ——————————————————————————————————————
>
>