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

["'S.V.R.Anand'" <[e-mail]>]

Hello Jean and all,

The document looks fine to me, and approve its publication as an RFC.

Regards
Anand


On 21-05-17 14:58:50, Jean Mahoney wrote:
> 
> 
> 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.
> >>>------------------------------------------------------------------------------------------------------------
> >>>
> >>>
> >