[i2rs] I2RS charter

["Adrian Farrel" <[e-mail]>]

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.

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.
==

2. Include Control Plane Protocols
This got immediate support and 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.  The routing system also includes the
control plane protocols 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
==
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
==

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:

==
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
==

I have made these changes and updated the draft charter at
http://datatracker.ietf.org/doc/charter-ietf-i2rs/

It is my intention to put this charter to the IESG early in the New Year. So
please review and comment heartily.

Thanks,
Adrian