Subject: [6lo] Éric Vyncke's No Objection on draft-ietf-6lo-deadline-time-04: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 15 May 2019 12:08:19 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-6lo-deadline-time-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/

----------------------------------------------------------------------
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)