Thanks a lot, Joel MichaelB has the editor pen, so just some quick thoughts as co-author/chair inline. On Thu, Aug 09, 2018 at 06:00:39PM -0700, Joel Halpern wrote: > 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? 4.1 is explaining it. In the ACP document its called the Node-ID. > 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. > 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 ? > 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 > 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). > 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. Cheers Toerless > 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.
