Subject: [Dime] Diameter QoS attribute draft & Design Guidelines

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 13 Oct 2007 17:50:12 +0300

Hi all,

we receive a few review comments that relate to the Diameter Design 
Guidelines draft. There was at least the following interesting aspect 
that I would like to discuss with the group.

Section 3 of 
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-02.txt 
essentially indicates (in a verbose fashion) what existing Diameter 
applications may use these Diameter QoS attributes.

There was the question why this is at all needed. Essentially, should we 
delete Section 3 from that draft?

In some sense this is a question about extensibility. When you define a 
new AVP then you might want it to be used in every possible application 
or just in particular application where you currently see a need. In 
some sense it is not necessary to list these applications since the 
support for these AVPs is in fact optional. Hence, nothing happens when 
the Diameter client or the Diameter server does not provide support for 
it. When the client does not include any of the defined QoS AVPs then 
nothing happens at the server. If the client includes them and the 
server does not support them then the server will just ignore them and 
the client will not receive the corresponding response. Even the case 
where the client and the server understand different QoS models is 
supported.

So, I guess it might be more reasonable to just delete Section 3 (and 
thereby shorten the draft) and instead provide some description about 
the different "error" cases.

What do others think about this proposal?

Ciao
Hannes

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

---

From: "Mark Jones" <[email-masked]>
Date: Mon, 15 Oct 2007 10:31:20 -0400

Hannes,

I agree with the proposal to remove the command ABNF from this draft.
This draft should minally provide the attribute definitions and stress
their reusability in ALL applications. I have no problem with the
examples in section 6 as they do a good job of explaining the semantic
rules in section 5. Section 7 can also be deleted.

Regards
Mark

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: October 13, 2007 10:50
> To: [email-masked]
> Subject: [Dime] Diameter QoS attribute draft & Design Guidelines
> 
> Hi all,
>

---

From: <[email-masked]>
Date: Mon, 15 Oct 2007 20:31:01 +0200

Hmmm.. I think I could be OK removing sections 3 and 7. However, then
some more text is definitely needed to explain e.g. the intended use
of QoS-Capability AVP. 

Cheers,
	Jouni

> From: Mark Jones [mailto:[email-masked]] 
> Sent: Monday, October 15, 2007 5:31 PM
> To: Hannes Tschofenig; [email-masked]
> Subject: RE: [Dime] Diameter QoS attribute draft & Design Guidelines
> 
> 
> Hannes,
> 
> This draft should minally provide the attribute definitions 
> and stress their reusability in ALL applications. I have no 
> problem with the examples in section 6 as they do a good job 
> of explaining the semantic rules in section 5. Section 7 can 
> also be deleted.
> 
> Regards
> Mark
> 
> > In some sense this is a question about extensibility. When 
> you define 
> > a new AVP then you might want it to be used in every possible 
> > application or just in particular application where you 
> currently see 
> > a need. In some sense it is not necessary to list these 
> applications 
> > since the support for these AVPs is in fact optional. 
> Hence, nothing 
> > happens when the Diameter client or the Diameter server does not 
> > provide support for it. When the client does not include any of the 
> > defined QoS AVPs then nothing happens at the server. If the client 
> > includes them and the server does not support them then the server 
> > will just ignore them and the client will not receive the 
> > corresponding response. Even the case where the client and 
> the server 
> > understand different QoS models is supported.
> >