Wes, Thanks for taking the time to supply your review.
On Mon, Jun 09, 2014 at 01:19:58PM -0400, George, Wes wrote: > > > >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, The way I've interpreted the diagram is basically: - I2RS defines the client and agent and the interactions (protocol) - The Agent, by necessity, interacts with system components in a black-box implementation-specific fashion. While I understand you're looking for "where does a data model box fit into the diagram", I'm not sure there's enough flexibility in the ASCII diagram to cover that. :-) If this were UML (which would balloon the diagram an order of magnitude), we'd have Interface lollipops all over the place and even then, that's probably the best we'd have for the high level description. > 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. I think it's meant to cover both cases: Within the scope of the WG effort and also protocol interactions. > 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. I agree. Authors, would you please add an appropriate reference? The URL is: http://www.ietf.org/iesg/statement/writable-mib-module.html > >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. Flow data isn't specifically in-scope to chartered work - today. When the Working Group was formed, the ADs realized that we could easily take on a massive amount of work and thus dilute the attention of the group. Today we have a charter with a limited number of cases: http://datatracker.ietf.org/wg/i2rs/charter/ Once we've gotten some traction on those cases, I suspect a re-chartering to cover such things can occur. > 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. [Please note: Discussion, not necessarily disagreement.] I think there's a few challenges with this. The biggest one is that no matter how carefully we try to word such an architectural requirement, we're going to end up making demands on implementations that either will be difficult to standardize or perhaps even impossible. For what it's worth, this isn't much uglier (and probably is a case that brought this to mind for you) than configuration state imposed by SNMP rather than the CLI. Configuration constructs in SNMP may not have good mappings to those in the CLI and vice versa. A trivial comparison might be if your I2RS agent was implemented by doing CLI translation, then it might be possible to do CLI comparisons. But if it's not, such comparison may be hard. Given the above, what would you suggest? I realize what we want is a way to troubleshoot, but I'm not sure there can be any specific recommendation that will span the architectures well enough to be standardized. -- JeffO _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
