[lamps] Artart last call review of draft-ietf-lamps-lightweight-cmp-profile-14

Robert Sparks via Datatracker <noreply@ietf.org> Fri, 21 October 2022 20:38 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: spasm@ietf.org
Delivered-To: spasm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D22C152594; Fri, 21 Oct 2022 13:38:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-lamps-lightweight-cmp-profile.all@ietf.org, last-call@ietf.org, spasm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.18.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166638471292.38790.9040536555322509835@ietfa.amsl.com>
Reply-To: Robert Sparks <rjsparks@nostrum.com>
Date: Fri, 21 Oct 2022 13:38:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/msD0CJEIXAeQnqDNawoqS28WPKY>
Subject: [lamps] Artart last call review of draft-ietf-lamps-lightweight-cmp-profile-14
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2022 20:38:33 -0000

Reviewer: Robert Sparks
Review result: Ready with Nits

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.