Re: [irs-discuss] Rough Draft IRS Charter

On Nov 4, 2012, at 1:40 PM, Ross Callon <rcallon@juniper.net> wrote:

> Speaking only for myself as an individual: 
> 
> I agree that this paragraph of the draft WG charter is a problem. For one thing the definition of "Slow Path" and "Fast Path" are not clear, and overlap with implementation issues as well as other issues. 
> 
> One option would be to just drop this paragraph. To me the charter hangs together fine without it. 

I personally do not find it offensive, but if it clears things up, let's loose it.

> 
> One alternative: Do we want to say something along the lines of "whatever solutions are selected by the WG will not preclude "fast path" low-overhead access to the routing system"? This would encourage the WG to think about what is needed to allow low-overhead access to data in the routers (both setting and reading), but would not in the charter specify what actually needs to be done to allow this. 

I don't like the language of "will not preclude".  it's a bit of a double negative to me. something like "will seek to reuse or develop a protocol that achieves the requirements of low-overhead, etc...  seems more flexible and precise to me at the same time.

Tom 

> 
> Ross
> 
> -----Original Message-----
> From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On Behalf Of Russ White
> Sent: Monday, October 22, 2012 1:50 PM
> To: irs-discuss@ietf.org
> Subject: Re: [irs-discuss] Rough Draft IRS Charter
> 
> 
> I think this has already been brought up on the list once before, but
> I'd just like to repeat my concerns on it:
> 
> ==
> Thus, the IRS is a "fast path" that can be used to program routing and
> policy state in a router using operational paradigms familiar to
> operators of traditional distributed devices. This differs from the
> programmatic "slow state" that is commonly a device's configuration
> interface because those mechanisms impose many transactional mechanisms
> and requirements, that may slow down the interaction.
> ==
> 
> Describing the CLI or other existing interfaces as the "slow path," and
> the proposed as the "fast path," is problematic. First, it implies that
> there is a specific path already available into all control plane
> devices, and that single path is "too slow," for some meaning of "too
> slow." Second, it implies, from the start, that we need new path, rather
> than a possible structure around existing paths that we can use to make
> sense of the routing system as a whole.
> 
> I think 2a needs to be better defined so it doesn't overlap with 2c, or
> 2c needs to be made a part of 2a in some way (?).
> 
> Thanks!
> 
> Russ
> 
> 
> 
> -- 
> <><
> riwhite@verisign.com
> russw@riw.us
> _______________________________________________
> irs-discuss mailing list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 
> 
> _______________________________________________
> irs-discuss mailing list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 