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

["Tschofenig, Hannes" <hannes.tschofenig at siemens.com>]

hi john, 

you are certainly right. sorry for initiating these discussions on the nsis list only. 
we should move them all to the recently created dime list. 

ciao
hannes 

> -----Ursprüngliche Nachricht-----
> Von: john.loughney at nokia.com [mailto:john.loughney at nokia.com] 
> Gesendet: Mittwoch, 25. Januar 2006 12:44
> An: robert.hancock at roke.co.uk; Tschofenig, Hannes
> Cc: falfano at lucent.com; mccap at lucent.com; 
> tseno.tsenov at gmail.com; dime at ietf.org
> Betreff: 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