Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Section 2.1.5 talks about use of MPTCP: "DNS naming is set up to provide the ACP IPv6 address of network devices. Unbeknownst to the application, MPTCP is used. MPTCP mutually discovers between the NOC and network device the data-plane address and caries all traffic across it when that MPTCP subflow across the data-plane can be built." However, I'm actually uncertain how this is supposed to work and what "Unbeknownst to the application" should mean. If another address should be signaled to the other host, this needs to be indicated by the application or at least some kind of policy framework above MPTCP. Also MPTCP will by default use both paths simultaneously while still looking like one connection to the application, meaning the application has no control which path is used for which traffic. I guess you can open a second subflow and then configure the first subflow as backup path but I'm not sure if that's what you want (given the application/policy framework will still not know which path is used)..? Please provide more information about what the expected usage scenario is here.
I like this document, and look forward to it being published. However, it caught my attention that there are no Normative References. It seems clear to me that (at least) an understanding of the ACP is necessary to properly achieve the objective of the document: "how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes." I then think that the reference to I-D.ietf-anima-autonomic-control-plane should be Normative.
I am skeptical that there are no normative references at all. Is it reasonable that a reader could skip all the references and still fully understand this document?
The Gen-ART reviewer identified a bunch of nits that should be addressed.
* The first paragraph of Section 2.1.4. is extremely difficult to read and the sentences seem incomplete/malformed. Please consider rewording " ACP does not support IPv4: Single stack IPv6 management of the network via ACP and (as needed) data plane. Independent of whether the data plane is dual-stack, has IPv4 as a service or is single stack IPv6. Dual plane management, IPv6 for ACP, IPv4 for the data plane is likewise an architecturally simple option."
secure ACP was extendable via untrusted routers then it would be a lot more verify the secure domain assertion. Therefore the ACP edge devices are not supposed to redistribute routes from non-ACP routers There's something grammatically wrong here and I can't make sense of this sentence. TLS/DTLS ([RFC5246])/([RFC6347]) with mutual AN-domain certificate authentication - and does not incur new key management. This isn't entirely clear to me. What are the identities that these devices are using to talk to each other? Are they always FQDNs? into IPv4 support for ACP will have a longer term benefit or enough critical short-term use-cases. Support for IPv4-only for ACP is purely a strategic choice to focus on the known important long term I think this probably should say IPv6 only address collision even though there is no central assignment authority. This is helped by the expectation, that ACPs are never expected to connect all together, but only few ACPs may ever need to Nit: no comma between "expectation" and "that" ACP packets can be recognized to come from you, you may need to list your prefixes in multiple of those sites. As I read this, it helps others to list, not yourself, right? Any current and future protocols must rely on secure end-to-end communications (TLS/DTLS) and identification and authentication via This looks normative. Should it be MUST?