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.
Yours,
Joel
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
readers.
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
requiring.)
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>
Cheers
Toerless
