Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-ietf-6lo-deadline-time-05.txt> NOW AVAILABLE
Charlie Perkins <charliep@computer.org> Mon, 17 May 2021 19:36 UTC
Return-Path: <charliep@computer.org>
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 56050F407C4; Mon, 17 May 2021 12:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
X-Spam-Flag: NO
X-Spam-Score: -97.038
X-Spam-Level:
X-Spam-Status: No, score=-97.038 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=0.01, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=2, SPF_SOFTFAIL=0.972, SUBJECT_IN_WHITELIST=-100, URIBL_BLOCKED=0.001] 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 KFsb4W9Sqvm0; Mon, 17 May 2021 12:36:09 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by rfc-editor.org (Postfix) with ESMTPS id 7BFF0F407C0; Mon, 17 May 2021 12:36:09 -0700 (PDT)
Received: from [50.197.142.146] (helo=[172.21.0.88]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from <charliep@computer.org>) id 1lij26-000FOk-27; Mon, 17 May 2021 15:36:06 -0400
To: Jean Mahoney <jmahoney@amsl.com>, Lijo Thomas <lijo@cdac.in>, rfc-editor@rfc-editor.org, satishnaidu80@gmail.com, "'S.V.R.Anand'" <anandsvr@iisc.ac.in>, 'Malati Hegde' <malati@iisc.ac.in>, ek.ietf@gmail.com
Cc: 6lo-chairs@ietf.org, 6lo-ads@ietf.org, shwethab@cisco.com, c310@rfc-editor.org
References: <20210513181917.B37DEF4074D@rfc-editor.org> <005001d74b19$62bcb980$28362c80$@cdac.in> <c3ecb73f-dea6-330f-5c67-2baa39cac6d2@amsl.com>
From: Charlie Perkins <charliep@computer.org>
Organization: Blue Sky Meadows
Message-ID: <b92c3841-2ad1-533d-6f7c-18265fa071c3@computer.org>
Date: Mon, 17 May 2021 12:36:04 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <c3ecb73f-dea6-330f-5c67-2baa39cac6d2@amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956df8303b86ceddf55a26d47b5011c841849bf012c4845a722350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 50.197.142.146
X-Mailman-Approved-At: Mon, 17 May 2021 12:38:04 -0700
Subject: Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-ietf-6lo-deadline-time-05.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: Mon, 17 May 2021 19:36:14 -0000
Hello Jean and all, Now that my affiliation has been updated, I don't have any other changes required before publication. Naturally Yours, Charlie P. On 5/17/2021 8:26 AM, Jean Mahoney wrote: > Lijo, > > Thank you for the updated XML file. Very helpful! We have removed the > XML comments that pertained to closed questions and comments: > > https://www.rfc-editor.org/authors/rfc9034-lastxmlrfcdiff.html > (these changes to the XML) > > https://www.rfc-editor.org/authors/rfc9034.txt > https://www.rfc-editor.org/authors/rfc9034.pdf > https://www.rfc-editor.org/authors/rfc9034.html > https://www.rfc-editor.org/authors/rfc9034.xml > https://www.rfc-editor.org/authors/rfc9034-diff.html (all changes) > https://www.rfc-editor.org/authors/rfc9034-auth48diff.html (AUTH48 > changes) > https://www.rfc-editor.org/authors/rfc9034-auth48rfcdiff.html > (AUTH48 changes side by side) > > We will await further word from you, your coauthors, and the AD > regarding other AUTH48 changes and/or approval. > > Best regards, > > RFC Editor/jm > > > On 5/17/21 7:37 AM, Lijo Thomas wrote: >> Hello, >> >> Thanks for the suggestions/inputs. We have updated the XML file < >> rfc9034-updated> and is attached herewith. >> >> Our responses to the suggested changes is tagged with "[Author >> Resp]" in the XML. >> >> Also attached the diff file indicating the updates. >> >> Please let us know if there is any further clarification or inputs >> required from our end. >> Thanks & Regards, >> Lijo Thomas >> >> -----Original Message----- >> From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> >> Sent: 13 May 2021 23:49 >> To: lijo@cdac.in; satishnaidu80@gmail.com; anand@ece.iisc.ernet.in; >> malati@ece.iisc.ernet.in; charliep@computer.org; ek.ietf@gmail.com >> Cc: rfc-editor@rfc-editor.org; 6lo-ads@ietf.org; 6lo-chairs@ietf.org; >> shwethab@cisco.com; c310@rfc-editor.org >> Subject: [AD] Re: AUTH48 [JM]: RFC 9034 >> <draft-ietf-6lo-deadline-time-05.txt> NOW AVAILABLE >> >> Authors, AD, >> >> *Erik (as AD), please reply to #1. >> >> While reviewing this document during AUTH48 >> (https://www.rfc-editor.org/authors/rfc9034.html and additional >> formats), please resolve the following questions, which are also in >> the XML file. >> >> 1) <!-- [rfced] AD: Please review and let us know if you approve the >> changes made after -05 of this draft was approved. They are shown in >> this diff file (comparing -05 and -06): >> https://www.rfc-editor.org/rfc9034-postapproval-rfcdiff.html >> >> Note: -06 was provided by the author in October 2019; it is not in >> the Datatracker. >> >> For the purpose of AUTH48, the .original for this file is -05 (the >> approved draft), so these changes are also viewable in the various >> diff files provided. >> --> >> >> >> 2) <!-- [rfced] FYI, the title of the document has been updated as >> follows to expand the abbreviation. Please review. >> >> Current: >> Packet Delivery Deadline Time in the 6LoWPAN Routing Header >> >> Perhaps: >> Packet Delivery Deadline Time in the Routing Header for >> IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) >> --> >> >> >> 3) <!-- [rfced] FYI, the authors' comments in the XML file have been >> marked with [auth]. Please let us know if any updates are needed >> based on those comments; if not, they will be removed. >> --> >> >> >> 4) <!-- [rfced] We have updated Lijo Thomas's address. Please let us >> know if other changes are necessary. >> >> Original: >> Lijo Thomas >> C-DAC >> Centre for Development of Advanced Computing (C-DAC), Vellayambalam >> Trivandrum 695033 >> India >> >> Current (The organization abbreviation (C-DAC) is given in the header): >> Lijo Thomas >> Centre for Development of Advanced Computing >> Vellayambalam >> Trivandrum 695033 >> India >> --> >> >> >> 5) <!-- [rfced] Please review the following changes for accuracy of >> these authors' names. >> >> Original: <author fullname="Lijo Thomas" initials="" surname="Lijo >> Thomas"> >> Current: <author fullname="Lijo Thomas" initials="L." surname="Thomas"> >> >> Original: <author fullname="S.V.R Anand" initials="" >> surname="S.V.R.Anand"> >> Current: <author fullname="S.V.R. Anand" initials="S.V.R." >> surname="Anand"> >> >> Original: <author fullname="Malati Hegde" initials="" surname="Malati >> Hegde"> >> Current: <author fullname="Malati Hegde" initials="M." surname="Hegde"> >> --> >> >> >> 6) <!-- [rfced] May this sentence be updated as follows? IoT and M2M >> seem redundant here; we suggest choosing one. >> >> Current: >> The deadline time enables forwarding and scheduling decisions >> for time-critical Internet of Things (IoT) machine-to-machine (M2M) >> applications that operate within time-synchronized networks that >> agree >> on the meaning of the time representations used for the deadline >> time values. >> >> Perhaps (and "Internet of Things" can be added to the keywords): >> The deadline time enables forwarding and scheduling decisions >> for time-critical, machine-to-machine applications that operate >> within time-synchronized networks that agree on the time >> representations used for the deadline time values. >> --> >> >> >> 7) <!-- [rfced] In the sentence below, would "service guarantees" >> be a better fit than "delay guarantees"? >> >> Current: >> Low-power and Lossy Networks (LLNs) are likely to be >> deployed for >> real-time industrial applications requiring end-to-end >> delay guarantees [RFC8578]. >> --> >> >> >> 8) <!-- [rfced] Could the following sentence be made more concise? >> >> Current: >> [RFC8138] specifies the 6LoWPAN Routing Header (6LoRH), >> compression schemes for RPL (Routing Protocol for Low-Power and >> Lossy Networks) routing (source routing) operation [RFC6554], >> header compression of RPL packet information [RFC6553], and >> IP-in-IP encapsulation. >> >> Perhaps: >> [RFC8138] specifies the 6LoWPAN Routing Header (6LoRH), >> compression schemes for RPL (Routing Protocol for Low-Power and >> Lossy Networks) source routing [RFC6554], header compression of >> RPL packet information [RFC6553], and IP-in-IP encapsulation. >> --> >> >> >> 9) <!-- [rfced] We have expanded "6lo" here, but perhaps "6LoWPAN" >> is meant? >> >> Current: >> The Deadline-6LoRHE can be used in any time-synchronized 6lo >> (IPv6 over Networks of Resource-constrained Nodes) network. >> --> >> >> >> 10) <!-- [rfced] We have made the following changes in Section 5 to >> improve readability. Please let us know if any other changes are >> necessary. >> >> Original: >> * For example, DTL = 0b0000 means the deadline time in the >> 6LoRHE >> is 1 hex digit (4 bits) long. OTL = 0b111 means the >> origination time is 7 hex digits (28 bits) long. >> >> Current: >> For example, DTL = 0b0000 means the DT field in the 6LoRHE >> is 1 hex digit (4 bits) long. OTL = 0b111 means the >> OTD field is 7 hex digits (28 bits) long. >> --> >> >> >> 11) <!-- [rfced] We have formatted equations with superscript and >> subscript. Please review. >> >> For example (Section 5): >> Epoch_Range(DTL) = (2^(4*(DTL+1)) >> >> Current: >> [same in the text file; please see HTML and PDF] >> >> >> For another example (Section 8 of -06): >> t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))] >> >> Current: >> [same in the text file; please see HTML and PDF] >> --> >> >> >> 12) <!-- [rfced] We have made the following change to improve >> readability. >> Please let us know if other changes are necessary. >> >> Original: >> A low value of >> DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16 >> RTUs within the Epoch_Range (DTL) = 16^1 (for any time unit TU). >> >> Current: >> A low value of >> DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16 >> RTUs within the Epoch_Range (i.e., Epoch_Range(DTL) = 16^1) for any >> TU. >> --> >> >> >> 13) <!-- [rfced] We're having difficulty parsing the following >> sentence. >> Does the suggested text convey the intended meaning? >> >> Current: >> When deadline-bearing flows are identified on a per-flow basis, >> which >> may provide attackers with additional information about the data >> flows, when compared to networks that do not include per-flow >> identification. >> >> Perhaps: >> The identification of deadline-bearing flows on a per-flow basis >> may provide attackers with additional information about the data >> flows compared to networks that do not include per-flow >> identification. >> >> Perhaps: >> The identification of deadline-bearing flows on a per-flow basis >> may provide attackers with additional information about the data >> flows compared to networks that do not include per-flow >> identification. >> --> >> >> >> 14) <!-- [rfced] For [PHY-SPEC], is this specification available from >> wi-sun.org? If so, please provide the URL for this reference. >> >> Current: >> [PHY-SPEC] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March >> 2016. >> --> >> >> >> Thank you. >> >> RFC Editor/jm/ar >> >> >> On May 13, 2021, rfc-editor@rfc-editor.org wrote: >> >> *****IMPORTANT***** >> >> Updated 2021/05/13 >> >> 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/rfc9034.xml >> https://www.rfc-editor.org/authors/rfc9034.html >> https://www.rfc-editor.org/authors/rfc9034.pdf >> https://www.rfc-editor.org/authors/rfc9034.txt >> >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9034-diff.html >> >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc9034-xmldiff1.html >> >> The following files are provided to facilitate creation of your own >> diff files of the XML. >> >> Initial XMLv3 created using XMLv2 as input: >> https://www.rfc-editor.org/authors/rfc9034.original.v2v3.xml >> >> XMLv3 file that is a best effort to capture v3-related format updates >> only: >> https://www.rfc-editor.org/authors/rfc9034.form.xml >> >> >> Tracking progress >> ----------------- >> >> The details of the AUTH48 status of your document are here: >> https://www.rfc-editor.org/auth48/rfc9034 >> >> Please let us know if you have any questions. >> >> Thank you for your cooperation, >> >> RFC Editor >> >> -------------------------------------- >> RFC9034 (draft-ietf-6lo-deadline-time-05) >> >> Title : Packet Delivery Deadline time in 6LoWPAN Routing >> Header >> Author(s) : L. Thomas, S. Anamalamudi, S. Anand, M. Hegde, C. >> Perkins >> WG Chair(s) : Carles Gomez, Shwetha Bhandari >> Area Director(s) : Erik Kline, Éric Vyncke >> >> ------------------------------------------------------------------------------------------------------------ >> >> [ C-DAC is on Social-Media too. Kindly follow us at: >> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] >> >> This e-mail is for the sole use of the intended recipient(s) and may >> contain confidential and privileged information. If you are not the >> intended recipient, please contact the sender by reply e-mail and >> destroy >> all copies and the original message. Any unauthorized review, use, >> disclosure, dissemination, forwarding, printing or copying of this email >> is strictly prohibited and appropriate legal action will be taken. >> ------------------------------------------------------------------------------------------------------------ >> >>
- [C310] AUTH48 [JM]: RFC 9034 <draft-ietf-6lo-dead… rfc-editor
- [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-ietf… rfc-editor
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Alice Russo
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Lijo Thomas
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Jean Mahoney
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Jean Mahoney
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Charlie Perkins
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Jean Mahoney
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Erik Kline
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Erik Kline
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… 'S.V.R.Anand'
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Malati Hegde
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… satish anamalamudi
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Erik Kline
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Lijo Thomas
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Jean Mahoney
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Jean Mahoney
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Lijo Thomas
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Jean Mahoney
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… lijo23@yahoo.com
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Jean Mahoney
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Erik Kline
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Erik Kline
- Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-… Jean Mahoney