> >To assist us with putting this work behind us, please respond to the >following questions: > >http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ >Have you read the problem statement draft? yes >Do you think it is ready to be published as a RFC?
Yes, but with two relatively minor comments: Section 2: It would be useful to clarify the scope of the proposed data model. I realize there’s a separate draft for data model, but since this is the primary draft that one should read before diving into the gory details, some clarity would be helpful. The big diagram includes a lot of interfaces and objects that are "out of scope for I2RS", but it’s unclear to me whether you also mean that all of those would be out of scope when it comes to the data model, or if you actually mean that they are simply out of scope when referring to which interface we’re trying to build between which objects. I think it’s the latter, since you need to represent a much larger range of things in the data model than in the interface, but you may want to be more explicit in the latter half of section 2, as well as replacing “I2RS" with something more descriptive in the diagram to avoid naming confusion since “I2RS” can mean IETF WG/effort OR the actual interface to the routing system and related protocol. Since section 3 discusses MIBs and configuration, a reference to the recent statement about writeable MIBs might also be appropriate here as one more bolster to the need for a different protocol to do this work. > >http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ >Have you read the architecture draft? yes >Do you think it is ready to be published as a RFC? Yes, again with a couple of comments: 1.2 - are we considering flow data as a part of dynamic system state and available to I2RS, or not? Would be useful to clarify, especially since availability of flow data is often limited (not typically stored in large amounts on-box), and similarly to the other stats mentioned, may be available via other sources. 6.2 - I recommend that you explicitly call out the need to be able to review (e.g. via CLI) the changes made by the I2RS agent and its state data without a dependency on the client itself. The simplest implementation case for making onboard CLI and I2RS agents play together is that the router CLI is simply another application that uses the I2RS agent in order to represent the necessary information, but I think that dependency might be problematic. I think what is needed here is a way to verify what is going on with the I2RS agent via separate means, such that if the I2RS agent goes insane, I can use another method to figure out what its particular psychosis might be. It may not be practical to assume that making the onboard CLI a client of the same agent will produce valid results. i.e. I may not get a useful answer if I query the I2RS agent “tell me why you’re insane” but I might be able to figure out what the agent was doing when it went insane if I can get access to the info about what actions it took/what data it manipulated once it went insane, or look directly at its underlying state database without its “help". I think this is a pretty important thing from a traceability and failure management perspective. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
