I await Michael's comments. A few in line responses (marked <jmh></jmh> where I think I may have been misunderstood. I have trimmed the rest. As noted in the elided text, these are all concerned with clarity.


On 8/10/18 1:10 AM, Toerless Eckert wrote:
On Thu, Aug 09, 2018 at 06:00:39PM -0700, Joel Halpern wrote:
Reviewer: Joel Halpern
Review result: Ready with Issues

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?

4.1 is explaining it. In the ACP document its called the Node-ID.

<jmh>I saw 4.1. If naming is intended to be a service provided by the ACP, then figure 2 and the text in section 3.1 apparently should include it. </jmh>

     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

Imho, the reference model text is correct. Just like in the non-autonomic
input (third bullet item), this vendor-redirect/cloud-registrar would
lead to an automatically set up remote ACP peer thats enterred into the
adjacency table.
<jmh>I can't find anything in the bootstrap document redirect section that suggests the behavior you indicate.</jmh>

     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

Hmm.. ACP is an overlay network that tries to match the underlay when
it can (link-local-adjacencies) and that uses remote adjacencies when
it needs to go over non-autonomic parts of the network.

Not quite sure what text to most easily add to make this any clearer..
Any suggestions ?
<jmh>The text mixes both uses of adjacency without distinction. One could seaprate the usage. One could add explanatory text. Something to clarify the situation. </jmH>

     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.

802.1AR as already referenced by ACP
<jmh>My only concern is that it appears to need to be a normative reference here, as it seems to be needed for understanding this document. </jmh>

     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

Both options are architecturally valid and the reference model
does not take sides, even though we would expect that LDevID is
persistent in most cases.

I don't think low-power is the criteria for not to have a persistent LDevID,
almost every tiny IoT device i've seen has some available flash cells.

The security model of nodes without writable persistent storage comes
to mind as use-case for non-persistent LDevID (boot from DVD/RO-Flash
only, power-cycle recreates known "good" state on device).

<jmh>The text as written implicitly requires persistent storage. If the intention is to allow both models (as I would hope) please tune the text in section 3.3.2.

     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.

I had same comment on ACP. I was going to fix it in ACP by saying
"does not need to configure security on any (ANI/ACP) nodes other
than Registrars and other PKI components (CA, CRL-DP,...).

Network can have 10,000 nodes and maybe just 2 registrar/CAs..

     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.

chair hat on:
There can not be a draft covering this yet, because the current
ANIMA charter didn't allow us to do this. We've got individual drafts
lined up for this topic, we just need to get through the rechartering,
we have started the discuss with our AD and wanted to then bring this to
the WG.
<jmh>How can this informational documents say "ASA must ..." if there is no definition of what they must do. If the WG has not addressed this topic, then reword this. Maybe "It is expected that wide deployment in the future will need ..." </jmh>


Anima mailing list

Reply via email to