Skip to main content

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.