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

[Jean Mahoney <[e-mail]>]

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]> 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] 
> <mailto:[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
>     <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.txt>
>     https://www.rfc-editor.org/authors/rfc9033.pdf
>     <https://www.rfc-editor.org/authors/rfc9033.pdf>
>     https://www.rfc-editor.org/authors/rfc9033.html
>     <https://www.rfc-editor.org/authors/rfc9033.html>
>     https://www.rfc-editor.org/authors/rfc9033.xml
>     <https://www.rfc-editor.org/authors/rfc9033.xml>
>     https://www.rfc-editor.org/authors/rfc9033-diff.html
>     <https://www.rfc-editor.org/authors/rfc9033-diff.html> (all changes)
>     https://www.rfc-editor.org/authors/rfc9033-auth48diff.html
>     <https://www.rfc-editor.org/authors/rfc9033-auth48diff.html> (all
>     AUTH48 changes)
>     https://www.rfc-editor.org/authors/rfc9033-lastdiff.html
>     <https://www.rfc-editor.org/authors/rfc9033-lastdiff.html> (these
>     changes)
>     https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html
>     <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] <mailto:[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.txt>
>             https://www.rfc-editor.org/authors/rfc9033.pdf
>             <https://www.rfc-editor.org/authors/rfc9033.pdf>
>             https://www.rfc-editor.org/authors/rfc9033.html
>             <https://www.rfc-editor.org/authors/rfc9033.html>
>             https://www.rfc-editor.org/authors/rfc9033.xml
>             <https://www.rfc-editor.org/authors/rfc9033.xml>
>             https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html
>             <https://www.rfc-editor.org/authors/rfc9033-lastrfcdiff.html>
>             (these changes side by side)
>             https://www.rfc-editor.org/authors/rfc9033-auth48diff.html
>             <https://www.rfc-editor.org/authors/rfc9033-auth48diff.html>
>             (changes made during AUTH48)
>             https://www.rfc-editor.org/authors/rfc9033-diff.html
>             <https://www.rfc-editor.org/authors/rfc9033-diff.html>
>             (all changes made to the text)
>             https://www.rfc-editor.org/authors/rfc9033-xmldiff.html
>             <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]
>             <mailto:[e-mail]>.
>
>         */TC: Thanks for pointing this out. The email will not be
>         available in a few months, could you change to
>         [e-mail] <mailto:[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]
>                 <mailto:[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
>                     <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
>                     <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/
>                     <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
>                     <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] <mailto:[e-mail]>)
>                        *  Olaf Landsiedel (Chalmers University,
>                     [e-mail] <mailto:[e-mail]>)
>                        *  Yasuyuki Tanaka (Inria-Paris,
>                     [e-mail]
>                     <mailto:[e-mail]>)
>
>                     Current:
>                        Beshr Al Nahas
>                        Chalmers University
>
>                        Email: [e-mail] <mailto:[e-mail]>
>
>
>                        Olaf Landsiedel
>                        Chalmers University
>
>                        Email: [e-mail] <mailto:[e-mail]>
>
>
>                        Yasuyuki Tanaka
>                        Inria-Paris
>
>                        Email: [e-mail]
>                     <mailto:[e-mail]>
>                     -->
>
>                 */TC: This looks good! Also please update the
>                 following contact info/*
>
>                         */OLD: /*
>
>                         */ Yasuyuki Tanaka
>                            Inria-Paris
>
>                            Email: [e-mail]
>                         <mailto:[e-mail]>/*
>
>                         */NEW: /*
>
>                         */ Yasuyuki Tanaka/*
>
>                         */ Toshiba/*
>
>                         */ Email: [e-mail]
>                         <mailto:[e-mail]>/*
>
>
>                     Thank you.
>
>                     RFC Editor/jm/ar
>
>
>                     On Apr 20, 2021, [e-mail]
>                     <mailto:[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/
>                     <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/
>                     <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
>                     <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.xml>
>                     https://www.rfc-editor.org/authors/rfc9033.html
>                     <https://www.rfc-editor.org/authors/rfc9033.html>
>                     https://www.rfc-editor.org/authors/rfc9033.pdf
>                     <https://www.rfc-editor.org/authors/rfc9033.pdf>
>                     https://www.rfc-editor.org/authors/rfc9033.txt
>                     <https://www.rfc-editor.org/authors/rfc9033.txt>
>
>                     Diff file of the text:
>                     https://www.rfc-editor.org/authors/rfc9033-diff.html
>                     <https://www.rfc-editor.org/authors/rfc9033-diff.html>
>
>                     Diff of the XML:
>                     https://www.rfc-editor.org/authors/rfc9033-xmldiff.html
>                     <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
>                     <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/ <http://www.tchang.org/>
>
>                 ——————————————————————————————————————
>
>
>
>
>         -- 
>
>         ——————————————————————————————————————
>
>         Stay healthy, stay optimistic!
>
>         Dr. Tengfei, Chang
>
>         Postdoctoral Research Engineer, Inria
>
>         www.tchang.org/ <http://www.tchang.org/>
>
>         ——————————————————————————————————————
>
>     -- 
>     c310 mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.rfc-editor.org/mailman/listinfo/c310
>     <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 <http://www.ingenieria.udp.cl>
> (56 2) 676 8125
>
> -- c310 mailing list [e-mail] 
> https://www.rfc-editor.org/mailman/listinfo/c310
>