Hi, Adrian (and i2rs gang), and thanks for the response. > The subject of the interfaces
Yes, that's what I was asking about. > is some lump of stuff that decides to poke the > routing system. In the architecture (I-D) the subject end of the interface is > called the I2RS Client and serves one or more "applications". We got a bit > hung > up about what constitutes an application: is it, for example, a P2P streaming > application, or is it a tool that is responsible for shaping the network? In > the > end, the answer appeared to be "yes". I would feel happier if some sense of that could be in the charter (but see below). In general, when we propose creating an interface to X, we have some idea of who or what we want to be using that interface (the subject, as you say). I understand the use cases document will go into that in much more detail, but I'd be happier if the charter said *something* about it. I don't know whether you're talking about having a data center's operation & management system using the interface, having a web server that sits in a customer's office using the interface, or having a web browser that runs in an end-user's iPad using the interface. If the answer really is, "Yes, all of those," then a few words in the charter should be possible, no? "This interface is expected to be used by systems as diverse as a data center's operation/management system, a web server, and a peer-to-peer streaming application. The working group will provide details of these and other applications as it develops its use cases." Perhaps something like that could be added to the paragraph that begins "I2RS facilitates real-time or event driven interaction with the routing system"? > | We're not trying to define what it is that wants to interact with the > | control plane in this way, only to provide an interface for any such > | processes. The use cases point us to examples where these interactions > | are defined without identifying what the off-board processes actually > | look like. I won't block this further, but I really think that leaving out *all* explanation of this makes for a charter that will be hard for people who are not already familiar with what you're doing to read and understand. The point here isn't to rein in the use cases (I'm not asking for that and wouldn't want that), but to make things clear to someone reading the charter. I'll clear the block and put what remains into a comment. Barry _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
