Subject: [Dime] Diameter QoS Application

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 30 Oct 2008 15:14:07 +0200

Dan made a good comment in his review of the QoS parameter document: 

>3. This document will trigger again the issue of exceeding the 
>AAA scope of DIAMETER as described by RFC 3588, raised in a 
>number of previous occasions, last by Brian Carpenter in his 
>GenART review for draft-sun-dime-itu-t-rw. I suggest to put 
>text in the Introduction section mentioning the issue of scope 
>and referring to rfc3588bis as an Informational Reference.

dime-qos-parameters-06.txt does not raise this issue and the same is
true for http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-attributes/. 

However, when used in
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt
then there are again the same issues as previously raised already. 

As such, I suggest that the group helps Dong with his document
(draft-sun-dime-itu-t-rw) since the same issue will come up again. 

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

---

From: "Sun, Dong \(Dong\)" <[email-masked]>
Date: Thu, 30 Oct 2008 16:35:29 -0500

Hannes, All,

Thanks for bringing up this issue. Indeed, we need a quick reaction on
this matter. It is now affecting the work progress (holding on the
publication of approved Recommendation) in both ITU-T and ETSI TISPAN
since there are a couple of interface spec (i.e. ITU-T Rw in the RACF
and TISPAN Re in the RACS) are using this new command code - PIR/PIA.

According to Dan's comment (see attached), further review should be
performed with some clarification, the only action item related to this
draft is the ITEM 3 - 
"Propose text for an update to the document including reasoning for 
> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will 
> draft such a text"

i.e. why a Diameter application is defined for non-AAA case.

just wondering how to proceed. Who will draft the texts for the question
- why Diameter protocol is used for non-AAA application? When the next
round of review will be performed?

I can sumbmit an updated version when we have the agreed texts.

Thanks,
Dong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, October 30, 2008 9:14 AM
To: [email-masked]
Subject: [Dime] Diameter QoS Application

Dan made a good comment in his review of the QoS parameter document: 

>3. This document will trigger again the issue of exceeding the AAA 
>scope of DIAMETER as described by RFC 3588, raised in a number of 
>previous occasions, last by Brian Carpenter in his GenART review for 
>draft-sun-dime-itu-t-rw. I suggest to put text in the Introduction 
>section mentioning the issue of scope and referring to rfc3588bis as an

>Informational Reference.

However, when used in

Ciao
Hannes

Subject: Re: RE: DISCUSS: draft-sun-dime-itu-t-rw
From: "Hannes Tschofenig" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "Sun, Dong \(Dong\)" <[email-masked]>, <[email-masked]>
Date: Fri, 29 Aug 2008 02:48:09 -0500

Hi Dan, 

let me quickly respond to this issue: 

> As expected the document was not approved by the IESG and is now in AD
> Follow-up. 
> 
> Beyond the two DISCUSSes there were two ABSTAIN ballots. 
> 
> The principal concern that I heard was related to the fact that the
> current process followed by the draft did not ensure a sufficient
level
> of review from the IETF to ensure that it really meets the IETF
> consensus. 
> 
> In order to overcome this I suggest that we do the following: 
> 
> 1. Ask for at least one more review (two is better) from the
AAA-Doctors
> team or DIME WG making also sure that the reviewers also include
reading
> the relevant parts in the ITU-T document in their review (Hannes, can
> you ask Bernard to be one of the reviewers?)

I sent a mail to him. 

> 
> 2. Explain to the IESG why the DIME Working Group did not take this
work
> as a WG chartered item (hannes, please write a short explanation, also
> include the discussions around 3588bis)

draft-sun-dime-itu-t-rw is about a QoS/NAT/Firewall signaling using
Diameter. In the DIME working group we also have a document that deals
with QoS signaling, namely
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt.
It does, however, not cover NAT and Firewall signaling aspects. 

Other SDOs are, however, not required to use the work we do in the IETF
on certain Diameter applications. Additionally, they may enhance or
modify it. There are many reasons why this happens and I will not go
into the details of those. Call it a matter of life that has todo with
psychology rather than technical arguments. 

For us in DIME it does not really matter why ITU-T works on this
specific subject and it does not matter to us from a review point of
view either. 

