All of my minor edits and a few smallish friendly amendments are at:
https://github.com/anima-wg/autonomic-control-plane/pull/3Michael Richardson <[email protected]> wrote: > I'm reading the -07 version of ACP (because it's been open in a tab Now to the changes in -08: AN "Autonomic Network". A network according to [I-D.ietf-anima-reference-model]. Its main components are Intent, Autonomic Functions and ANI. So, I had an initial problem with this, that it referes to something we have no idea about, "Intent". Then I wondered if this was well defined in the reference, and I find that actually the reference model has no terminology section.... maybe one could consider the entire document a terminology section. But, it seems strange to be definining this way in *this* document. I think that it should end at the first period. If the second sentence is needed, it should go into the reference. On this topic (which is not "ACP document"), I'm concerned about the amount of (*) text in the reference model document! AN Domain Name A string name (typically in a format of a DNS domain name) identifying an Autonomic Network. It is stored in the ACP information field of an ANI devices LDevID. re (typically..) either it's an FQDN (with all the QNAME restrictions and a reference), or it's just a string. Let's decide one way or the other, rather than "typically". I think that there are a number of other terms which should not be introduced definitatively in this document.... 5. Inside the ACP VRF, each node sets up a virtual (loopback) interface with its ULA IPv6 address. I think we should say that it's a /128. section 6.1.2 says "Maintenance" but, it's about AN_join_registrar. I don't think that the AN_join_registrar definition belongs in this document. I agree that some minor bit of text should exist, but I don't think this belongs here. This belongs in BRSKI. Perhaps it got clipped out in editing, but that's a bug. section 6.6: If our devices certificate indicates a CDP or OCSP then the peers certificate must be valid occrding to those (eg: OCSP check across the ACP or not listed in the CRL). {see git for a grammar fix to above} Somewhere, I think that we should be saying that Certificate Distribution Points (CDPs) or OCSP servers (whichever is used) SHOULD be available via the connections inside the ACP. BUT, as those things are usually referenced with names there are some MIF-like isues that I think the ACP document should address: 1) DNS. 2) address preferences. (Homenet's naming architecture is dealing with the same questions, but I think the answers may be different) 6.8.1. GRASP as a core service of the ACP I think that this section is really important. Too important to belong buried in a document about to build secure tunnels for IP traffic. At the least, this belongs prominently in the reference model document. At the largest, it needs a new document with a title like: "The ACP profile of GRASP as a core service" along with 6.8.2. re 6.10.2: -> 8+40+2 = 50 bits. so why in 6.10.3 says, "51 bits" for subscheme. I don't find the rational for the V bit very convincing. I don't think you need any real justification for it. 6.10.4. ACP V8 Addressing Sub-Scheme The sub-scheme defined here is defined by the Type value 1 (one) in the base scheme. I think you mean, "Type value 01 (one)", since there are two type bits. I find the use of 1 confusing, given that we also have the Z bit. You've made me happy with the address definition. I sent some text via pull request to clarify some of the no-artifact choice in RPL. most of the rest of the text looks great to me... (I just learnt that "artefact" was british spelling for artifact.. I guess we just need to pick one or the other.) I'll have to ask Pascal why he suggested: Trickle: Not used. 7.1 --- a pretty important section. One consideration that might be worth doing in a future document is registering a TLV for LLDP (CDP) that could carry GRASP M_FLOOD ACP messages. That would please switch fabric vendors because then making the topologies follow physical would be very easy. LLDP does not get forwarded. I wonder who knows the right IEEE incantations to do this. section 10.1: it seems like it's all been said already. section 10.2 ---> move to an appendix. section 10.3 ---> appendix or cut. I see that it all *WAS* in an appendix. I don't know why you moved it. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
