I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-6lo-deadline-time-03 Reviewer: Dale R. Worley Review Date: IETF LC End Date: 2018-12-24 IESG Telechat date: unknown Summary: This draft is on the right track but has open issues, described in the review. Major issues: 1. In regard to the TU field of the header: TU (2 bits) : Indicates the time units for DT and OT fields 00 : Time represented in microseconds 01 : Time represented in seconds 10 : Network ASN 11 : Reserved Note that to define DT and OT, we need to specify not only a time unit, but the instant of zero time. Network ASN has a zero time defined by the network, but for the other two choices, the zero time is not specified by this document. Perhaps it is intended that any "time-synchronized network" necessarily defines a zero time and that is being referenced here. If that is so, it should probably be made explicit. Indeed, it is probably worth going farther: The 10 value is only meaningful in 6TiSCH networks. So really, the interpretation of TU is scoped to the underlying network technology and the definition(s) of time it provides. The defintion of TU in this document should be something like this: TU (2 bits) : Indicates the time scale for DT and OT fields Values depend on the underlying network technology. For 6TiSCH networks: 00 : Reserved 01 : Reserved 10 : Network ASN 11 : Reserved Values in other networks are out of scope of this document. 2. I'm surprised that the OT value is represented as an absolute value from the time-base used for the particular Deadline-6LoRHE, rather than as an offset before the DT. The difference DT - OT will typically be much smaller than OT itself, so if O = 1 and OT is present, using a difference would usually shorten the header. This change clearly isn't necessary for correctness, but it seems like a significant efficiency gain, as after 1 year, a 10 msec ASN with have values nearing 2^32, but DT - OT may remain less than 2^8. Nits/editorial comments: Abstract 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. It's not clear to me how much "over constrained networks and operate within time-synchronized networks" adds to this sentence. True, this header requires that nodes have a common sense of time, but does that require a "time-synchronized network"? (OTOH, perhaps that is what "time-synchronized network" *means*, but I don't know that.) And while 6LoWPAN is expected to be operated across a constrained network, a constrained network isn't a requirement for its use. OTOH, perhaps what you mean is that the header is designed for use over constrained networks, i.e., it is bit-efficient. In that case, I'd relocate the phrase to "... delivery deadline time for data packets, designed for use over constrained networks." 1. Introduction ... compression schemes for RPL routing (source routing) operation [RFC6554], ... It might be helpful to define "RPL". I think better wording would be "compression schemes for [RFC6554] RPL routing", or "compression schemes for RPL routing using [RFC6554]". The draft [I-D.ietf-roll-routing-dispatch] 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. I think these two sentences could be clarified along these lines: This document specifies a new Deadline-6LoRHE type for the Elective 6LoWPAN Routing Header Type, so that the deadline time of data packets can be included within the 6LoWPAN routing header. RFC 8138 [formerly ietf-roll-routing-dispatch] 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 also specifies handling of the deadline time when packets traverse through time-synchronized networks operating in different timezones or distinct reference clocks. Perhaps s/traverse through/traverse between/. Time synchronization techniques need not be mandated by this specificiation. "are not mandated" would be better -- "need not be mandated" sounds like a (lack of) requirement for the document itself. Or use the conventional "Time synchronization techniques are outside the scope of this document." A 6TiSCH network has been used to describe the implementation of the Deadline-6LoRHE, but this does not preclude its use in scenarios other than 6TiSCH. Probably s/has been used/is used/. BLE mesh time synchronization is also being recently explored by the Bluetooth community. s/is also being recently explored/is being explored/ -- "recently" implies that the action has ended before the present. 2. Terminology This document uses terminology consistent with the terminology used in [RFC6550] and [I-D.ietf-6tisch-terminology]. I think you mean that it "uses the terminology defined in ..."; to say it is "consistent with" can mean just that this document's terminology does not conflict with that of other documents. Also, in this document, the terms "expiration time", "delivery deadline time", and "deadline" are used interchangeably with the same meaning. It's best to use only one term for a single concept. 3. 6LoRHE Generic Format o Type: Type of the 6LoRHE. You should add that this value is defined in section 7. 4. Deadline-6LoRHE I think Figure 2 could be made more informative by making the transit out on network TZ3 explicit and by realigning the blocks of values. Note that I've shifted the diagram 3 spaces to the left to obtain room for these changes. TZ1 TZ2 TZ3 T1A=0| | | |---- D1=100 | | | \ | | | \ | | | \ T1D=100 |T2A=1000 | | -------->|----- D2=400 | | | \ | | | \ | | | \ T2D=1400 | T3A=5000 | | ------------------->|----------> | | | v v v D = 0 D = T1D-OT D = T2D-OT = 100-0 = 1400 - 900 = 100 = 500 [= (D1 + D2)] OT = T1A-D OT = T2A-D OT = T3A-D = 0 = 1000-100 = 5000 - 500 = 900 = 4500 5. Deadline-6LoRHE Format 6LoRH Type: TBD This should have a reference to section 7. 6.1. Scenario 1: Endpoints in the same DODAG (N1) Figure 5 could be made a bit clearer (and figures 6 and 7 modified similarly): +-------+ ^ | 6LBR | | | | | | | +-------+ | Upward | / /| \ | Downward routing | (F) / | \ | routing | / \ (C) | (D) | | / \ | | / |\ | | (A) (B) : (E) : R | | /|\ | \ / \ | | S : : : : : : v [END]