-----Original Message-----
From: Tom-PT Taylor [mailto:taylor at nortel.com]
Sent: Monday, December 11, 2006 5:15 PM
To: Tolga Asveren
Cc: dime at ietf.org
Subject: Re: [Dime] Application Id for commands in Gq and similar
applications
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?
Tolga Asveren wrote:
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:taylor at nortel.com]
Sent: Monday, December 11, 2006 9:41 AM
To: dime at ietf.org
Subject: [Dime] Application Id for commands in Gq and similar
applications
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
DiME at ietf.org
https://www1.ietf.org/mailman/listinfo/dime
