Skip to main content

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."