Subject: [Dime] Application Id for commands in Gq and similar applications

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 11 Dec 2006 09:40:37 -0500

I have been mulling over the use of application-ids in the new ITU-T Rs 
application, which builds on 3GPP Gq. It has introduced a stateless mode 
of operation which has caused us to reuse a couple of 3GPP Cx commands, 
Push-Notification-Request/Answer, in place of RAR/RAA when the PDF is 
running in stateless mode. That means we have a new application, not Gq.

To ensure that Rs messages are routed to the right application at the 
destination, the application-Id in the Diameter header has to be that of 
the Rs application rather than of the application (mostly base, but also 
NASREQ and Cx as I said) that originally defined the command. And the 
application-Id presented in the body of the command has to be consistent 
with the header.

My conclusion is that Gq should not have preserved the mandatory 
Auth-Application-Id AVPs of the commands it took from base and RFC 4005, 
but should instead have accepted that it was an experimental 
vendor-specific application within the context of Diameter rules and 
replaced these AVPs with Vendor-Specific-Application-Id AVPs. The Rs 
application should do the same, using its own application-id and the 
ITU-T vendor-id.

Comments?

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 11 Dec 2006 13:40:50 -0500

Sorry, read Sh rather than Cx below.

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 11 Dec 2006 16:01:47 -0500

Hi Tom,

Considering that  application Id namespace is flat, it seems that it doesn't
matter much whether Auth-App-Id or Vendor-Specific-App-Id is used. Actually
I even don't know why both the Application-Id in the message header and the
X-App-Id AVPs are used. They have to have the same value, so probably
X-App-Id AVPs are redundant.

I think for the Gq interface the idea why Auth-Application-Id was preserved
is that it is defined as a mandatory AVP for AAR/AAA in RFC4005. OTOH, Gq
does something inconsistent with this by dropping Auth-Request-Type AVP in
AAR/AAA, which is a mandatory AVP according to the command grammar(defined
in {} ).

I believe, one important question to answer is how much freedom do new
applications have, when they are reusing commands defined by other
applications in terms of changing the grammar. For example, are they
allowed/supposed to drop some mandatory AVPs in the new grammar definition
of the command? It could be a good idea not to touch mandatory AVPs, which
are supposed to be vital from the commands semantics point of view. If there
is such a need, probably a new command could be justified. OTOH, this may
cause the number of new commands to explode.

   Thanks,
   Tolga

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Monday, December 11, 2006 9:41 AM
> To: [email-masked]
> Subject: [Dime] Application Id for commands in Gq and similar
> applications
>
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 11 Dec 2006 17:14:48 -0500

I see two paths for the ITU-T at this point. One is to conform fully 
with the word, though perhaps not the spirit, of RFC 3588 by specifying 
that all of the commands it uses are vendor-specific experimental 
commands which just happen to have the same numbers, same names, and 
almost the same content as their original counterparts. The other 
possibility might conform more to the spirit underlying RFC 3588 by 
using Auth-Application-Id to convey the application identifier (like Gq 
and the RFCs), keeping all the mandatory AVPs, but specifying default 
contents for those mandatory AVPs of no interest to the application.

I need to decide which way to go within the next day -- last call 
comments are due to the ITU-T on Wednesday. Are there opinions out there?

---

From: "Tolga Asveren" <[email-masked]>
Date: Mon, 11 Dec 2006 17:43:14 -0500

IMHO, the second path you described seems a better approach. It reuses what
is already defined and just extends it.

The first approach would require some IANA action. There isn't any range in
command code namespace, which is reserved for generic vendor specific use.

    Thanks,
    Tolga

> Sent: Monday, December 11, 2006 5:15 PM
> To: Tolga Asveren
> Cc: [email-masked]
> Subject: Re: [Dime] Application Id for commands in Gq and similar
> applications
>
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 11 Dec 2006 21:22:08 -0500

I'm not sure the first approach does require IANA action. As long as the 
ITU-T itself coordinates the assignment of command codes within the 
spaces defined by ITU-T applications, there should be no conflict. We 
have already created an ITU-T vendor-specific AVP registry, and I see no 
difference in principle for commands.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 11 Dec 2006 21:31:13 -0500

Despite what I just said, I'll go for the second approach for the sake 
of maximizing the possibility of interoperability.

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 12 Dec 2006 10:20:14 -0500

Hi Tom,
> of maximizing the possibility of interoperability.

Just trying to catch up on the discussion, does the "second approach" 
mean that the app id in the header does not match those in the app id 
avps ? If so, this is probably in conflict with the existing base and 
with the bis as well. My understanding is that if your just trying to 
reuse a command/message defined from another spec (pls correct me if I 
mis-understood the problem) then the "second approach" is preferred but 
you should define a consistent app id in both the header and app id 
avps. The app id of the spec that originally defined the command need 
not be represented when you use the command in your new application.

regards,
victor

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 12 Dec 2006 10:41:38 -0500

I've snipped down to the description of the second approach.

You saw my other note suggesting a change in the meaning of the 
application identifier in the body? I thought I would do some forensic 
tracking, and dug out a copy of draft-calhoun-diameter-04.txt (July 
1998) that's still lurking on my laptop. (We used it as a basis for 
IPDC, one of Megaco's predecessors.) Anyway, that was too far back -- 
the concept of applications wasn't present yet.

> not be represented when you use the command in your new application.
[snip]

  The other
>>>> contents for those mandatory AVPs of no interest to the application.
[snip]

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 12 Dec 2006 12:21:58 -0500

Hi Tom,
> application identifier in the body? 

I see. My main concern was interoperability if this new "meaning" 
results in multiple different app ids within a message. It could 
generate issues.

best regards,
victor

> I thought I would do some forensic tracking, and dug out a copy of 
> draft-calhoun-diameter-04.txt (July 1998) that's still lurking on my 
> laptop. (We used it as a basis for IPDC, one of Megaco's 
> predecessors.) Anyway, that was too far back -- the concept of 
> applications wasn't present yet.
>
> Victor Fajardo wrote:
>> Hi Tom,
>>> Despite what I just said, I'll go for the second approach for the 
>>> sake of maximizing the possibility of interoperability.
>>
>> reuse a command/message defined from another spec (pls correct me if 
>> I mis-understood the problem) then the "second approach" is preferred 
>> but you should define a consistent app id in both the header and app 
>> id avps. The app id of the spec that originally defined the command 
>> need not be represented when you use the command in your new 
>> application.
>>
> [snip]
>
>  The other

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 12 Dec 2006 16:34:57 -0500

I share Victor's concerns on this one. I believe it may be safer not to
touch the meaning of Application-Id AVPs and they have always the same
values as the Application-Id in the message header.

My understanding of approach two was that Auth-App-Id (together with App-Id
in the header) is populated with the identifier of the corresponding
application, e.g. Gq.

  Thanks,
   Tolga

> From: Victor Fajardo [mailto:[email-masked]]
> Sent: Tuesday, December 12, 2006 12:22 PM
> To: Tom-PT Taylor
> Cc: Tolga Asveren; [email-masked]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 12 Dec 2006 16:50:54 -0500

That is, indeed, what I recommended for Q.3301.1 (the Rs application).