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.