A PCE-Based Architecture for Application-Based Network Operations
Note: This ballot was opened for revision 14 and is now closed.
(Alia Atlas) Yes
(Jari Arkko) No Objection
(Richard Barnes) No Objection
Alissa Cooper No Objection
Comment (2015-01-21 for -15)
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.
(Spencer Dawkins) No Objection
(Stephen Farrell) No Objection
Comment (2015-01-22 for -15)
- 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. - 18.104.22.168: 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.
(Joel Jaeggli) No Objection
Barry Leiba No Objection
(Kathleen Moriarty) No Objection
Comment (2015-01-22 for -15)
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.