Dear Wesley, We have posted a the new version (03) of our deadline-time draft , addressing the review comments https://tools.ietf.org/pdf/draft-ietf-6lo-deadline-time-03.pdf Thanks for your valuable inputs and happy to receive further comments if any; Thanks & Regards, Lijo Thomas -----Original Message----- From: Wesley Eddy [mailto:wes@xxxxxxxxxxxxxxx] Sent: 19 September 2018 10:03 To: Iot-dir@xxxxxxxx Cc: draft-ietf-6lo-deadline-time.all@xxxxxxxx; ietf@xxxxxxxx; 6lo@xxxxxxxx Subject: Iotdir early review of draft-ietf-6lo-deadline-time-02 Reviewer: Wesley Eddy Review result: Ready with Issues 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." ------------------------------------------------------------------------------------------------------------ [ 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. ------------------------------------------------------------------------------------------------------------
