[Gen-art] Genart last call review of draft-ietf-anima-reference-model-06

Joel Halpern <jmh@joelhalpern.com> Fri, 10 August 2018 01:00 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6A3130FFA; Thu, 9 Aug 2018 18:00:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Halpern <jmh@joelhalpern.com>
To: gen-art@ietf.org
Cc: ietf@ietf.org, anima@ietf.org, draft-ietf-anima-reference-model.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153386283991.28744.9091243291268056328@ietfa.amsl.com>
Date: Thu, 09 Aug 2018 18:00:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/1Xm9It3ZvHu7HrkA8kKQUWUbrLU>
Subject: [Gen-art] Genart last call review of draft-ietf-anima-reference-model-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.27
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2018 01:00:41 -0000

Reviewer: Joel Halpern
Review result: Ready with Issues

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.