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

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 03 Oct 2009 12:21:37 +0100

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)

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 8 Oct 2009 14:42:33 +0200

For memory, the changes from the previous version are:

(i) removed all text about emergency/GETS/etc.,
	i.e. the I-D is purely specifying an RSVP mechanism
	(without discussing "architectures/ services" that
	may make use of it).

(ii) removed references to "calls" and instead talk about "sessions"

(iii) included a statement restricting operations to intra-domain
	("Based on current security concerns, these extensions are
	targeting applicability within a single domain.")

One other thing to add is that no changes have been made to the core
specification concerning RSVP, nor has any been requested by the IESG.
The changes have been in the form of making the draft wholly specific to
RSVP without any other context or background.

Francois

On 3 Oct 2009, at 13:21, Gorry Fairhurst wrote:

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 08 Oct 2009 14:41:50 +0100

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

-- 
Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered in Scotland,
No SC013683.

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 8 Oct 2009 11:06:14 -0400

I fully intend to review the latest versions and submit comments.

However, at the moment I am "off" deal with some aspects of my father's 
estate, and so I probably won't get a chance to read it properly until 
next week.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

Gorry Fairhurst <[email-masked]> 
Sent by: [email-masked]
10/08/2009 09:41 AM
Please respond to
[email-masked]

To
[email-masked]
cc
tsvwg chair <[email-masked]>, tsvwg <[email-masked]>
Subject
[tsvwg] WGLC for RSVP Extensions for Admission Priority {To end: 17th 
October 2009}

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

> (RSVP) Extensions for Admission Priority" (see 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-emergency-rsvp-12.txt
).

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 13 Oct 2009 14:54:50 -0400

First, I want to confirm that Francois's changes are "as advertised", and 
I would like to see the draft approved.

I have come up with a few (mostly grammatical) nits.

The introduction refers to a “single domain”, but section 3 refers to 
“policy boundaries”.  Just a nit, but you might want to clarify the 
distinction between “domain” and “policy domain”.

Section 3, top of page 6
“Session establishment can be conditioned to resource-based and
   policy-based network layer admission control achieved via RSVP
   signaling.”
I don’t understand what “conditioned to” means in this context.  “Based 
on”?

Can you clarify the relationship between this document and 
[I-D.ietf-nsis-qos-nslp] and [I-D.ietf-nsis-qspec].  The versions on line 
have long since expired, but I thought there was an interim NSIS meeting 
where they decided to take out the references to Admission Priority Policy 
Element and Application-Level Resource Priority Policy Element, on the 
grounds that they thought it was slowing down approval of the NSIS 
documents.  What is the current status?

In section 4.1, in the text after the bullet for “o  Adm. Priority 
(Admission Priority): 8 bits (unsigned)” it says

      “*  The admission control priority of the flow, in terms of access
         to network bandwidth in order to provide higher probability of
         session completion to selected flows.”

Since we are talking about the SAME flow, it would be clearer to say
      “*  The admission control priority of the flow, in terms of access
         to network bandwidth in order to provide higher probability of
         session completion to the flow.”

Later down in the same text it says
“Bandwidth allocation models such as
         those described in Appendix A are to be used by the RSVP router
         to achieve such increased probability of session establishment.”

Since there is no clear antecedent to the second “such”, it would be 
clearer to say
“Bandwidth allocation models such as
         those described in Appendix A are to be used by the RSVP router
         to achieve increased probability of session establishment.”

In section 4.1.1
“   The only difference with [RFC3181]…”
Would be better as
“   The only difference from [RFC3181]…”

In section 6, in the paragraph about the merge strategy, the three choices 
are 
“In section 3.1, the present document defines a Merge Strategy field
   inside the Admission Priority policy element.  IANA needs to create a
   registry for this field and allocate the following values:

   o  1: Take priority of highest QoS

   o  2: Take highest priority

   o  3: Force Error on heterogeneous merge”

But the Admission Priority policy element doesn’t have a QoS, so how can 
you merge based on it?  Does the QoS come from some other policy element? 
Am I missing something?

At the bottom of page 16 (still section 6) it says
“A numerical value should be allocated immediately by IANA to all
   existing priority.”
But it should be
“A numerical value should be allocated immediately by IANA to all
   existing priorities.”

Thanks

Janet

To
[email-masked]
cc

best wishes,

Gorry

---

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

Hello Janet,

Thanks for taking the time to do another thorough review.  Comments  
below:

On 13 Oct 2009, at 20:54, Janet P Gunn wrote:

>
> First, I want to confirm that Francois's changes are "as  
> advertised", and I would like to see the draft approved.

