Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC 9033 <draft-ietf-6tisch-msf-18.txt> NOW AVAILABLE
Jean Mahoney <jmahoney@amsl.com> Thu, 22 April 2021 22:15 UTC
Return-Path: <jmahoney@amsl.com>
X-Original-To: c310@rfc-editor.org
Delivered-To: c310@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 85BD1F407C7; Thu, 22 Apr 2021 15:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
X-Spam-Flag: NO
X-Spam-Score: -192.991
X-Spam-Level:
X-Spam-Status: No, score=-192.991 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.01, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=0.01, SPF_HELO_NONE=2, SPF_PASS=-0.001, SUBJECT_IN_WHITELIST=-100, T_FILL_THIS_FORM_SHORT=5, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkyoLb_oIg9i; Thu, 22 Apr 2021 15:15:30 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) by rfc-editor.org (Postfix) with ESMTPS id C22F6F407C4; Thu, 22 Apr 2021 15:15:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 66BFC389EE7; Thu, 22 Apr 2021 15:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oude8N_VbT4z; Thu, 22 Apr 2021 15:15:36 -0700 (PDT)
Received: from AMSs-MBP.localdomain (unknown [47.186.1.92]) by c8a.amsl.com (Postfix) with ESMTPSA id BEF29389867; Thu, 22 Apr 2021 15:15:35 -0700 (PDT)
To: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
Cc: Mališa Vučinić <malisa.vucinic@inria.fr>, 6tisch-ads@ietf.org, c310@rfc-editor.org, 6tisch-chairs@ietf.org, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>
References: <20210421064903.D13C4F40756@rfc-editor.org> <CAAdgstT4asOnH1TA9Hv4o1Md=z_TP49KkgOON_P=NBkPi7Md0Q@mail.gmail.com> <8cdd1222-50b2-13f9-275c-940563303199@amsl.com> <CAAdgstRTHx7_3CiASL2HFW0Etb44nrU9HV5Kdm8YDVoMNYSS5g@mail.gmail.com> <1ac3fc1e-232d-fba1-25df-af020b417b00@amsl.com> <CAH7SZV-MFHfa0w0ERvXKXuNFs6fBZEp1t35gyyDTPXZGKiUiBA@mail.gmail.com> <4E80E284-0BC6-43F6-AA15-CE693DD820ED@inria.fr> <eb79a567-0bc7-37fd-eca3-1cfc48dcc557@amsl.com> <CAH7SZV8ZZmKjBc7jqvbwwthFGUNOHRPvLJgubNNAteWwPdMydA@mail.gmail.com>
From: Jean Mahoney <jmahoney@amsl.com>
Message-ID: <698cc09f-a857-260f-8fdb-1b3dc3232e3c@amsl.com>
Date: Thu, 22 Apr 2021 17:15:35 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <CAH7SZV8ZZmKjBc7jqvbwwthFGUNOHRPvLJgubNNAteWwPdMydA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A17F486E6BFAEA5447252D30"
Content-Language: en-US
Subject: Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC 9033 <draft-ietf-6tisch-msf-18.txt> NOW AVAILABLE
X-BeenThere: c310@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <c310.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/c310>, <mailto:c310-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/c310/>
List-Post: <mailto:c310@rfc-editor.org>
List-Help: <mailto:c310-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/c310>, <mailto:c310-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2021 22:15:35 -0000
Diego, Thank you! We have noted your approval on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9033 Best regards, RFC Editor/jm On 4/22/21 4:53 PM, Prof. Diego Dujovne wrote: > Jean, > I approve the document for publication in its current state. > Regards, > > Diego Dujovne > > Le jeu. 22 avr. 2021 à 17:37, Jean Mahoney <jmahoney@amsl.com > <mailto:jmahoney@amsl.com>> 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 > <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 <c310-bounces@rfc-editor.org> >> <mailto:c310-bounces@rfc-editor.org> on behalf of "Prof. Diego >> Dujovne" <diego.dujovne@mail.udp.cl> >> <mailto:diego.dujovne@mail.udp.cl> >> *Date: *Thursday 22 April 2021 at 19:01 >> *To: *Jean Mahoney <jmahoney@amsl.com> <mailto:jmahoney@amsl.com> >> *Cc: *<6tisch-ads@ietf.org> <mailto:6tisch-ads@ietf.org>, >> <c310@rfc-editor.org> <mailto:c310@rfc-editor.org>, >> <6tisch-chairs@ietf.org> <mailto:6tisch-chairs@ietf.org>, >> "rfc-editor@rfc-editor.org" <mailto:rfc-editor@rfc-editor.org> >> <rfc-editor@rfc-editor.org> <mailto:rfc-editor@rfc-editor.org> >> *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 <jmahoney@amsl.com >> <mailto:jmahoney@amsl.com>> 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 >> <jmahoney@amsl.com <mailto:jmahoney@amsl.com>> 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 >> tengfei.chang@inria.fr <mailto:tengfei.chang@inria.fr>. >> >> */TC: Thanks for pointing this out. The email will not be >> available in a few months, could you change to >> tengfei.chang@gmail.com <mailto:tengfei.chang@gmail.com> >> 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 >> <rfc-editor@rfc-editor.org >> <mailto:rfc-editor@rfc-editor.org>> 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, >> beshr@chalmers.se <mailto:beshr@chalmers.se>) >> * Olaf Landsiedel (Chalmers University, >> olafl@chalmers.se <mailto:olafl@chalmers.se>) >> * Yasuyuki Tanaka (Inria-Paris, >> yasuyuki.tanaka@inria.fr >> <mailto:yasuyuki.tanaka@inria.fr>) >> >> Current: >> Beshr Al Nahas >> Chalmers University >> >> Email: beshr@chalmers.se >> <mailto:beshr@chalmers.se> >> >> >> Olaf Landsiedel >> Chalmers University >> >> Email: olafl@chalmers.se >> <mailto:olafl@chalmers.se> >> >> >> Yasuyuki Tanaka >> Inria-Paris >> >> Email: yasuyuki.tanaka@inria.fr >> <mailto:yasuyuki.tanaka@inria.fr> >> --> >> >> */TC: This looks good! Also please update the >> following contact info/* >> >> */OLD: /* >> >> */ Yasuyuki Tanaka >> Inria-Paris >> >> Email: yasuyuki.tanaka@inria.fr >> <mailto:yasuyuki.tanaka@inria.fr>/* >> >> */NEW: /* >> >> */ Yasuyuki Tanaka/* >> >> */ Toshiba/* >> >> */ Email: yatch1.tanaka@toshiba.co.jp >> <mailto:yatch1.tanaka@toshiba.co.jp>/* >> >> >> Thank you. >> >> RFC Editor/jm/ar >> >> >> On Apr 20, 2021, rfc-editor@rfc-editor.org >> <mailto:rfc-editor@rfc-editor.org> 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 >> c310@rfc-editor.org <mailto:c310@rfc-editor.org> >> 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 c310@rfc-editor.org >> <mailto:c310@rfc-editor.org> >> 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] AUTH48 [JM]: RFC 9033 <draft-ietf-6tisch-m… rfc-editor
- Re: [C310] AUTH48 [JM]: RFC 9033 <draft-ietf-6tis… rfc-editor
- Re: [C310] AUTH48 [JM]: RFC 9033 <draft-ietf-6tis… Mališa Vučinić
- Re: [C310] AUTH48 [JM]: RFC 9033 <draft-ietf-6tis… Prof. Diego Dujovne
- Re: [C310] AUTH48 [JM]: RFC 9033 <draft-ietf-6tis… Xavi Vilajosana Guillen
- Re: [C310] AUTH48 [JM]: RFC 9033 <draft-ietf-6tis… Tengfei Chang
- Re: [C310] AUTH48 [JM]: RFC 9033 <draft-ietf-6tis… Pascal Thubert (pthubert)
- Re: [C310] AUTH48 [JM]: RFC 9033 <draft-ietf-6tis… Jean Mahoney
- Re: [C310] AUTH48 [JM]: RFC 9033 <draft-ietf-6tis… Jean Mahoney
- Re: [C310] AUTH48 [JM]: RFC 9033 <draft-ietf-6tis… Pascal Thubert (pthubert)
- Re: [C310] AUTH48 [JM]: RFC 9033 <draft-ietf-6tis… Tengfei Chang
- [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC 903… Jean Mahoney
- Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC… Prof. Diego Dujovne
- Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC… Mališa Vučinić
- Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC… Jean Mahoney
- Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC… Prof. Diego Dujovne
- Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC… Jean Mahoney
- Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC… Tengfei Chang
- Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC… Xavi Vilajosana Guillen
- Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC… Simon Duquennoy
- Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC… Erik Kline
- Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC… Jean Mahoney
- Re: [C310] [AD - Erik Kline] Re: AUTH48 [JM]: RFC… Jean Mahoney