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-anima-reference-model-06
Reviewer: Joel Halpern
Review Date: 2018-08-09
IETF LC End Date: 2018-08-21
IESG Telechat date: Not scheduled for a telechat

Summary: The document is ready for publication as an Informational RFC.  Clarity would be improved if the minor issues below were addressed.

Major issues: N/A

Minor issues:
    Section 2 includes "naming" in the list of services the ANI provides.  Which surprised me.  But then section 3 does not include "naming" in the list of services of the ANI in Figure 2 of section 3.1?

    In section 3.2, in the second paragraph on where adjacency information comes from, the text of the second bullet refers to vendor redirects.  While I understand that those are an important part of the system information, they do not appear to create an adjacency?  If they do, then the term adjacency needs to be better explained in this section.  The first bullet in the next list says the same thing.  My best guess is that adjacency sometime means actual topological adjacency, and sometimes means a more general form of adjacency.  As written, I think it will confuse readers.

    IDevID (referenced in section 3.3.1 at least) appears to be a normative reference.  Devices supporting the Anima Reference Model are required to support that, so understanding how to do so seems necessary for understanding this specification.

    Does section 3.3.2 intend to mandate that devices have persistent storage for the LDevID?  Or is it trying to say that on power cycle it stays in Enrolled state if it retains its LDevID, but goes back to the Factory default state if not?  (Given that folks have repeatedly said that these may be low power devices, I think we need to be clear about what we are requiring.)

    Section 5 starts by saying that the administrator does not have to configure security.  In the very next paragraph it says that a PKI must be in place.  That clearly requires configuring some security properties.  Please reword.

    Section 6.2 says that all ASA must "follow the same operating principles".  The general guideliens of what these must cover is then given.  It is appropriate that this document does not specify the detailed behavior.  That would go in a standards track document.  But there is no reference to a draft covering that.  So we have text saying that all ASA must follow "something", but no reference as to the content of that "something".  Is this a real requirement?  If so, it appears to be unmeetable.

Nits/editorial comments: 
    In section 3.2, why would / could an adjacency table track "validity and trust of the adjacent autonomic
   node's certificate" if all transactions have to verify that separately anyway?  Why mention it here?

   In the next to last bullet of the second bulleted list of section 3.2, the text states that the node will start a "join assistant" ASA.  Could we have a forward reference to 6.3.1.2 (which then has the necessary normative reference)?

    The first use of LDevID in section 3.3.1 should have a forward reference to the definition (which I think is section 5.2.)

    Section 3.3.2 in defining when a device is in the Enrolled state says that it in the Enrolled state if it has an LDevID.  As far as I can tell, the added constraint is that it is not currently a member of an ACP.  The text should include that.

    The third paragraph of section 6.1 refers to the Autonomic nodes and the ASAs as "self-aware".  I do not know what meaning is being ascribed to that phrase.  The usage does not seem to correspond to any meaning I can understood.  Can we just remove the sentence?  (I suspect that the intention is to lead to the fact that the functions can advertise their capabilities, and negotiate them.  We don't need the sentence as grounding for that.)

    While I appreciate the reference to SUPA in section 7.2, the working group having been terminated by the AD makes this a difficult topic for people to find.  Presumably, PCIM should be an actual reference to the relevant RFC.

    Personal opinion: Section 8 on coordination is too hypothetical to be useful to a reader of this document.  I think it is better removed.