Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-04.txt

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 14 Jan 2008 11:19:48 +0100

Hello Lars, Magnus, James,

Could you consider those two documents for WG LC?

Thanks

Francois

On 19 Dec 2007, at 09:50, Francois Le Faucheur IMAP wrote:

> Hello Lars, Magnus, James,
>
> The updated versions of the two RSVP Proxy" I-Ds have been posted:
> 	* draft-ietf-tsvwg-rsvp-proxy-approaches-03.txt
> 	* draft-ietf-tsvwg-rsvp-proxy-proto-04.txt
>
> All issues are now closed and they reflect the comments received in  
> Vancouver from CCAMP WG.
>
> We would like to request that those go to WG Last Call.
>
> Thanks
>
> Francois
>
> Begin forwarded message:
>
>> From: [email-masked]
>> Date: 18 December 2007 21:15:02 GMT+01:00
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-04.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Transport Area Working Group  
>> Working Group of the IETF.
>>
>> 	Title		: RSVP Extensions for Path-Triggered RSVP Receiver Proxy
>> 	Author(s)	: F. Le Faucheur, J. Manner, A. Narayanan, A. Guillou,  
>> L. Faucheur
>> 	Filename	: draft-ietf-tsvwg-rsvp-proxy-proto-04.txt
>> 	Pages		: 28
>> 	Date		: 2007-12-18
>> 	
>> RSVP signaling can be used to make end-to-end resource reservations
>>    in an IP network in order to guarantee the QoS required by certain
>>    flows.  With conventional RSVP, both the data sender and  
>> receiver of
>>    a given flow take part in RSVP signaling.  Yet, there are many use
>>    cases where resource reservation is required, but the receiver,  
>> the
>>    sender, or both, is not RSVP-capable.  Where the receiver is not
>>    RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
>>    thereby performing RSVP signaling on behalf of the receiver.  This
>>    allows resource reservations to be established on the segment  
>> of the
>>    end-to-end path from the sender to the RSVP Receiver Proxy.   
>> However,
>>    as discussed in the companion document presenting RSVP Proxy
>>    approaches, RSVP extensions are needed to facilitate operations  
>> with
>>    an RSVP Receiver Proxy whose signaling is triggered by receipt of
>>    RSVP Path messages from the sender.  This document specifies these
>>    extensions.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy- 
>> proto-04.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the  
>> body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>> announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-ietf-tsvwg-rsvp-proxy-proto-04.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	[email-masked].
>> In the body type:
>> 	"FILE /internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-04.txt".
>> 	
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <[email-masked]>
>>
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 14 Jan 2008 13:30:37 -0600

Francois

To let you know, I have the ball to do a review of these IDs.

I'll get this done soon.

James

At 04:19 AM 1/14/2008, Francois Le Faucheur IMAP wrote:
>>>From: <mailto:[email-masked]>[email-masked]
>>>To: <mailto:[email-masked]>[email-masked]
>>>Cc: <mailto:[email-masked]>[email-masked]
>>>Title: RSVP Extensions for Path-Triggered RSVP Receiver Proxy
>>>Author(s): F. Le Faucheur, J. Manner, A. Narayanan, A. Guillou, L. Faucheur
>>>Filename: draft-ietf-tsvwg-rsvp-proxy-proto-04.txt
>>>Pages: 28
>>>Date: 2007-12-18
>>>
>>>    flows.  With conventional RSVP, both the data sender and receiver of
>>>    cases where resource reservation is required, but the receiver, the
>>>    allows resource reservations to be established on the segment of the
>>>    end-to-end path from the sender to the RSVP Receiver Proxy.  However,
>>>    approaches, RSVP extensions are needed to facilitate operations with
>>><http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-04.txt>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-04.txt
>>>
>>><mailto:[email-masked]>[email-masked] 
>>>with the word unsubscribe in the body of
>>>the message.
>>>You can also visit 
>>><https://www1.ietf.org/mailman/listinfo/I-D-announce>https://www1.ietf.org/mailman/listinfo/I-D-announce 
>>>
>>><http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
>>>or 
>>><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>><mailto:[email-masked]>[email-masked].
>>>In the body type:
>>>NOTE:The mail server at ietf.org can return the document in
>>>Content-ID: 
>>><<mailto:[email-masked]>[email-masked]>