Subject: [NSIS] Diameter QoS Draft: Issue #16, #20, #22

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sun, 15 Jan 2006 22:28:34 +0100

Hi Robert, 

you provided feedback for the Diameter QoS application draft. We would
like to close the open issues based on the draft version -05: 
http://tools.ietf.org/wg/aaa/draft-alfano-aaa-qosprot-05.txt

We created the following issues after your review. We updated the draft
based on your feedback and reflected your comment. 

Two party authorization model
http://www.tschofenig.priv.at:8080/diameter-qos/issue16

Suggestion:Close

Gating
http://www.tschofenig.priv.at:8080/diameter-qos/issue20

Suggestion:Close

Session Identifier
http://www.tschofenig.priv.at:8080/diameter-qos/issue22

Suggestion:Close

Ciao
Hannes

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Nguyen, An P CIV NCS NC2" <[email-masked]>
Date: Tue, 17 Jan 2006 14:12:22 -0500

Hannes,

I don't know if this is the time to raise the authentication issue of
priority users. As far as QSPEC and RMD are concerned, how are resource
priority headers such as ETS and WPS in document
http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-10 be
accomodated in this draft?

Regards,

An 

-----Original Message-----
From: Tschofenig, Hannes [mailto:[email-masked]]
Sent: Sunday, January 15, 2006 4:29 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Tseno Tsenov; [email-masked]
Subject: [NSIS] Diameter QoS Draft: Issue #16, #20, #22

Hi Robert, 

Suggestion:Close

Gating

Suggestion:Close

Session Identifier

Suggestion:Close

Ciao
Hannes

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 23 Jan 2006 15:50:48 +0100

hi an, 

initially i thought you would ask how we the interworking between rfc
3181 alike parameters and the diameter qos document looks like. btw, the
rfc3181 parameters are also carried in the qspec as described in section
7.2.7.1.
 
but now you ask me how the interworking between the priority parameters
defined in draft-ietf-sip-resource-priority-10 and the diameter qos
draft looks like. in fact the parameters lists in 
draft-ietf-sip-resource-priority are also available with the qspect as
described in section 7.2.7.3. 

some time ago we had long discussion on how the
draft-ietf-sip-resource-priority-10 and the rfc 3181 parameters work
together. you can find these discussions entitled with 'Questions
regarding <draft-baker-tsvwg-mlpp-that-works -01.txt>' starting with the
following posting:
http://www1.ietf.org/mail-archive/web/nsis/current/msg03869.html

with regard to the aaa interaction you asked for: no matter which
parameters you use it seems that you need to interact with the aaa
infrastructure in order to determine whether you are allowed to use
these values or not. the policies at the aaa server will indicate
whether the reservation request is successfull or not.

ciao
hannes

7.2.7.3

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 24 Jan 2006 17:29:51 -0000

hi all,

i haven't re-read the full draft, but checked the issues below.

> Sent: 15 January 2006 21:29
> To: Hancock, Robert
> Cc: [email-masked]; [email-masked]; Tseno Tsenov; [email-masked]
> Subject: Diameter QoS Draft: Issue #16, #20, #22
> 
> 
> Hi Robert, 
> 
> you provided feedback for the Diameter QoS application draft. 
> We would like to close the open issues based on the draft 
> version -05: 
> We created the following issues after your review. We updated 
> the draft based on your feedback and reflected your comment. 
> 

in 3.2 the final part of the first paragraph reads:
  "With the 'Two party model' the QoS resource requesting
   entity is authenticated by the Network Element and the authorization
   decision is made either locally at the Network Element itself or
   offloaded to a trusted entity (most likely within the same
   administrative domain).  In the former case no Diameter QoS protocol
   interaction is required."

which i parse as

"In the two party model, the requesting entity is authenticated
by the NE and there are two cases
former) authorization decision is made locally at the Network 
        Element itself
latter) the authorization decision is offloaded to a trusted 
        entity (most likely within the same administrative domain)
In the former case no Diameter QoS protocol interaction is required."

So ... is the Diameter QoS protocol interaction required in the 
*latter* case? Is it in the scope of this document? (And why the
expectation that such an interaction would not cross a domain
boundary?) Or is the entire scenario out of scope?

> http://www.tschofenig.priv.at:8080/diameter-qos/issue20

i think what is still needed (what i was originally confused
about) is a clarification that 'disabled' really means 'packets
are blocked' (if this is what you mean). the origin of my confusion
is that I assumed that the document is about authorising reservations
in a network environment where the default is 'best efforts', whereas
the gating discussion seems to imply an environment where the default
is 'blocked'.

> 
> Suggestion:Close
> 
> Session Identifier http://www.tschofenig.priv.at:8080/diameter-qos/issue22

i think i understand the proposal, but the ABNF is quite confusing.
AFAICT the QoS-Auth-Resources AVP can optionally (syntactically) have a 
Signaling-Session-ID AVP and a Flows AVP, and the Flows AVP can have
a set of IND-Flows AVPs each of which can have any/all of a Flow-Id,
QoS-Filter-Rule and SPI. would it be possible to structure things so
that the fact that Signaling-Session-ID, Flow-ID and the combination
of {QoSFilter-Rule with SPI} were alternatives? (i.e. A|B|C format)?
or is it not that simple?

---

From: [email-masked]
Date: Wed, 25 Jan 2006 13:44:24 +0200

Hi all,

Its fine to discuss some QoS issues for this draft, but since this is a
potential work item for the DiME (Diameter Maintanence and Extentions)
Working Group, perhaps it would be good to have some discussions there.

[email-masked]
https://www1.ietf.org/mailman/listinfo/dime 

thanks,
John

PS - I BCC:ed the NSIS mailing list, to avoid cross-posted replies.

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Hancock, Robert
>Sent: 24 January, 2006 19:30
>To: Tschofenig, Hannes
>Subject: [NSIS] RE: Diameter QoS Draft: Issue #16, #20, #22
>
>hi all,
>
>> We created the following issues after your review. We updated the 
>> draft based on your feedback and reflected your comment.
>> 
>"In the two party model, the requesting entity is 
>authenticated by the NE and there are two cases
>        entity (most likely within the same administrative 
>domain) In the former case no Diameter QoS protocol 
>*latter* case? Is it in the scope of this document? (And why 
>the expectation that such an interaction would not cross a domain
>about) is a clarification that 'disabled' really means 
>'packets are blocked' (if this is what you mean). the origin 
>of my confusion is that I assumed that the document is about 
>authorising reservations in a network environment where the 
>default is 'best efforts', whereas the gating discussion seems 
>to imply an environment where the default is 'blocked'.
>
>> 
>> Suggestion:Close
>> 
>> Session Identifier 
>AFAICT the QoS-Auth-Resources AVP can optionally 
>(syntactically) have a Signaling-Session-ID AVP and a Flows 
>AVP, and the Flows AVP can have a set of IND-Flows AVPs each 
>of which can have any/all of a Flow-Id, QoS-Filter-Rule and 
>SPI. would it be possible to structure things so that the fact 
>that Signaling-Session-ID, Flow-ID and the combination of 
>{QoSFilter-Rule with SPI} were alternatives? (i.e. A|B|C format)?