Hi Benoit, > BLOCK: > > Three points I want to discuss. > > 1. > > I2RS facilitates real-time or event driven interaction with the routing > system through a collection of protocol-based control or management > interfaces. These allow information, policies, and operational > parameters to be injected into and retrieved (as read or by > notification) from the routing system while retaining data consistency > and coherency across the routers and routing infrastructure, and among > multiple interactions with the routing system > > You mentioned multiple management interfaces. Good, because that's a > fact, and will be a fact for many years to come. > Now, I was really after some text taking into account the data > consistency and coherency across the different management interfaces. > Maybe this is covered by the "among multiple interactions with the > routing system", I read multiple times and I'm not sure: I would like to > have clearly spell out. Basically, don't break any existing management > interface. > The problem I want to solve is: a set of API that will be THE way to > interact with the routing system without any consistency with the CLI, > the show commands, a read MIB table, a YANG module. > Note: I'm not dreaming, I actually had this specific discussion.
OK. Added to the end of the paragraph you quoted... The I2RS interfaces will co-exist with existing configuration and management systems and interfaces. > 2. > Same old discussion about framework versus architecture. > So you included the two terms to make me happy? ;-) > > The I2RS working group works to develop a framework and architecture > that will enable specific use cases, and lead to an understanding of the > informational models and requirements for encodings and protocols for > the I2RS interfaces. > > And now, we have a new term: architecture framework > > Jul 2013 : Request publication of an Informational document defining the > architecture framework > > I don't understand how you could have this "architecture framework" > before the use cases? > IMHO, the framework and architecture terms are not suitable. What you're > after is the explanation of the required building blocks in the use case > document(s). > > And then, the framework or architecture (pick up the term you want) will > explain: > to solve the use cases A, B, C, we need the building blocks D, E, F, with > the interfaces G, H, I, the data model J, K, L, and the protocol M. > However, that document will only exist in the next charter We discussed this at some length on voice and agreed to disagree a little. However, to ease this I am adding clarification that the architecture/framework is "high-level" and "describes the basic building-blocks." > 3; > During the BoF, many use cases were discussed. > You asked: do we want to limit the use cases? Answer: yes > You asked: is 3 a reasonable number? Answer: yes > So how many do you have? It's not clear from the bullet points below " - > Tightly scoped key use cases for operational use of I2RS as follows:" As we discussed, the length of the list of use cases has increased, but the breadth of scope has narrowed. This is because we have replaced a few large and wide use cases each with several more narrow cases. We agree that the whole point of making such a list is that it will keep us away from ocean-boiling. We also agreed that I-Ds for other use cases would not be considered by the WG under this charter. Lastly we discussed how many RFCs might result from this list. My answer was that the worst case is 6 (one for each use case), but that it is possible (even likely) that authors would combine their work. It is too early to tell definitively which use cases might end up in a combined document (maybe all, maybe none), and there is nothing to say in the charter except for the existing statement about not adding to the use cases without rechartering. > COMMENT: > > EDITORIAL: > > "Collocated" and "with the with" in > > While processes participating in the routing system are often colocated > with the with local forwarding elements, this isn't a necessary condition. Yup. Thanks. Adrian _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
