Ballot deferred by Alissa Cooper on 2018-05-22.
Summary: Needs 5 more YES or NO OBJECTION positions to pass.
I noted in the different versions the content of section 10 floated between an appendix and as part of the document (current version). Considering Section 10's intro, I agree with Mirja, this content seems more suitable (and will ease the readability) as an appendix. Section 10.5 still says "This appendix..".
Thank you for addressing my DISCUSS concerns so quickly and well. I've cleared. (Actually wrote this a few days back, but forgot to hit the confirm button :- ( ) -- Original DISCUSS for hysterical raisins -- I'm balloting DISCUSS, but I think that this should be relatively simple to address: The document says things like:"Today, the management and control plane of networks typically runs in the global routing table, which is dependent on correct configuration and routing." and "Context separation improves security, because the ACP is not reachable from the global routing table. " The term "global routing table" is widely used and understood to mean the global BGP routing table, or Internet global routing table. I understand that you are using it in the "default VRF" meaning, but I think that it is really important to clarify / disambiguate this the first time you use it. ---------- Thank you very much for writing this document -- it is comprehensive... A rich text version of my review is here: https://mozphab-ietf.devsvcdev.mozaws.net/D3801#inline-4146 , and pasted below for tooling, email, etc. --- draft-ietf-anima-autonomic-control-plane.txt:212 network nodes that is not the ACP, and therefore considered to be dependent on (mis-)configuration. This data-plen includes both the traditional forwarding-plane, as well as any pre-existing control- Nit: data-plane draft-ietf-anima-autonomic-control-plane.txt:508 certificate. This does not require any configuration on intermediate nodes, because they can communicate zero-touch and securely through the ACP. I understand what you are trying to say, but "zero-touch" is not an adverb. draft-ietf-anima-autonomic-control-plane.txt:518 the data-plane is operational, will the other planes work as expected. This is *sometimes* an undesirable dependency, but is usually viewed as a feature (by operational people) -- having the control plane share fate with the dataplane is something that is usually a feature - this drives at least part of the reason that many organizations run OSPF and OSPFv3 - having V4 OSPF relying on v4 dataplane avoids blackholes if the v4 dataplane stops working. (This is sometimes, but less often used as an argument against ISIS). I understand why it is useful in this context, but it would be useful to clarify/make it clear that you understand the subtleties. Also, nit: "is operational, will the" -- the comma feel weird here. draft-ietf-anima-autonomic-control-plane.txt:526 management session is running can lock an admin irreversibly out of the device. Traditionally only console access can help recover from such issues. "only console access or OOB". You may be using "console access" to mean OOB, but much (most?) OOB is now not console based. draft-ietf-anima-autonomic-control-plane.txt:531 Operations Center") such as SDN controller applications: Certain network changes are today hard to operate, because the change itself may affect reachability of the devices. Examples are address or mask I think that this was an editing issue -- you don't "operate" changes. Perhaps "implement"? draft-ietf-anima-autonomic-control-plane.txt:858 o If the node certificates indicate a CDP (or OCSP) then the peer's certificate must be valid according to those criteria. e.g.: OCSP You expand CDP further in the document, but this is the first time it is used. draft-ietf-anima-autonomic-control-plane.txt:994 ACP neighbors. Native interfaces (e.g.: physical interfaces on physical nodes) SHOULD be brought up automatically enough so that ACP discovery can be performed and any native interfaces with ACP I don't have a suggestion, but "automatically enough" doesn't sound right - "automatically configured enough" ? draft-ietf-anima-autonomic-control-plane.txt:1067 In the above (recommended) example the period of sending of the objective could be 60 seconds the indicated ttl of 180000 msec means that the objective would be cached by ACP nodes even when two out of Editing fail -- missing some punctuation or words. draft-ietf-anima-autonomic-control-plane.txt:1933 for reachability. The use of the autonomic control plane specific context eliminates the probable clash with the global routing table and also secures the ACP from interference from the configuration IMPORTANT: The term "global routing table" has a well known meaning in operations -- it is the global BGP table. I strongly suggest using a different term, or having a very clear statement in the terminology section, AND the first time you use it in the document. This will help minimize confusion. draft-ietf-anima-autonomic-control-plane.txt:3081 10.2. ACP (and BRSKI) Diagnostics Just a note that I like / appreciate this section - having guidance on how to troubleshoot is very helpful. draft-ietf-anima-autonomic-control-plane.txt:3416 10.3.2.2. Fast state propagation and Diagnostics "Physical down" state propagates on many interface types (e.g.: When I saw the "physically brought down" I started composing a long soapbox rant on the fact that this will slow down state propagation -- I like that that document anticipates and addresses this. It might be useful to have a pointer in the previous section (like "(see below)" or similar.) draft-ietf-anima-autonomic-control-plane.txt:3482 for 5 seconds to probe if there is an ACP neighbor on the remote end every 500 seconds = 1% power consumption. I believe that this is sufficiently incorrect that you should remove the 1% result (or, better yet the whole last sentence). Various interfaces (especially long reach) take a significant amount of time (and additional power) when bringing up interfaces -- things like DWDM optics and amplifiers sometimes need significant power for heating elements to lock the frequency / wavelength, and so the power consumption is not linear with interface uptime.
1) I would like to see a slightly stronger statement here in section 6.1.3: "The M_FLOOD message MUST be sent periodically. The default SHOULD be 60 seconds, the value SHOULD be operator configurable." Maybe the following instead: "The M_FLOOD message MUST be sent periodically. The default MUST be 60 seconds, the value SHOULD be operator configurable but SHOULD be not smaller than 60 seconds." Or even a MUST for the minimum value is that acceptable for the desired use cases. 2) Also in section 6.5, I would like to seem some rate limiting/pacing: "An ACP node may choose to attempt initiate the different feasible ACP secure channel protocols it supports according to its local policies sequentially or in parallel,..." 3) Sec 6.7.3: How are baseline ACP and constrained ACP nodes defined? 4) sec 6.10.6: "With the current allocations, only 2 more schemes are possible, so the last addressing scheme should consider to be extensible in itself (e.g.: by reserving bits from it for further extensions." Maybe use a normative MUST here: "With the current allocations, only 2 more schemes are possible, so the last addressing scheme MUST be extensible in itself (e.g.: by reserving bits from it for further extensions." 5) I guess section 10 could be moved to the appendix.