Hi Wes, Thanks for your thoughtful review. Responses in-line.
Alia On Mon, Jun 9, 2014 at 1:19 PM, George, Wes <[email protected]> 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, 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. > [Alia] Before the diagram at the end of the paragraph, I've added: " The scope of the data-models used by I2RS extends across the entire routing system and I2RS protocol." and updated the text inside the figure under the block-diagram to say " <--> interfaces inside the scope of I2RS Protocol +--+ objects inside the scope of I2RS-defined behavior <**> interfaces NOT within the scope of I2RS Protocol +**+ objects NOT within the scope of I2RS-defined behavior .... boundary of a router supporting I2RS " > 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. > [Alia] Ok - I added to the end of that paragraph: " Additionally, on March 2, 2014, the IESG issued a statement about Writeable MIB Modules which is expected to limit creation of future writeable MIB modules." > > > > >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. > [Alia] Good catch - added in "flow data" to the "Dynamic System State:" description so that the sentence now reads: "Such state may include various counters, statistics, flow data, and local events. " 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. > [Alia] At the end of Section 6.3, I added "On a routing element, it is critical that there is a way of reviewing (e.g. via the CLI) the changes made by each associated I2RS Agent and its state data. Preferably, this mechanism should use a different priveleged mechanism other than simply connecting as an I2RS client to learn the data. Using a different mechanism should improve traceability and failure management." Thanks again, Alia > 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 >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
