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

[Jean Mahoney <[e-mail]>]

Pascal,

On 4/21/21 4:47 AM, Pascal Thubert (pthubert) wrote:
> Dear all
>
> The IEEE reference  to IEEE Standard 802.15.4 I dated: DOI 10.1109/IEEESTD.2016.7460875, April 2016
> Usually we avoid that to enable the RFC over the family of IEEE standards as opposed to only the dated version, 2015 here.
> OTOH, this spec goes deeper than we normally do at the IETF in referencing IEEE std innards.
> So though unusual, maybe in this case the dated form is OK. Still I'd like to see text about that reference that expects compatibility with future 802.15.4 versions, something like:
> "
> It is the expected that the IEEE methods and variables that this specification utilizes will remain in the future versions of IEEE Std 802.15.4 [IEEE802154], in which case this specification also applies to those future versions.
> "

Where should we add this new text in the document?

Best regards,

RFC Editor/jm


> Keep safe;
>
> Pascal
>
>> -----Original Message-----
>> From: [e-mail] <[e-mail]>
>> Sent: mercredi 21 avril 2021 8:49
>> To: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Cc: [e-mail]; [e-mail]; 6tisch-
>> [e-mail]; Pascal Thubert (pthubert) <[e-mail]>; c310@rfc-
>> editor.org
>> Subject: Re: AUTH48 [JM]: RFC 9033 <draft-ietf-6tisch-msf-18.txt> NOW
>> AVAILABLE
>>
>> 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