A PCE-Based Architecture for Application-Based Network Operations
draft-farrkingel-pce-abno-architecture-16

This being outside of my domain of focus, I'm curious about the choice to publish this document now. There seem to be a number of places where the possibility that a currently unspecified interface will be defined by I2RS, although I gather that this document is not setting requirements for what I2RS will produce. This jumped out at me especially in the case of the ABNO control interface, which seems like a central component. I was also wondering whether ALTO is already being used in the ways described in this document, and Section 3.9 also caught my eye, as it seemed odd to go ahead with what are essentially placeholder use cases to be filled in later.  

I realize there is a trade-off between describing a high-level architecture to drive specification of the components and identifying how existing components can be fit together, but the combination of all of the above items made me wonder about the utility of writing this architecture down now when it could perhaps change depending on how the missing pieces get specified, implemented, and used.

The security considerations seem to emphasize the sensitivity of the network data involved in ABNO and the corresponding need to protect it, but couldn't the application data involved be equally as sensitive and deserving of protection from unauthorized access? That point seems to be missing in the text.

I agree with Stephen's comments.  In the security considerations section, I'd suggest the word regulate and regulated get changed to "manage" and "managed" as opposed to controlled as it may fir with the text better and has the same intent that Stephen is pointing out.

   This security will include authentication and authorization
   to control access to the different functions that the ABNO system can
   perform, to enable different policies based on identity, and to
   regulate the control of the network devices.

   Considering that the ABNO system contains a lot of data about the
   network, the services carried by the network, and the services
   delivered to customers, access to information held in the system must
   be carefully regulated.

- intro: it's not clear to me who is making these increasing
demands. I wonder because it seems sometimes as if it's
lower layer folks demanding that applications demand stuff
from the lower layers. If that is not correct, and if there
are good references to layer 7+ as the real source of
requirements here I think that'd be a nice addition.

- intro: grooming and regrooming aren't terms with which I'm
familiar and don't occur in 5557 so an explanation would be
good, esp. since the usual connotation of Internet grooming
is very negative. 

- 2.3.2.7: just a note-to-self really, a function such as
this might be a nice place to do some security things (e.g.
certificate transperency like or to post-facto detect a
DH-MitM in some cases). That might need the auditor to not
belong to the network operator though so may be a different
beast really.

- section 5: do you *really* mean regulated? I think you
mean controlled actually.

- section 5: I think you could note the potential for a
network like this (or any network really) to be used to
track users, esp if one can compromise a node that has
access to information that assists in that (e.g.
configuration or keys for wireless devices or something)

- appendix B: I was a little surprised by this given the
kind of document. It also seems odd that there's no pointer
from this to a reference or URL describing findings or
details.