Subject: [core] draft-ietf-core-senml - Last Call comments

From: Jim Schaad <[email-masked]>
Date: Fri, 22 Sep 2017 22:24:51 -0700

I believe that this document is ready to proceed with some nits.

I am not really setup to do a competent review on the technical aspects of
the document, however they seem to be clear to me.

* Section 4.2 - Update Time: I suggest that the sentence starts w/ "An
optional value in sections that represents the maximum time".  The time
after optional confused me as I initially read this as a time not as a delta
time.  There may also be a requirement here that an actual time value exist
somewhere so that one can compute the absolute time that an update should
occur by.

* Section 4.4 - It is not clear to me that all of the base values in section
4.1 provide all of the information needed in order to resolve.  While I can
infer most of them, I am unclear what to do with Version.

* Section 4.4 - It may be a good idea to indicate in this section that all
base values are to start with the letter b so that if a new base value is
found by a resolver it will know that it has a problem.

* Section 6 - I am sad, but I understand the reasons for the decision, that
Octets are not encoded as binary values.

* Section 6 - It might be a good idea to also provide the example in CBOR
Diagnostic notation.   That is easier to read and gives a better idea of
what the content structure is.

* Section 9 - I have a problem here because in CoAP fragments are not
currently transmitted thus the example in 9.1 is probably not a useful item
if you are trying to reduce the transmission size.  Do you just want to use
a query parameter instead?  If not then you need to provide some additional
explanation.

* Section 12.1 - You might want to include a note for the RFC editor to
reverse the order of note 1 and note 2 as they do not appear in that order
in the table.

* Section 12.2 - I am not clear that the column "XML Type" should refer to
XML.  I assume that this is also the type used for JSON and CBOR.

* Section 14 - You might want to re-iterate the Privacy consideration that
you noted in Section 4.3 when dealing with name assignment.  The section you
are dealing with has a reference for dealing with IPv6, but not for the
other recommended name times.

Jim