Skip to main content

Last Call Review of draft-ietf-anima-reference-model-06

Request Review of draft-ietf-anima-reference-model
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-08-21
Requested 2018-08-07
Authors Michael H. Behringer , Brian E. Carpenter , Toerless Eckert , Laurent Ciavaglia , Jéferson Campos Nobre
Draft last updated 2018-08-09
Completed reviews Rtgdir Telechat review of -07 by Christian Hopps (diff)
Opsdir Last Call review of -06 by Tianran Zhou (diff)
Genart Last Call review of -06 by Joel M. Halpern (diff)
Secdir Last Call review of -06 by Radia Perlman (diff)
Genart Telechat review of -08 by Joel M. Halpern (diff)
Assignment Reviewer Joel M. Halpern
State Completed
Review review-ietf-anima-reference-model-06-genart-lc-halpern-2018-08-09
Reviewed revision 06 (document currently at 10)
Result Ready with Issues
Completed 2018-08-09
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


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

    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

    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 (which then has the necessary normative

    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.