Ack.

> The introduction refers to a “single domain”, but section 3 refers  
> to “policy boundaries”.

The sentence in the introduction has been added on Ron's request. I  
believe the intent there was "administrative domain" so I'd propose  
the sentence in the Introduction be updated to:
"Based on current security concerns, these extensions are targeting  
applicability within a single administrative domain."

> Just a nit, but you might want to clarify the distinction between  
> “domain” and “policy domain”.
>
> Section 3, top of page 6
> I don’t understand what “conditioned to” means in this context.   
> “Based on”?

We meant "dependent on the condition that ...".
So I guess it should read :
"Session establishment can be made conditional on resource-based and  
policy-based network layer admission control achieved via RSVP  
signaling."

>
> Can you clarify the relationship between this document and [I-D.ietf- 
> nsis-qos-nslp] and [I-D.ietf-nsis-qspec].  The versions on line have  
> long since expired, but I thought there was an interim NSIS meeting  
> where they decided to take out the references to Admission Priority  
> Policy Element and Application-Level Resource Priority Policy  
> Element, on the grounds that they thought it was slowing down  
> approval of the NSIS documents.  What is the current status?

That's a good catch. I'll drop a note to the NSIS WG to get an update  
on their qspec plans.

>          session completion to the flow.”

Well, flows with a lower Admission Priority will receive lower  
probability, so we can't imply that this flow will necessary get  
higher probability.
The text already says that the encoded value relates to "the flow".
The text seems acceptable to me.

>          to achieve increased probability of session establishment.”

the antecedent is "to provide higher probability of  session  
completion to selected flows", but because it is separated by a few  
sentences, I agree the relationship probably gets lost. So I agree  
with your suggestion.

> “   The only difference from [RFC3181]…”

agreed

>
> In section 6, in the paragraph about the merge strategy, the three  
> choices are
> But the Admission Priority policy element doesn’t have a QoS, so how  
> can you merge based on it?  Does the QoS come from some other policy  
> element?

It comes from other RSVP object (FlowSpec). In plain terms, the merge  
strategy 1 basically says that if you merge a small reservation and a  
big reservation, you take the admission priority of the big reservation.
This is mirroring the merge strategies specified in RFC3181 for  
"preemption".

> “A numerical value should be allocated immediately by IANA to all

Ack.

> Thanks

Thank you.

Francois

> Janet
>
>
> This is a PRIVATE message. If you are not the intended recipient,  
> please delete without copying and kindly advise us by e-mail of the  
> mistake in delivery.
> NOTE: Regardless of content, this e-mail shall not operate to bind  
> CSC to any order or other contract unless pursuant to explicit  
> written agreement or government initiative expressly permitting the  
> use of e-mail for such purpose.
>
>
> [tsvwg] WGLC for RSVP Extensions for Admission Priority {To end:  
> 17th October 2009}
>
>
>
>
>
> Protocol
> 2009.

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 14 Oct 2009 08:29:14 -0400

I take it back. 

 My mind must be going.  I was confusing the NSIS documents with the DIME 
documents.

My deepest apologies for causing confusion.

Janet

Francois Le Faucheur <[email-masked]> 
10/14/2009 05:09 AM

To
Janet P Gunn/USA/CSC@CSC
cc
Francois Le Faucheur <[email-masked]>, [email-masked], tsvwg 
chair <[email-masked]>, tsvwg <[email-masked]>, 
[email-masked]
Subject
Re: [tsvwg] WGLC for RSVP Extensions for Admission Priority {To end: 17th 
October 2009}

Hello Janet,

Ack.

agreed

Ack.

Thank you.

Francois

---

From: ken carlberg <[email-masked]>
Date: Wed, 14 Oct 2009 08:34:21 -0400

Janet,

as you are probably aware, the priority related extensions to the  
Diameter QoS application were removed a while back.  I've had  
discussions with Hannes about the topic, but I tabled the topic until  
we get the priority extension to RSVP draft accepted by the IESG.

-ken

On Oct 14, 2009, at 8:29 AM, Janet P Gunn wrote:

>
> I take it back.
>
>  My mind must be going.  I was confusing the NSIS documents with the  
> DIME documents.
>
> Francois Le Faucheur <[email-masked]>, [email-masked],  
> tsvwg chair <[email-masked]>, tsvwg <[email-masked]>, [email-masked]
> Subject
> Re: [tsvwg] WGLC for RSVP Extensions for Admission Priority {To end:  
> 17th October 2009}
>
>
>
>
>
> Hello Janet,
>