Skip to main content

Early Review of draft-ietf-6lo-deadline-time-02
review-ietf-6lo-deadline-time-02-iotdir-early-eddy-2018-09-18-00

Request Review of draft-ietf-6lo-deadline-time
Requested revision No specific revision (document currently at 05)
Type Early Review
Team Internet of Things Directorate (iotdir)
Deadline 2018-09-21
Requested 2018-09-05
Requested by Suresh Krishnan
Authors Lijo Thomas , Satish Anamalamudi , S.V.R Anand , Malati Hegde , Charles E. Perkins
I-D last updated 2024-05-28 (Latest revision 2019-07-08)
Completed reviews Iotdir Early review of -02 by Wesley Eddy (diff)
Rtgdir Telechat review of -03 by Dan Frost (diff)
Secdir IETF Last Call review of -03 by Charlie Kaufman (diff)
Genart IETF Last Call review of -03 by Dale R. Worley (diff)
Genart Telechat review of -04 by Dale R. Worley (diff)
Secdir Telechat review of -04 by Charlie Kaufman (diff)
Assignment Reviewer Wesley Eddy
State Completed
Request Early review on draft-ietf-6lo-deadline-time by Internet of Things Directorate Assigned
Reviewed revision 02 (document currently at 05)
Result Ready w/issues
Completed 2018-09-18
review-ietf-6lo-deadline-time-02-iotdir-early-eddy-2018-09-18-00
The draft is easily readable and can be understood and should be simple to
implement by someone working in the area.

I only have one technical issue that I think should definitely need to be
resolved, and a few small editorial comments.

Technical issues:

- The point of the D-bit is confusing.  It is supposed to indicate whether the
packet MUST be dropped when the deadline is exceeded.  However, if the D-bit is
zero, the document says that a 6LR "MAY" forward the packet anyways.  Since
this uses MAY rather than "MUST" or "MUST NOT", it seems like there should be
some example use case, scenario, or rationale for why an implementer would
choose one way or the other, or how they would include logic to make the
decision when the D-bit is 0.  Fundamentally though, I'm also unsure why a
sender would include a deadline and then set the D-bit to 0 ... is it maybe
something like they still want the packet to be delivered so that network
measurements of current latency or other properties can be measured using the
packet?  If the deadline is missed due to congestion/contention causing
increased delays, then it seems prudent to always drop the packet, in which
case the D-bit would not be needed.

Editorial comments:

- In Section 1, 2nd paragraph, it would probably be good to explain what an
elective RH is and define 6LoRHE as an elective 6LoRH here, before "6LoRHE" is
used in the Deadline-6LoRHE name.

- In Section 1, last paragraph, it would be good to add informative references
for the last two sentences mentioning Bluetooth and Wi-SUN work in this area.

- In Section 4, last paragraph, it might be worth mentioning for clarity that
there are also potentially long serialization delay and MAC layer contention
delays in some of the relevant network types.  These could dominate propagation
and queueing that are mentioned, in some feasible cases.

- The "Length of DT field" and "Length of OT field" descriptions seem a bit
light, although from the examples it is clear, but they could be replaced with
something more clear like "Length of DT field as an unsigned 3-bit integer,
encoding the length of the field in octets, minus one."