Last Call Review of draft-ietf-core-senml-etch-05
review-ietf-core-senml-etch-05-genart-lc-sparks-2019-08-29-00
Request | Review of | draft-ietf-core-senml-etch |
---|---|---|
Requested revision | No specific revision (document currently at 07) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2019-09-02 | |
Requested | 2019-08-19 | |
Authors | Ari Keränen , Mojan Mohajer | |
I-D last updated | 2019-08-29 | |
Completed reviews |
Opsdir Last Call review of -05
by Carlos Pignataro
(diff)
Iotdir Last Call review of -05 by Matthias Kovatsch (diff) Secdir Last Call review of -05 by Christian Huitema (diff) Genart Last Call review of -05 by Robert Sparks (diff) |
|
Assignment | Reviewer | Robert Sparks |
State | Completed | |
Review |
review-ietf-core-senml-etch-05-genart-lc-sparks-2019-08-29
|
|
Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/1D9FZWPn0-tmoLESPYpDXj0chWI | |
Reviewed revision | 05 (document currently at 07) | |
Result | Ready w/nits | |
Completed | 2019-08-29 |
review-ietf-core-senml-etch-05-genart-lc-sparks-2019-08-29-00
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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-core-senml-etch-05 Reviewer: Robert Sparks Review Date: 2019-08-29 IETF LC End Date: 2019-09-02 IESG Telechat date: 2019-09-05 Summary: Ready for publication as a Proposed Standard RFC, but with nits to consider before publication Nits: Since the string "-etch-" is in the media type, it might be nice to say in the document where it came from. I think the text in the interoperability considerations sections of the registrations could be improved. You mean to talk about unrecognized keys, not unrecognized key-value pairs. I also think the body of the RFC should have a very short extensibility section that explicitly says you're doing a similar thing as 8424 section 4.4 and point to that section. I am a little uncomfortable with the "Fragment Identification" section (4) of this document - it feels like a "do what we mean" statement. I don't have text to suggest. It may well be that it will be dead-obvious to an implementer what to do, but it makes me uneasy.