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

["Prof. Diego Dujovne" <[e-mail]>]

Jean,
        I approve the document for publication in its current state.
Regards,

                          Diego Dujovne

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

> Mališa,
>
> Each author needs to explicitly state their approval before the document
> can move forward in the publication process.  We have noted your approval
> on the AUTH48 status page. Thank you!
>
>    https://www.rfc-editor.org/auth48/rfc9033
>
> Diego,
>
> We weren't sure if you were approving just the recent changes or
> officially approving the document for publication, so we have not yet noted
> it on the status page.
>
> Best regards,
>
> RFC Editor/jm
>
>
> On 4/22/21 3:28 PM, Mališa Vučinić wrote:
>
> 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]> <[e-mail]>
> on behalf of "Prof. Diego Dujovne" <[e-mail]>
> <[e-mail]>
> *Date: *Thursday 22 April 2021 at 19:01
> *To: *Jean Mahoney <[e-mail]> <[e-mail]>
> *Cc: *<[e-mail]> <[e-mail]>, <[e-mail]>
> <[e-mail]>, <[e-mail]> <[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]
> <[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/
>
> ——————————————————————————————————————
>
> --
> 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
>
>

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