RE: IESG RSVP Recommendation?

["Dana L. Blair" <dblair@cisco.com>]

>   -----Original Message-----
>   From: owner-more@ops.ietf.org [mailto:owner-more@ops.ietf.org]On Behalf
>   Of Gibson, Mark
>   Sent: Thursday, August 23, 2001 9:39 AM
>   To: more@psg.com
>   Cc: mankin@isi.edu
>   Subject: RE: IESG RSVP Recommendation?
>   
>   
>   ...and see the passage:
>   
>   "General issues of scalability, security and policy control as
>      outlined in Section 2 are the subjects of active research and
>      development, ..."

While this is true, we need to look at Section 3 also.  I think
section 3 supports my position of using RSVP within a given
service providers network to facility Application admission 
control and congestion avoidance/control for competing realtime
applications.

thanks,
Dana

>   
>   Doesn't this put things back to the original question: What's 
>   the *current*
>   view (4 years on) of where RSVP should be used? 
>   
>   What, for instance, happened to the RSVP aggregation work being 
>   pursued in
>   the ISSLL wg.
>   
>   Mark
>   (sorry about our standard trailer)
>   
>    -----Original Message-----
>   From: 	Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] 
>   Sent:	23 August 2001 14:02
>   To:	James Kempf
>   Cc:	mankin@isi.edu; more@psg.com
>   Subject:	Re: IESG RSVP Recommendation?
>   
>   
>   Look at RFC 2208.
>   
>     Erik
>   
>   
>   
>   --
>   This communication contains confidential information intended 
>   solely for the use of the individual/s and/or entity or 
>   entities to whom it was intended to be addressed.  If you are 
>   not the intended recipient, be aware that any disclosure, 
>   copying, distribution, or use of the contents of this 
>   transmission is prohibited.  If you have received this 
>   communication in error, please contact the sender immediately, 
>   delete this communication from your system, and do not disclose 
>   its contents to any third party, or use its contents.  Any 
>   opinions expressed are solely those of the author and do not 
>   necessarily represent those of Orchestream Ltd or its group of 
>   companies unless otherwise specifically stated.
>