Skip to main content

Telechat Review of draft-ietf-core-cf-reg-update-07
review-ietf-core-cf-reg-update-07-iotdir-telechat-navas-2025-04-18-00

Request Review of draft-ietf-core-cf-reg-update
Requested revision No specific revision (document currently at 09)
Type Telechat Review
Team Internet of Things Directorate (iotdir)
Deadline 2025-05-01
Requested 2025-04-14
Requested by Éric Vyncke
Authors Thomas Fossati , Esko Dijk
I-D last updated 2025-06-09 (Latest revision 2025-05-09)
Completed reviews Genart IETF Last Call review of -04 by Christer Holmberg (diff)
Secdir IETF Last Call review of -05 by Rich Salz (diff)
Iotdir Telechat review of -07 by Renzo Navas (diff)
Assignment Reviewer Renzo Navas
State Completed
Request Telechat review on draft-ietf-core-cf-reg-update by Internet of Things Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/P0p0V9h2kdaS2TlbEww5W44EzzQ
Reviewed revision 07 (document currently at 09)
Result Ready w/nits
Completed 2025-04-18
review-ietf-core-cf-reg-update-07-iotdir-telechat-navas-2025-04-18-00
Disclaimer: I have not been following this document, so I do not have any
context that leads to his current state.

I categorize my review as “Ready w/nits”, because even if I am being too
verbose, most of my comments are about clarification of some terms (lowercase /
capitalisation), and some hints that can lead to clarification of some
sentences. Other than these “nits” with terms; the document is clear,
“negative” examples (section 3) are useful to exemplify what can go wrong, and,
most importantly, the new procedure (Section 4) is quite clear! Thank you for
this work.

------------------
COMMENTS BEGIN
-------------------

Section 2. Lowercase terms seem ok (also used this way in RFC9193), except for
the “content-type” term that is defined and used as “Content-Type” in RFC9193.
Do we want all lowercase terms ? (This term in particular is used only once
later in the document). In any case, the passage
“term->term_rfc9193->definition” can be done unambiguously so not a problem.

Section 3.3, How do we determine if a parameter’s value is valid ? (given an
existing media type parameter)? (We have to track the values on the “Reference”
column on the Media Type register? E.g., for “cose;cose-type=”, I could not
find it on IANA https://www.iana.org/assignments/media-types/application/cose ,
but have to read RFC9052). OK after reading the document, all these cases
(invalid or unknown stuff) will need an “Expert Review” . SUGGESTION: maybe put
a small disclaimer at the beginning of the section? For example: "Unknown or
Invalid values will be detected by a Expert Review".

Section 4. I think we should erase the word "virtual" (unless it has a specific
meaning, which in that case is not clear what that meaning is).

Section 4.3: Commenting just to say: amazing QoL addition!

Section 4.4. In item 1 the term “content coding” is used , but on item 5 the
term “Content Coding” is used, are those different terms or the same? As
defined in Section 2 those terms were all lowercase... if this is the same term
(thus, same meaning) I suggest you should be consistent throughout the document
with the capitalization. If this is a different term.. Well, that is a bit
confusing, and these other terms will need another definition. You can also say
that you are case insensitive in Section 2 (but in any case, I suggest being
consistent with capitalization to avoid all this).

After carefully reading things, I think the term in item 5 is referring to the
“Content Coding” Column in the CoAP Content-Formats IANA Registry, so maybe
explicitly say "If a Content Coding registry value"... I left my initial
comments/doubts about terms with/without capitalization just to make the point
that maybe where there is that subtlety, the text can help the reader with a
bit of signposting (e.g., add "registry value" in the case I mentioned). (Also,
we are not case insensitive, because in this excerpt the term upper/lower-case
made a difference; so explicitly say the terms are case sensitive in Section
2?).