[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
- To: <robert.hancock at roke.co.uk>, <hannes.tschofenig at siemens.com>
- Subject: [Dime] RE: [NSIS] RE: Diameter QoS Draft: Issue #16, #20, #22
- From: john.loughney at nokia.com
- Date: Wed, 25 Jan 2006 13:44:24 +0200
- Cc: falfano at lucent.com, mccap at lucent.com, dime at ietf.org, tseno.tsenov at gmail.com
- List-archive: <http://www1.ietf.org/pipermail/dime>
- List-help: <mailto:dime-request@ietf.org?subject=help>
- List-id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
- List-post: <mailto:dime@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
- Sender: dime-bounces at ietf.org
- Thread-index: AcYaC85mJCwfhNw9TCa7JEZv72INhgG/AmUAACcmacA=
- Thread-topic: [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.