The reason why the ITU-T (and previously OMA with
http://tools.ietf.org/html/rfc5224) came to the DIME working group is
actually related to a suggestion from our side (based on the Diameter
extensibility discussions we had) to define new Command Codes whenever
the ABNF of a command is modified by adding, removing or semantically
changing required AVP (i.e, those marked as {}). By defining new Command
Codes we believe to better avoid interoperability problems. 

The OMA has followed that suggestion (and so did ITU-T, to some extend)
but obviously ran into an issue with the requirements for the allocation
of Command Codes (compared to the allocation of Application IDs) based
on what RFC 3588 says. RFC 3588 allows vendors (in this case SDOs) to
register applications without going through the IETF process but has
different rules for the allocation of Command Codes. The DIME working
group had a long discussion about this issue and decided to change the
rules for allocating Command Codes with the revision of RFC 3588 (see
http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-11.txt)
and to align the procedure with the way how Application IDs are
requested. The main reasons for this decision were the following: 

* We did not want to encourage SDOs to misuse Diameter Command Codes
when they don't want to come to the IETF (and thereby causing
interoperability issues). 

* We did not want to drag all the SDOs to the IETF when it comes to
extending Diameter. Diameter is a very popular protocols among other
SDOs and this approach would not scale very well nor are we the experts
in all the applications areas people have in mind where Diameter could
be used.

* Some of us believe that the decision to have different rules for
Application ID allocation and Command Code assignment was a mistake
since it does not make a lot of sense from a logical point of view. 

* We should not treat the 3GPP differently to other SDOs since the 3GPP
was given a bunch of Command Codes without a corresponding specification
(see ftp://ftp.rfc-editor.org/in-notes/rfc3589.txt). We try to be
consistent in our behavior. 

As such, we came up with the idea to have an "interim" solution for
dealing with requests regarding Diameter Command Codes before RFC
3588bis gets published as an RFC. 

> 3. Propose text for an update to the document including reasoning for
> ignoring SHOULD NOT from RFC 3588 as per Chris' proposal - I will
draft
> such a text

I will think about text. Maybe it is lack of imagination on how
protocols could be used? Wouldn't be the first time that a protocol is
used in a way not originally envisioned. Example: RSVP - RSVP-TE

Funny enough, the idea about using Diameter for the purpose of NAT and
firewall signaling actually came from the IETF MIDCOM working group, see
http://www.ietf.org/rfc/rfc4097.txt
Unfortuantely, the MIDCOM group decided to pick SNMPv3 as their favorite
protocol and it turns out that this was the wrong decision. Hard to
predict preferences...

> 
> Also in parallel the DIME WG should do the best to accelerate the
> approval and submission of RFC3588 to the IESG so that we will need to
> deal with as few such cases in the future as possible (ideally zero). 

That's certainly a good idea. We are having a final round of reviews and
I have asked the authors of the draft to also re-read the document to
avoid problems in later stages (as they have happened with other
Diameter documents already). 

Ciao
Hannes

> 
> Thanks and Regards,
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Chris Newman
> > Sent: Thursday, August 28, 2008 7:29 PM
> > To: [email-masked]
> > Cc: [email-masked]; 
> > [email-masked]; [email-masked]
> > Subject: DISCUSS: draft-sun-dime-itu-t-rw 
> > 
> > Discuss:
> > As this issue was raised during IETF review and appears to 
> > concern a number of area directors, I'm holding an actionable 
> > discuss position:
> > 
> > Based on GEN-ART review responses, it appears this statement 
> > in the DIAMETER base spec:
> > 
> >   "Diameter is not intended as a general purpose protocol, and
> >    allocations SHOULD NOT be made for purposes unrelated to
> >    authentication, authorization or accounting."
> > 
> > is spurious and not being followed.  If we're not going to 
> > follow this rule (which is fine if there's rough consensus 
> > not to follow it), I believe it's important that it be 
> > documented why we're not following the rule (a "SHOULD NOT" 
> > requires justification).  Various approaches I find acceptable are:
> >  1. The document approval text includes reasoning for 
> > ignoring SHOULD NOT  2. An update to the document text 
> > includes reasoning for ignoring
> >     SHOULD NOT
> >  3. Hold this until a small RFC is published that updates 3588 to
> >     change or remove the SHOULD NOT restriction.
> > 
> > 
> >