Jim Schaad
2017-09-23 05:24:51 UTC
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
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