Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
draft-ietf-6lo-deadline-time-05

[Ballot comment]
Thanks for addressing my DISCUSS items

----
(2) Section 5.  Per the description of the D flag, how would a forwarding device “suspect that a downstream node might find [a packet] useful”?

(3) Section 6.  Is there normative language about the behavior of forwarding entities when encountering the Deadline header in this section?  If not, I’d recommend adding explicit text to that effect.

[Ballot comment]
The changes to the Security Considerations on version -05 address my concern about abuse of the deadline time.  Thanks for that, and I'm clearing my DISCUSS now.

Editorial comments that are still relevant in version -05:

In the Introduction, please expand “BLE” on first use.

In “Terminology”, you’re citing RFC 8174, but not using the new BCP 14 boilerplate from there.  Please copy/paste the new boilerplate.

— Section 5 —

Why is DTL the length *minus 1*?  Doesn’t that invite mistakes?  Is there a reason not to make it the length, and to say that 0 is not a valid value?  Do you really need the extra size that the extra bit provides?

[Ballot discuss]
I support Magnus’s DISCUSS #1 (and perhaps we are noting the same thing)

The current Security Considerations text needs explicit discussion of the impact of the deadline being manipulated.

[Ballot comment]
(1) I also support Barry’s DISCUSS on the need to discuss what happens to a network where all senders have short deadlines

(2) Section 5.  Per the description of the D flag, how would a forwarding device “suspect that a downstream node might find [a packet] useful”?

(3) Section 6.  Is there normative language about the behavior of forwarding entities when encountering the Deadline header in this section?  If not, I’d recommend adding explicit text to that effect.

(4) Editorial nits:
** Section 4.  Typo.  s/the the/the/

[Ballot comment]
In Section 4:

  There are multiple ways that a packet can be delayed, including
  queuing delay, MAC layer contention delay, serialization delay, and
  propagation delays.  Sometimes there are processing delays as well.
  For the purpose of determining whether or not the deadline has
  already passed, these various delays are not distinguished.

Not distinguished from what? Do you mean "not counted"?

In Section 5:

  o  OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer,
      encoding the length of the field in hex digits.  If OTL == 0, the
      OTD field is not present.  The value of OTL MUST NOT exceed the
      value of DTL plus one.

      *  For example, DTL = 0b0000 means the deadline time in the 6LoRHE
        is 1 hex digit (4 bits) long.

Ok, so 0b0000 ==> (0 + 1) * 4, means 4 bits.

          OTL = 0b111 means the
        origination time is 7 hex digits (28 bits) long.

Is my math wrong or is your example wrong?

0b111 == 7. So (7 + 1) * 4 would be 32 bits.


  o  Binary Pt (6 bits) : If zero, the number of bits of the integer
      part the DT is equal to the number of bits of the fractional part
      of the DT.  if nonzero, the Binary Pt is a signed integer
      determining the position of the binary point within the value for
      the DT.

      *  If BinaryPt value is positive, then the number of bits for the
        integer part of the DT is increased by the value of BinaryPt,
        and the number of bits for the fractional part of the DT is
        correspondingly reduced.  This increases the range of DT.
      *  If BinaryPt value is negative, then the number of bits for the
        integer part of the DT is decreased by the value of BinaryPt,
        and the number of bits for the fractional part of the DT is
        correspondingly increased.  This increases the precision of the
        fractional seconds part of DT.

It would be good if you specified how negative values are represented (Ok, maybe it is obvious) and the range for positive and negative values.

[Ballot comment]
Firstly, thank you very much for the:
"3.  6LoRHE Generic Format
  Note: this section is not normative and is included for convenience."
It's really helpful to include stuff like this for newcomers and reviewers.

I support Barry's DISCUSS - I was going to ask the same thing, but he beat me to it.

I suspect that more context might also be helpful - one of the few times I can think of when I'd rather have a packet dropped than delivered late is for things like VoIP, where delayed / out-of-ordered packets are of no use, but I feel I might be missing more examples?

[Ballot discuss]
The Gen-ART reviewer made the following observation, which I'd like to discuss:

There is a serious problem with the last 5 paragraphs of section 8,
"Synchronization Aspects":  they seem to assume that the time
representation for the Deadline Time and Origination Time values will
wrap around, that is, that the representation is the absolute value
modulo the size of the field.  In addition, there is a lack of clarity
how the new epoch point will be chosen after the value wraps around.
This seems to contradict the earlier sections of the document which
speak of the values as if they are always to be considered as absolute
values on a time scale selected by the TU field, viz., either the NTP
time scale (in seconds) or the network's ASN numbering.

