Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)
draft-ietf-anima-stable-connectivity-10
Yes
(Alvaro Retana)
(Terry Manderson)
No Objection
(Adam Roach)
(Alia Atlas)
(Deborah Brungard)
(Kathleen Moriarty)
(Spencer Dawkins)
Note: This ballot was opened for revision 07 and is now closed.
Alvaro Retana Former IESG member
(was Discuss)
Yes
Yes
(for -08)
Unknown
Terry Manderson Former IESG member
Yes
Yes
(for -07)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(for -07)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -07)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2018-01-11 for -07)
Unknown
The Gen-ART reviewer identified a bunch of nits that should be addressed.
Ben Campbell Former IESG member
No Objection
No Objection
(2018-01-10 for -07)
Unknown
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?
Deborah Brungard Former IESG member
No Objection
No Objection
(for -07)
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
(2018-01-10 for -07)
Unknown
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?
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -07)
Unknown
Mirja Kühlewind Former IESG member
(was Discuss)
No Objection
No Objection
(2018-02-09)
Unknown
Thanks for addressing my discuss by rather describing requirements for the transport than scratching out an MPTCP-based solution! I like the new text! Also thanks again to Yoshi for the TSV review!
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -07)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(2018-01-10 for -07)
Unknown
* 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."