I don't think the questions are needed or amendments are necessary. Your right that is seemed to me the same if I forgoten the documents, however, some comment in line :)
On 1/3/13, Thomas Narten <[email protected]> wrote: > I also find the above text unclear/confusing. Alia and I had an > offline exchange, which resulted in the following suggestion: > > In a network, the routing system is the collection of entities, > protocols and processes that collectively build the forwarding > tables that are exported into the entities that constitute the > network's fowarding plane. > > This attempts to say what the "routing system" in general terms while > also being clear about the separation of the data/forwarding plane > from the routing system. I2RS is presumably focussed on the latter. I don't think the charter should explain much about I2RS definitions, I prefered not to define but to state the charter aim and objectives. > > I also don't think its helpful to talk about "The routing system may > be further divided to be an interface over which data traffic is > forwarded". That doesn't seem accurate, as network interfaces > typically just process packets, and I have a hard time seeing a single > interface being considered a "routing system". You misunderstood because you did not read the documents, all explained there. >> "I2RS facilitates real-time or event driven interaction with the >> routing system through a collection of control or management >> protocol-based interfaces." > > I'm OK with this change, but the bigger question I have when reading > the charter (at a general level), is how this "management interface" > differs from what we already have today. E.g., config files. I suspect > one answer is "you can't do what we want to do through the existing > config file mechanisms", but that's only partly helpful and begs the > question of just what is something this effort is intended to do that > can't already be done today. We know every thing could/can be done in past/present/future, but the question is was it standard by IETF, if not then I think it answers your question and the effort should be done. > The charter itself doesn't say anything > like that. It's just silent about why what I2RS is trying to do can't > be done today. Indeed, there is no hint at all about how this might be > done (and the BOF had lots of questions along the lines of "why can't > you use <insert favorite protocol> to do this today?" we cannot do any thing without a WG and we need a charter to have authorisation. > > I'm not sure what to suggest here, but my own sense is that an outside > reader looking at this charter will have a hard time understanding > just what the scope of this effort is and what problem it is trying to > solve. I think I like your idea that *what problem trying to solve* which is a good to mention in the charter. May be some times there is no problem but there is ideas to make better services. The case problems are in ID started as work-in-progress. However, I think the scope is there clear but note mentioned as *scope* (i.e. I named it the charter aim) please read: I2RS facilitates real-time or event driven interaction with the routing system through a collection of 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. Maybe it will be nice to indicate that as: I2RS scope is ......etc. AB _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