It's possible that four of these paragraphs are intended to only apply
to the use of TU = 00, the NTP time scale, and perhaps that usage of
the header is understood not to be completely specified yet.

However, the final paragraph discusses TU = 10 (the ASN time scale),
and claims that wrapping of the DT value is intended.  This is
relevant to current implementations.

Some sort of resolution of this is needed; as the document stands it
is self-inconsistent.  One possible resolution would be to omit these
paragraphs.

[Ballot comment]
Thanks for the work everyone has put into this document. I have only a small number of comments and some nits.

Comments:
- section 1, are the different timezones really a problem? I would assume that all those devices are using a common reference such as UTC or does 'time zone' in this document does not refer to EST, PST, CET, .. ? If so, then it should be specified to ease the understanding
- section 3, should explain why it starts with 0b101, if there is no meaning but it is just an identifier for the option, any reason why there is no IANA registry for this ? (and I understand that the IANA registry should have been created in the master document)
- section 3, seems to imply that there is nothing after type but with a variable length. Suggest to add 'options'
- section 5, DTL is "unsigned 4-bit integer, encoding the length of the field in hex digits" can you clarify whether it is the number of 8-bit bytes or the number of 4-bit nibbles ? The rest of the text seems to imply the latter but it would be nice to introduce it earlier IMHO. Also, if odd number of nibbles, then the figure 3 is not really correct as it implies a 8-bit boundary. Or is there some padding ? Then it should be specified and explained why simply not counting in 8-bit bytes.
- more generally, I wonder whether having a mechanism to prioritize 'soon to expire' packets would be doable and benefitial. In the same vein, a description of the forwarding node decision would be welcome rather then implied in the D flag description

Nit:
- abstract contains very long sentences which makes it hard to parse (esp the last sentence) not to mention acronyms that should be expanded even if well-known (M2M for example)

[Ballot discuss]
I have a few small points (one is confusing enough to warrant a quick discussion), but they affect clarity of the specification:

In Section 5:

  o  OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer,
      encoding the length of the field in hex digits.  If OTL == 0, the
      OTD field is not present.  The value of OTL MUST NOT exceed the
      value of DTL plus one.

      *  For example, DTL = 0b0000 means the deadline time in the 6LoRHE
        is 1 hex digit (4 bits) long.

Ok, so 0b0000 ==> (0 + 1) * 4, means 4 bits.

          OTL = 0b111 means the
        origination time is 7 hex digits (28 bits) long.

Is my math wrong or is your example wrong?

0b111 == 7. So (7 + 1) * 4 would be 32 bits.

[Ballot comment]
In Section 4:

  There are multiple ways that a packet can be delayed, including
  queuing delay, MAC layer contention delay, serialization delay, and
  propagation delays.  Sometimes there are processing delays as well.
  For the purpose of determining whether or not the deadline has
  already passed, these various delays are not distinguished.

Not distinguished from what? Do you mean "not counted"?

In Section 5:

  o  Binary Pt (6 bits) : If zero, the number of bits of the integer
      part the DT is equal to the number of bits of the fractional part
      of the DT.  if nonzero, the Binary Pt is a signed integer
      determining the position of the binary point within the value for
      the DT.

      *  If BinaryPt value is positive, then the number of bits for the
        integer part of the DT is increased by the value of BinaryPt,
        and the number of bits for the fractional part of the DT is
        correspondingly reduced.  This increases the range of DT.
      *  If BinaryPt value is negative, then the number of bits for the
        integer part of the DT is decreased by the value of BinaryPt,
        and the number of bits for the fractional part of the DT is
        correspondingly increased.  This increases the precision of the
        fractional seconds part of DT.

It would be good if you specified how negative values are represented (Ok, maybe it is obvious) and the range for positive and negative values.

[Ballot comment]
Agree with others, it would be helpful to have more description on the context/use.

Mirja noted this sentence:
“The packet SHOULD be delivered to the Receiver before this time.”
What happens if it is not delivered before this time?

[Ballot comment]
I support Magnus and Barry's Discuss. I would also like to see at least more text in the security consideration section about potential attacks or risks that can follow when the provided information is altered by another node or provided in a mal-intended way.

Also it would be good to provide further information on how this deadline is supposed to be used by the network as well as by the endpoint. How does an endpoint decide about the right deadline? Does the endpoint need to know the RTT? How can this impact routing and scheduling? Of course these things don't have to be normatively specified, however, providing more information about the intended use and assumption would probably be helpful for implementors to do the right thing as well.

