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

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

Dear all,
               I have reviewed the changes and I agree on them. As Malisa
said, the remainig items can be solved by Tengfei.
Regards,

           Diego Dujovne

El mié., 21 de abril de 2021 04:11, Mališa Vučinić <[e-mail]>
escribió:

> Hello,
>
> I went through the text and I have no further changes to make.
>
> Regarding point (2) below, please use the UTF-8 version of my name for all
> the documents in this cluster: Mališa Vučinić. I believe Tengfei will
> resolve the remaining issues.
>
> Thank you.
>
> Mališa
>
> On 21/04/2021 08:49, "[e-mail]" <
> [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?
>     -->
>
>
>     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
>     -->
>
>
>     3) <!-- [rfced] Please insert any keywords (beyond those that appear
>     in the title) for use on https://www.rfc-editor.org/search.
>     -->
>
>
>     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.
>     -->
>
>
>     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.
>     -->
>
>
>     6) <!-- [rfced] Please consider rephrasing to make this more precise.
>     -->
>
>
>     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.
>     -->
>
>
>     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
>     -->
>
>
>     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>.
>     -->
>
>
>     10) <!-- [rfced]  In the appendix, the term "mote" is used instead of
> "node".
>     Is this intentional?
>     -->
>
>
>     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]
>     -->
>
>
>     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
>
>
>