Subject: [Dime] RE: Vendor-Specific Commands

From: "Daily William" <[email-masked]>
Date: Wed, 1 Aug 2007 18:25:12 -0400

Perhaps this is a naive question, but it seems to be worth asking
anyway.

It seems to me that the command code is already in a namespace, this
being defined by the application id.  This concept is used by other
protocols, most notably TCAP, where the operations codes (or commands in
Diameter) are defined within the domain of the application-context-name
(or Application-Id in Diameter).  A quick check of the Mobile
Application Part (MAP) and CAMEL Application Part (CAP) does show
overlap.

If one accepts the observation, then it stands to reason that when the
vender specific Application-Id is used all command codes used by
messages with the vender specific Application-id are vender specific
already.

With respect to routing, it seems odd to me that the command code would
need to understood by the routing algorithm in order for inter opt to
work.  What seems to be the only necessary information needed by the
routing would be:

                { Origin-Host }
                { Origin-Realm }
                { Destination-Realm }
                [ Destination-Host ]

For the request and in the response:

                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
* [ Proxy-Info ]

In addition to the above, the peers would need to agree that the
application-id can be supported in peer connection CER/CEA exchange,
which should not be a problem for routers.

Diameter does not segment the information to support the base protocol
functions from the data necessary for support of the application
(everything is an AVP). Since there is no clean delineation between the
bits for base and everything else we need to rely on best practice to
insure that the inter operation works.

If one accepts the premise that the command code is within the domain of
the Application ID, then perhaps the best solution is a description of
what the minimum requirements are for a new application and the best
practice to achieve this in a vender specific application.

Regards,

Bill Daily
Comverse, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2007 12:01 PM
To: [email-masked]
Subject: DiME Digest, Vol 20, Issue 3

Send DiME mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/dime
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of DiME digest..."

Today's Topics:

   1. RE: Vendor-Specific Commands (Mark Jones)

----------------------------------------------------------------------

Message: 1
Date: Wed, 1 Aug 2007 11:35:48 -0400
From: "Mark Jones" <[email-masked]>
Subject: RE: [Dime] Vendor-Specific Commands
To: <[email-masked]>
Cc: [email-masked]
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

> I would think that the best possible solution for vendor 
> specific command code
> would be to allocate a range of codes that IANA would freely 
> handout as long
> as there was a specification publicly available.  

Excellent suggestion, John. This is already being done for Application
Ids and IANA could follow the same reference rules for new command codes
assignments:

- IETF: Reference an RFC.

- Non-IETF SDO: Reference an information RFC (preferred) or SDO spec.

- Non-SDO Vendor: Reference is email of vendor contact person.

Regards
Mark

------------------------------

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

End of DiME Digest, Vol 20, Issue 3
***********************************

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

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 2 Aug 2007 16:36:00 -0400

> being defined by the application id.  

My understanding is the Command Codes are taken from a single global
namespace in order to allow Command re-use. Commands from one Diameter
application can be re-used in another and are still required to conform
to the original ABNF. However, the Command header in this case would
contain the Application ID of the 'using application' and not the
'defining application'. This is required because the Application ID in
the Command Header is used as a secondary key field in routing table
lookups.

I don't think this case was covered in the original 3588 but it is
clarified in section 5.3 of the Application Design Guidelines draft. 

Regards
Mark

---

From: "Daily William" <[email-masked]>
Date: Wed, 8 Aug 2007 11:08:27 -0400

Mark,

Thanks for this information.  I now have a better understanding of the
objective in command code definitions.

However this brings to light another interesting question.  If a command
is reused within the scope of an application ID that it was not
originally defined in then it seems that the semantics of the Command
can being defined by the 'using application'.

An example of this is in the proposed use of ACR/ACA in the
draft-ietf-dime-diameter-qos-01.txt.  The ABNF for ACR/ACA is
inconsistent with the ABNF of Base Diameter (App Id 3).  All this is ok
and reflects the semantics of the two applications however the ABNF for
the same message in both applications is ambiguous and contradictory.

Base diameter defines the command header ABNF syntax as:

   header           = "<" Diameter-Header:" command-id
                      [r-bit] [p-bit] [e-bit] [application-id]">"

IMHO, perhaps in the definition of new applications (or anything other
then base diameter (0)) best practice should dictate that the
application-id be used in the ABNF for all messages in the new
application.  This is especially important for reused commands to remove
ambiguity.  Considering that the base ABNF syntax supports this
capability this should be relatively easy.

Regards,

Bill

Comverse, Inc.

-----Original Message-----
From: Mark Jones [mailto:[email-masked]] 
Sent: Thursday, August 02, 2007 4:36 PM
To: Daily William
Cc: [email-masked]
Subject: RE: [Dime] RE: Vendor-Specific Commands

Regards
Mark

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 09 Aug 2007 08:18:28 -0400

Hi Daily,

> capability this should be relatively easy.

The diameter "best practices" document 
(http://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-02.txt) 
does explicitly state what you mentioned. Unfortunately, older document 
had followed an older scheme and recent drafts had yet to conform.

regards,
victor