Hi, Some comments, not in order of importance.
> 2.3. Data Plane Independent Permanent Reachability It's probably worth noting in this section that the ACP does depend on some basics: e.g. layer 2 bridges functioning and intermediate nodes functioning (even if their data plane routing is down). Otherwise it sounds a bit miraculous. Maybe this is also the place to first mention that the ACP may partition when something basic breaks. > 5.1.1. Domain Certificate with ANIMA information ... > An example: > > anima.acp+FD99:B02D:8EC3:0:200:0:6400:[email protected] > > The ACP address MUST be specified in its canonical form, as specified > in [RFC5952], to allow for easy textual comparisons. Er-hum. RFC5952 specifies lower case hexadecimal. > 5.1.2. AN Adjacency Table ... > Where the next autonomic device is not directly adjacent, the > information in the adjacency table can be supplemented by > configuration. For example, the node-ID and IP address could be > configured. I hate this. If we let this camel put its nose in the tent, how can we claim the result is "autonomic"? At the very least, I would to see this (and any other such items) in a separate section with a big red flag on it. Maybe move this point to "6.2. ACP through Non-Autonomic L3 Clouds"? > 5.2.1. L2 topology considerations ... > Predictable scaling requirements for ACP neighbors can most easily be > achieved if in topologies like these, AN capable L2 switches can > ensure that discovery messages terminate on them so that neighboring > AN routers and switches will only find the physcially connected AN L2 > switches as their candidate ACP neighbors. Correct, but since you will soon present GRASP as the discovery mechanism, I think you need to say here that *as a result of this requirement*, such L2 switches need to run L3 (i.e. IPv6) and the ANI software suite (i.e. at least ACP, BRSKI and GRASP). Dumb switches need not apply. > 5.2.3. Discovery with GRASP ... > The name of the GRASP objective to announce/discover the capability > of a neighbor to run the ACP is "ACP". We're now suggesting "AN_ACP" simply so that it's identified as an ANI objective. Not a big deal, just a suggested convention. > The precise > GRASP objective to be used is specified in Section 3 of > [I-D.carpenter-anima-ani-objectives]. That's fine for now. Later we should consider moving the definition into this draft. There's an open question whether we use the Flood or Discover/Negotiate mechanism of GRASP for this. My view is that Flood is the simplest and since it doesn't require any GRASP message from the discovering node, it's marginally less attackable. [I-D.carpenter-anima-ani-objectives] describes both options, but we need to decide. > 5.2.4. Discovery and BRSKY s/BRSKY/BRSKI/ This section needs to use the agreed terminology at https://mailarchive.ietf.org/arch/msg/anima-bootstrap/Iqsosf7pBgOeep4UL0C73mSUSKQ > When an autonomic device is a registrar, it will announce the > registrar function via GRASP in the ACP as the "6JOIN" objective. That name is not settled. I suggest deleting it here; it belongs in the BRSKI spec. (Also, every Join Registrar will also behave as a Join Assistant, so it will also announce the assistant function as a GRASP objective.) > 5.5.5. ACP Security Profiles The MTI for normal nodes is IPsec, but you make dTLS the MTI for constrained devices. That doesn't guarantee interoperability. Or do you mean that constrained nodes MUST support IPsec and dTLS? > Autonomic devices need to specify in documentation the set of secure > ACP mechanisms they suppport. That's very nice but no use; autonomic nodes don't read each other's documentation. What is useful is that a device announces the mechanisms it supports to its peers, e.g. in a GRASP Flood message. > 6. Workarounds for Non-Autonomic Nodes I guess we have to cover this. I would like it to start with a short rant about how awful it is. But more realistically, we have to be very clear that (a) the ACP will come up and run without any of this and (b) the points that have to be configured will be singularities in the AN - they won't recover spontaneously if broken, etc. That's it for now. Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
