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

[Mališa Vučinić <[e-mail]>]

I wasn’t sure if another co-author approval is needed to cover the latest changes, but in case it is, I approve the publication of this document in its current state.

 

Mališa

 

From: c310 <[e-mail]> on behalf of "Prof. Diego Dujovne" <[e-mail]>
Date: Thursday 22 April 2021 at 19:01
To: Jean Mahoney <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC 9033 <draft-ietf-6tisch-msf-18.txt> NOW AVAILABLE

 

Dear all,

               I agree with the former changes.

Regards,

 

                              Diego Dujovne

 

Le jeu. 22 avr. 2021 à 11:53, Jean Mahoney <[e-mail]> a écrit :

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

 

NEW: 

 

   Yasuyuki Tanaka

   Toshiba

 

   Email: [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/

——————————————————————————————————————

-- 
c310 mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/c310


 

-- 

DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

-- c310 mailing list [e-mail] https://www.rfc-editor.org/mailman/listinfo/c310