Re: [C310] [AD] Re: AUTH48 [JM]: RFC 9034 <draft-ietf-6lo-deadline-time-05.txt> NOW AVAILABLE

[Jean Mahoney <[e-mail]>]

Charlie,

Thank you for your response. We have noted your approval on the AUTH48 
status page:

    https://www.rfc-editor.org/auth48/rfc9034

We will await further word from your coauthors and the AD regarding 
other AUTH48 changes and/or approval.

Best regards,

RFC Editor/jm


On 5/17/21 2:36 PM, Charlie Perkins wrote:
> 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: [e-mail] <[e-mail]>
>>> Sent: 13 May 2021 23:49
>>> To: [e-mail]; [e-mail]; [e-mail]; 
>>> [e-mail]; [e-mail]; [e-mail]
>>> Cc: [e-mail]; [e-mail]; 
>>> [e-mail]; [e-mail]; [e-mail]
>>> 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, [e-mail] 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.
>>> ------------------------------------------------------------------------------------------------------------ 
>>>
>>>
>