Thanks Adrian, I support including both 1 and 2, but if I need to choose then prefer 1, comments in lines;
On 12/21/12, Adrian Farrel <[email protected]> wrote: > Hi, > > I have ploughed through the emails discussing the charter and come up with > some > minor tweaks. > > 1. "Interface" > There was a strong desire to separate the two meanings of "interface". > However, > the solutions suggested were all rather variable. In fact, the word is only > used > in the first paragraph of the charter, so it seems best to be long-winded > for > the sake of clarity. This leads to: > > == > A routing system is all or part of a routing network. A part of a routing > network may be a single router or a collection of routers. The routing > system > may be further divided to be an interface over which data traffic is > forwarded, > or a collection of such interfaces. AB>Suggest Amend> A routing system SHOULD be in all or part of the routing network. AB> Amend to> The routing system may be further divided by an interface over which data traffic can be forwarded, or by a collection of such interfaces. > > 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 notification) from the routing system while retaining > data > consistency and coherency across the routers and routing infrastructure, > and > between multiple interactions with the routing system. > == AB> replace: between with among > > 2. Include Control Plane Protocols > This got immediate support and leads to: > I think If included we need to define the interface within this plane, separating I2RS protocol and the control operation protocol. > == > A routing system is all or part of a routing network. A part of a routing > network may be a single router or a collection of routers. The routing > system > may be further divided to be an interface over which data traffic is > forwarded, > or a collection of such interfaces. The routing system also includes the > control plane protocols that operate the routers. > AB> Amend> The routing system also includes the operational protocols that are within control plane that operate the routers. > 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 notification) from the routing system while retaining > data > consistency and coherency across the routers and routing infrastructure, > and > between multiple interactions with the routing system. > == > > 3. Rationalise the Use Cases > There was good support in theory (at the BoF) for reducing / focussing the > use > cases., but as I predicted, the rule of thumb is "Cut out other people's > use > cases. Leave mine in." > There were some emails of a generally supportive nature for focussing the > use > cases a bit better, and some suggestions for additional (but focussed) use > cases. > Here is my suggestion based on: > draft-atlas-irs-problem-statement section 3 > draft-keyupate-irs-bgp-usecases > draft-white-irs-use-case-00.txt section 2 > draft-white-irs-use-case-00.txt section 3 > draft-white-irs-use-case-00.txt section 4 > draft-amante-irs-topology-use-cases no objection, as after a year we may recharter :) > == > OLD > - Tightly scoped key use cases for operational use of I2RS. These use cases > will > include at least: > o Interactions with the RIB. > o Association of routing policies with routing state. > o The ability to extract information about topology from the > network. Injection and creation of topology will not be > considered as an initial work item. > > Other use cases may be adopted by the working group only after > milestones > have been added to the charter page. > NEW > - Tightly scoped key use cases for operational use of I2RS. These use cases > will > include at least: > o Interactions with the RIB. Allowing read and write access to the RIB > and to > the policies used to construct the FIB, but no direct access to the FIB. > o Control and analysis of the operation of BGP including the setting and > activation of policies related to the protocol. > o Control, optimization, and choice of traffic exit points from networks > based on more information than provided by the dynamic control plane. > o Distributed reaction to network-based attacks through quickly > modification > of the control plane behavior to reroute traffic for one destination while > leaving a standard mechanisms (filters, metrics, and policy) in place for > other > routes. > o Service layer routing to improve on existing hub-and-spoke traffic > o The ability to extract information about topology from the network. > Injection and creation of topology will not be considered as an initial > work > item. > > Other use cases may be adopted by the working group only after > milestones > have been added to the charter page. > END > == agree > > 4. Rationalise milestones > There was concern that each and every document did not need to be listed in > the > milestones. And it was noted that the chairs (once the WG is running) can > add > milestones as they consider useful. > Additionally, we need to have some proposed dates against the milestones. > That leads to: > Yes preferable we can leave it after in the meetings and discussion while the work and efforts is flowing, so I agree with your suggest. > == > Jul 2013 : Request publication of an Informational document defining the > problem > statement > Jul 2013 : Request publication of an Informational document defining the > architecture framework > Aug 2013 : Request publication of Informational documents describing use > cases > Sep 2013 : Request publication of an Informational document defining the > protocol requirements > Sep 2013 : Request publication of an Informational document defining > encoding > language requirements > Nov 2013 : Request publication of Standards Track documents specifying > information models > Nov 2013 : Request publication of an Informational document providing an > analysis of existing IETF and other protocols and encoding languages against > the > requirements > Dec 2013 : Consider re-chartering +1 for the above, > == > > I have made these changes and updated the draft charter at > http://datatracker.ietf.org/doc/charter-ietf-i2rs/ > Thanks > It is my intention to put this charter to the IESG early in the New Year. +1 with above, > So > please review and comment heartily. > > Thanks, > Adrian > Thanking you AB > > > > > > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