One more comment: The following normative statements should probably rather use non-normative lower-case "should":
“The packet SHOULD be delivered to the Receiver before this time.”
and
“All nodes within the network SHOULD process the Deadline-6LoRHE in order to support delay-sensitive deterministic applications.”
as they are rather implicit goals than an actionable requirement.

[Ballot comment]
I support Magnus and Barry's Discuss. I would also like to see at least more text in the security consideration section about potential attacks or risks that can follow when the provided information is altered by another node or provided in a mal-intended way.

Also it would be good to provide further information on how this deadline is supposed to be used by the network as well as by the endpoint. How does an endpoint decide about the right deadline? Does the endpoint need to know the RTT? How can this impact routing and scheduling? Of course these things don't have to be normatively specified, however, providing more information about the intended use and assumption would probably be helpful for implementors to do the right thing as well.

[Ballot discuss]
The security consideration section have significant short comings as this mechanism enables multiple ways to attack both the packet and the system to my understanding. I would appreaciate your clarifications on these matters.

First of all by changing the dead-line so that it gets dropped because it is already late, alternatively move the deadline time out further in time (later), so that the forwarders may deliver it so late that the receiver considers it to late.

Secondly, there is the question if extensive use of this header will cause overload or affect the scheduling of packet transmission affect other traffic negatively. There appear to exist potential for new ways of bad interflow interactions here.

[Ballot comment]
Looking at this mechanism it appears to me as something that should fit into a frame work, but that is not explicitly given. The main reason I am raising that is that it appears to not care about a number of interesting and challenging questions for a mechanism like this. Questions that a particular framework can take care of, or which any user of this mechanism would need to consider in their deployment before they can determine if they can safely deploy it. It might be that some of the questions have answers and I missed. In that case please straighten me out. And if you have some additional document that provides more detailed usage which discuss any of these issues I would appreciate a pointer.

So quesitons that I got when reading this specification:

1. Are there any mechanism to provide feedback if the packets reach the receiver in time? If the sender sets the deadline shorter than the minimal one-way path delay, then all packets will be late. Will any feedback be provided that this is happening? In cases D=1 this appear to be a recipe for a black hole for the traffic. One can also end up in situation where a large fraction of the packet are late.

2. Any mechanism that exist to determine what the expected latency are from sender to receiver?

3. Are there any type of admittance or policy approval to use this mechanism?

4. What is the relationship between traffic with a dead-line and other traffic without a dead-line. Are traffic with a dead-line implicitly allowed to pre-empt other traffic or at least to delay it in its queue?

5. As Barry noted, what are the protection against missuse?

These are issue that a framework or architecture would consider, I note that https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ include some discussion of these topics. Still DETNET architecture appear more constrained when it comes to usage than what this mechanism through its examples.

[Ballot discuss]
This should be easy to explain and clear up, but I have to ask, as I don’t see anything about it in the document: what deters entities from using this with a short deadline time in order to get expedited delivery, when they don’t need it?  How does this help a network if, ultimately, every transmission specifies a very short deadline time?

[Ballot discuss]
This should be easy to explain and clear up, bit I have to ask, as I don’t see anything about it in the document: what deters entities from using this with a short deadline time in order to get expedited delivery, when they don’t need it?  How does this help a network if, ultimately, every transmission specifies a very short delivery time?

[Ballot comment]
In the Introduction, please expand “BLE” on first use.

In “Terminology”, you’re citing RFC 8174, but not usng the new BCP 14 boilerplate from there.  Please copy/paste the new boilerplate.

— Section 5 —

The definition of “TU” is out of order; please move it so it’s in the same order in the definitions as in the block.

Why is DTL the length *minus 1*?  Doesn’t that invite mistakes?  Is there a reason not to make it the length, and to say that 0 is not a valid value?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-6lo-deadline-time-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Elective 6LoWPAN Routing Header Type registry on the IPv6 Low Power Personal Area Network Parameters registry page located at:

https://www.iana.org/assignments/_6lowpan-parameters/

a single, new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Description: Deadline-6LoRHE
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-12-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-6lo-deadline-time@ietf.org, 6lo-chairs@ietf.org, samitac.ietf@gmail.com, 6lo@ietf.org, Samita Chakrabarti , suresh@kaloom.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Packet Delivery Deadline time in 6LoWPAN Routing Header) to Proposed Standard


