[Dime] RE: [NSIS] RE: Diameter QoS Draft: Issue #16, #20, #22
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime 

thanks,
John

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

>-----Original Message-----
>From: nsis-bounces at ietf.org [mailto:nsis-bounces at ietf.org] On 
>Behalf Of ext Hancock, Robert
>Sent: 24 January, 2006 19:30
>To: Tschofenig, Hannes
>Cc: falfano at lucent.com; mccap at lucent.com; Tseno Tsenov; nsis at ietf.org
>Subject: [NSIS] RE: Diameter QoS Draft: Issue #16, #20, #22
>
>hi all,
>
>i haven't re-read the full draft, but checked the issues below.
>
>> -----Original Message-----
>> From: Tschofenig, Hannes [mailto:hannes.tschofenig at siemens.com]
>> Sent: 15 January 2006 21:29
>> To: Hancock, Robert
>> Cc: mccap at lucent.com; falfano at lucent.com; Tseno Tsenov; nsis at ietf.org
>> 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:
>> 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
>
>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?
>
>> 
>> Suggestion:Close
>> 
>> Gating
>> 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?
>
>> 
>> Suggestion:Close
>> 
>> Ciao
>> Hannes
>> 
>
>_______________________________________________
>nsis mailing list
>nsis at ietf.org
>https://www1.ietf.org/mailman/listinfo/nsis
>

_______________________________________________
DiME mailing list
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.