Subject: Re: [tsvwg] WGLC for RSVP Extensions for Admission Priority {To end: 17th October 2009}

From: "P O'Hanlon" <[email-masked]>
Date: Tue, 13 Oct 2009 15:29:07 +0100

I've taken a look at the draft and it seems reasonable for use in
suitably RSVP enabled environments.

One minor issue is that I imagine that end-systems shouldn't need to
be able to directly copy the SIP RHP into an  RSVP message ( as
mentioned in Sect 3 para 3) - I imagine this could also be done by
some gateway or proxy?

There a couple of typos:
section 3 (page 7): 2nd last para: priotized => prioritized
section 5.2 (page 14): para 1: teh => the

Cheers,

Piers O'Hanlon

> I haven't seen any notes to the list on this draft.
>
> Does anyone apart from the authors think this version is ready to publish? Do you have any other feedback? - Please
> send comments to the list.
>
> best wishes,
>
> Gorry
>
> Gorry Fairhurst wrote:
>>
>>    This email announces the beginning of a working group last call for draft-ietf-tsvwg-emergency-rsvp-12.txt,
>> "Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority" (see http://www.ietf.org/internet-drafts
>> /draft-ietf-tsvwg-emergency-rsvp-12.txt).
>>
>>   The draft history is recorded at:
>>   https://datatracker.ietf.org/idtracker/draft-ietf-tsvwg-emergency-rsvp/
>>
>>     This document was returned to the WG after IESG review, and has been updated. It is now thought by the authors
>> to be ready to proceed to be published as a Proposed Standard. Please send any comments to the TSVWG list.
>>
>>    The last call will run for two weeks, ending Monday, 17th October 2009. Emails saying "I support" or "I don't
>> support" are also most helpful in judging the consensus.
>>
>>    Gorry Fairhurst
>>     (TSVWG Chair)
>>
>>
>> --
>> Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
>> The University of Aberdeen is a charity registered in Scotland,
>> No SC013683.

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 14 Oct 2009 09:57:58 +0200

Hello,

> suitably RSVP enabled environments.

thanks for the feedback.

> mentioned in Sect 3 para 3) - I imagine this could also be done by

Where the end-system is RSVP-capable and RSVP usage is secured (e.g.  
by RSVP Authentication and/or Integrity object inside RSVP Policy Data  
object), I would expect the endpoint to populate the the "Application- 
Level Resource Priority Policy Element" in addition to the "Admission  
Priority Policy Element" (at least when the application level priority  
is non-default). Now, as you said there are scenarios where RSVP would  
be initiated by proxy/gateway/SBC (instead of the end-system) and then  
the "Application-Level Resource Priority Policy Element"  would be  
populated by that device.

> section 5.2 (page 14): para 1: teh => the

Noted.

Thanks

Francois
>> Does anyone apart from the authors think this version is ready to  
>> publish? Do you have any other feedback? - Please
>>>   This email announces the beginning of a working group last call  
>>> for draft-ietf-tsvwg-emergency-rsvp-12.txt,
>>> "Resource ReSerVation Protocol (RSVP) Extensions for Admission  
>>> Priority" (see http://www.ietf.org/internet-drafts
>>>    This document was returned to the WG after IESG review, and has  
>>> been updated. It is now thought by the authors
>>> to be ready to proceed to be published as a Proposed Standard.  
>>> Please send any comments to the TSVWG list.
>>>
>>>   The last call will run for two weeks, ending Monday, 17th  
>>> October 2009. Emails saying "I support" or "I don't