The IESG has received a request from the IPv6 over Networks of
Resource-constrained Nodes WG (6lo) to consider the following document: -
'Packet Delivery Deadline time in 6LoWPAN Routing Header'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-12-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies a new type for the 6LoWPAN routing header
  containing the delivery deadline time for data packets.  The deadline
  time enables forwarding and scheduling decisions for time critical
  IoT M2M applications that need deterministic delay guarantees over
  constrained networks and operate within time-synchronized networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-6tisch-terminology: Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e (None - IETF stream)

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational,
Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in
the title page header?

A. draft-ietf-6lo-deadline-time-02 draft is a 'standards track' document. This intended status is indicated
in the document header. The document introduces a new 6lo Routing header type for the 6loRH packet defined
in RFC8138.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a
Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  RFC 8138 specifies the 6LoWPAN Routing Header (6LoRH),
  compression schemes for RPL routing (source routing)
  operation [RFC6554], header compression of RPL Packet
  Information [RFC6553], and IP-in-IP encapsulation.  This document
  specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1,
  so that the deadline time of data packets can be included within the
  6LoWPAN routing header.  This document also specifies handling of the
  deadline time when packets traverse through time-synchronized
  networks operating in different timezones or distinct reference clocks.
  Time synchronization is not mandated in this document, rather it points to
    different available time synchronization solutions for low power and lossy networks.



Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular
points or were there decisions where the consensus was particularly rough?

A.  Working group has provided many input towards development of the document during the initial phase before it is becoming a WG document.
Once these comments were incorporated into the document, the draft went for successful adoption call. After that  two reviewers provided thorough comments including the shepherd.
Working group has a rough consensus to move this draft towards IESG submission.

Document Quality:

The document is  has been clarified with editorial changes in -02. A few more nits need to be updated as mentioned in the shepherd's comments. Other than that , it is ready.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their
plan to implement the specification? Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)?
In the case of a Media Type review, on what date was the request posted?

A.

draft-ietf-6lo-deadline-time-01 has been implemented in open source OpenWSN environment and got merged
with the main distribution.

The github links for this is available at:

https://github.com/openwsn-berkeley/openwsn-fw/tree/develop/openapps/uexpiration

https://github.com/openwsn-berkeley/openwsn-fw/pull/355

The shepherd or working group are unaware of any forthcoming vendor implementation of the document, however
openwsn source code is used by many low power vendors(6tisch).

The working group has provided feedback to the document -
https://mailarchive.ietf.org/arch/browse/6lo/?q=6lo-deadline-time
Geoorge Papadopoulos and Samita Chakrabarti reviewed the recent document version -01.
Previously the working group commented on the non-working group version of the document
and the comments are available at: https://mailarchive.ietf.org/arch/browse/6lo/?q=6lo-expiration



Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd: Samita Chakrabarti, Responsible Area Director: Suresh Krishnan


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version
of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A. Document shepherd has reviewed the -01 version of the document. The -02 reflects comments from document
shepherd and George Papadopoulos. The document is ready for publication.



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been
performed?

A. The document has been reviewed by many working group members throught its journey.The working group
  agrees to make it a standard track document. Document shepherd has no particular concerns on the reivews.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took
place.

A. Not applicable.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the
Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail
those concerns here.

A.  It has been reviewed by a number of WG members and the shepherd. It is ready to advance.

A note to the Area Director: A few references to draft-ietf-roll-routing-dispatch-05 should be changed to
RFC 8138.



(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with
the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

A. No IPR disclosures had been filed by the co-authors of the document. Confirmation with each author is
in progress.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and
conclusion regarding the IPR disclosures.
A. No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the WG as a whole understand and agree with it?

A. The working group as a whole understands and agrees with the progress of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the
areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate
email because this questionnaire is publicly available.)

A. No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough;
this check needs to be thorough.

No issues found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type,
and URI type reviews.

A. Not Applicable.

(13) Have all references within this document been identified as either normative or informative?

A. Yes. However, the 6tisch-terminology reference may be moved to "informative" section.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an
unclear state? If such normative references exist, what is the plan for their completion?
A. No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references
to support the Area Director in the Last Call procedure.

A. None except the reference of 6tisch-terminology document.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the
title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the document where the relationship of
this document to the other RFCs is discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No. This document will not update any base 6lo documents or  existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to
its consistency with the body of the document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A. The document requests an IANA change.It introduces a new 6loRH type. The value is left as TBD. Version -02
  draft does not clearly state if this IANA reigistry will fall into Critical 6LoRH type or Elective 6loRH
  type assignments or both.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public
guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

A.https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#critical-6lowpan-routing-header-type

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the
document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.(1) What type of
RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

A. Manual checks are performed by the shepherd. The document is seeking Standards track.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational,
Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in
the title page header?

A. draft-ietf-6lo-deadline-time-02 draft is a 'standards track' document. This intended status is indicated
in the document header. The document introduces a new 6lo Routing header type for the 6loRH packet defined
in RFC8138.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a
Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  RFC 8138 specifies the 6LoWPAN Routing Header (6LoRH),
  compression schemes for RPL routing (source routing)
  operation [RFC6554], header compression of RPL Packet
  Information [RFC6553], and IP-in-IP encapsulation.  This document
  specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1,
  so that the deadline time of data packets can be included within the
  6LoWPAN routing header.  This document also specifies handling of the
  deadline time when packets traverse through time-synchronized
  networks operating in different timezones or distinct reference clocks.
  Time synchronization is not mandated in this document, rather it points to
    different available time synchronization solutions for low power and lossy networks.



Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular
points or were there decisions where the consensus was particularly rough?

A. D

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their
plan to implement the specification? Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)?
In the case of a Media Type review, on what date was the request posted?

A.

draft-ietf-6lo-deadline-time-01 has been implemented in open source OpenWSN environment and got merged
with the main distribution.

The github links for this is available at:

https://github.com/openwsn-berkeley/openwsn-fw/tree/develop/openapps/uexpiration

https://github.com/openwsn-berkeley/openwsn-fw/pull/355

The shepherd or working group are unaware of any forthcoming vendor implementation of the document, however
openwsn source code is used by many low power vendors(6tisch).

The working group has provided feedback to the document -
https://mailarchive.ietf.org/arch/browse/6lo/?q=6lo-deadline-time
Geoorge Papadopoulos and Samita Chakrabarti reviewed the recent document version -01.
Previously the working group commented on the non-working group version of the document
and the comments are available at: https://mailarchive.ietf.org/arch/browse/6lo/?q=6lo-expiration



Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Document Shepherd: Samita Chakrabarti, Responsible Area Director: Suresh Krishnan


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version
of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

A. Document shepherd has reviewed the -01 version of the document. The -02 reflects comments from document
shepherd and George Papadopoulos. The document is ready for publication.



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been
performed?

A. The document has been reviewed by many working group members throught its journey.The working group
  agrees to make it a standard track document. Document shepherd has no particular concerns on the reivews.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took
place.

A. Not applicable.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the
Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail
those concerns here.

A.  It has been reviewed by a number of WG members and the shepherd. It is ready to advance.

A note to the Area Director: A few references to draft-ietf-roll-routing-dispatch-05 should be changed to
RFC 8138.



(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with
the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

A. No IPR disclosures had been filed by the co-authors of the document. Confirmation with each author is
in progress.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and
conclusion regarding the IPR disclosures.
A. No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the WG as a whole understand and agree with it?

A. The working group as a whole understands and agrees with the progress of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the
areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate
email because this questionnaire is publicly available.)

A. No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough;
this check needs to be thorough.

No issues found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type,
and URI type reviews.

A. Not Applicable.

(13) Have all references within this document been identified as either normative or informative?

A. Yes. However, the 6tisch-terminology reference may be moved to "informative" section.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an
unclear state? If such normative references exist, what is the plan for their completion?
A. No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references
to support the Area Director in the Last Call procedure.

A. None except the reference of 6tisch-terminology document.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the
title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the document where the relationship of
this document to the other RFCs is discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

No. This document will not update any base 6lo documents or  existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to
its consistency with the body of the document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A. The document requests an IANA change.It introduces a new 6loRH type. The value is left as TBD. Version -02
  draft does not clearly state if this IANA reigistry will fall into Critical 6LoRH type or Elective 6loRH
  type assignments or both.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public
guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

A.https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#critical-6lowpan-routing-header-type

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the
document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.(1) What type of
RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

A. Manual checks are performed by the shepherd. The document is seeking Standards track.

Request for posting confirmation emailed to previous authors: "S.V.R Anand" , 6lo-chairs@ietf.org, Charles Perkins , Satish Anamalamudi , Lijo Thomas , Malati Hegde , "P.M. Akshay"

Request for posting confirmation emailed to previous authors: "S.V.R Anand" , 6lo-chairs@ietf.org, Charles Perkins , Satish Anamalamudi , Lijo Thomas , Malati Hegde , "P.M. Akshay"