Last Call Review of draft-ietf-lamps-lightweight-cmp-profile-14
review-ietf-lamps-lightweight-cmp-profile-14-artart-lc-sparks-2022-10-21-00
Request | Review of | draft-ietf-lamps-lightweight-cmp-profile |
---|---|---|
Requested revision | No specific revision (document currently at 21) | |
Type | Last Call Review | |
Team | ART Area Review Team (artart) | |
Deadline | 2022-10-24 | |
Requested | 2022-10-10 | |
Authors | Hendrik Brockhaus , David von Oheimb , Steffen Fries | |
I-D last updated | 2022-10-21 | |
Completed reviews |
Dnsdir Last Call review of -14
by David Blacka
(diff)
Genart Last Call review of -14 by Joel M. Halpern (diff) Artart Last Call review of -14 by Robert Sparks (diff) Intdir Telechat review of -15 by Sheng Jiang (diff) Iotdir Telechat review of -15 by Niklas Widell (diff) |
|
Assignment | Reviewer | Robert Sparks |
State | Completed | |
Request | Last Call review on draft-ietf-lamps-lightweight-cmp-profile by ART Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/art/X1dALDfl8H64T_2ZPAPw0dbOOjM | |
Reviewed revision | 14 (document currently at 21) | |
Result | Ready w/nits | |
Completed | 2022-10-21 |
review-ietf-lamps-lightweight-cmp-profile-14-artart-lc-sparks-2022-10-21-00
Summary: Ready with nits for publication as a Proposed Standard RFC Early warning to the ADs - a thorough review of this document would require familiarity with many large bodies of work. This document profiles a large framework. As a profile it tightens requirements rather than creates new behavior. I found no new ART-specific concerns introduced by this document. I am _not_ familiar enough with the space to have spotted whether the document unintentionally allows behavior that the framework it is profiling would not. I have a few nits I would like the WG to consider: The last paragraph of 3.7 does not parse. I think I can guess at the intent by inferring commas, but please simplify the sentences instead. The last sentence of the 4th paragraph of section 2 (just before Figure 1) is unnecessary. Please just delete it. Why are the last two paragraphs in section 2 present? Consider just removing them. If they need to stay, consider a separate section that explains why you are discussing things that do not fit the architecture described in this document. The requirement blocks at, e.g., page 16 are dense, and useful as a pocket-reference kind of collection. But they appear without introduction, and require some thought to infer the structure. Consider a few sentences of introduction. Also, they use PROHIBITED as if it were a 2119 keyword - where is it defined? The EE state machine is confusing. '+' means different things in different parts of the diagram. In some places its a union of paths. At others, it is a decision point. In one case, it is intended to be edges passing over each other (consider using something like -)- instead). There is one spot that makes no sense at all that I can guess at: in the bottom line between the join to get to "end" and the corner at the lower right edge. What is it trying to say? To make sure - The note in the 4th to last paragraph of 4.1 uses a pattern of text that is often a relaxation of a requirement in some other document. Is it in this case? In section 5.2, why are you calling out that a forwarding agent might store data, or traverse a network boundary. These aren't helping clarify the profile. How are they different from saying "might change the state of a blue LED"? The rest of the discussion should be considered to see if it's really necessary for the purposes of this document. In 5.2.2 "described in for central key generation" does not parse. Micronit: RFCCCCC does not appear anywhere except the RFC Editor note.