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

2018-08-09 Thread Joel Halpern 
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

.

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.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review Assignments

2018-08-09 Thread Jean Mahoney 
Hi all,

The following reviewers have assignments:

For telechat 2018-08-16

Reviewer   Type  LC end Draft
Stewart Bryant Telechat  2018-08-08 draft-ietf-doh-dns-over-https-13 *

Last calls:

Reviewer   Type  LC end Draft
Tim Evens  Last Call 2018-08-13 draft-ietf-radext-coa-proxy-05
Joel Halpern   Last Call 2018-08-21 draft-ietf-anima-reference-model-06
Jouni Korhonen Last Call 2018-07-09 draft-ietf-netmod-acl-model-19
Ines RoblesLast Call 2018-08-13 draft-york-p-charge-info-08

* Other revision previously reviewed
** This revision already reviewed

Next in the reviewer rotation:

  Christer Holmberg
  Russ Housley
  Erik Kline
  Jouni Korhonen
  Paul Kyzivat
  Matthew Miller
  Francesca Palombini
  Pete Resnick
  Ines Robles
  Dan Romascanu

The LC and Telechat review templates are included below:
---

-- Begin LC Template --
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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments: 

-- End LC Template --

-- Begin Telechat Template --
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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

-- End Telechat Template --


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art