Subject: [Dime] on the use of Diameter commands (was WGLC comments of draft-ietf-dime-nat-control-03)

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 6 Sep 2010 15:03:26 +0200

Hi Jouni, all,

Thanks for your detailed review of draft-ietf-dime-nat-control-03. Apart
from the immediate issue mentioned, it brings up a wider question on how
we use of commands.

Wrt/ the specific issue: NCR w/ TERMINATE-REQUEST equals STR; and (I
agree) should be replaced; this would be inline with the guidelines in
dime-app-design-guide and 3588bis. The reason why the glitch happened
and the document did not reuse STR right away, was because we somewhat
followed the "TISPAN" or "3GPP" logic, i.e. incorporating several
behaviors into a single command, which points to the more general
discussion:

In TISPAN or 3GPP one sometimes only defines a single command and
overloads this command with different behaviors based on the value of a
parameter/AVP (e.g. Gq' with the "Specific-Action AVP"). With this
approach all the behaviors for an application are thus contained under a
single "umbrella command" - specific to this application. This results
in a smaller set of commands with a bit of a "hierarchical" structure -
which some folks see as more readable - but also means that you have to
provide differentiation below the command level if you implement the
state machine.
TISPAN and 3GPP also do not following this logic in all cases (largely
because of command reuse), so one always ends up in some middle ground.
IETF usually takes a cleaner approach, avoiding overloading of commands,
but defining distinct commands per required atomic operation. 

So what we could do for the draft is to (a) reuse existing commands as
much as possible (i.e. reuse STR/STA), which after your comments is a
no-brainer and (b) evolve to specifying individual commands for each
operation, rather than overloading NCR/NCA (the change is really
straight forward from a technical point of view).

If we'd (as the working group) decide to evolve the document along the
lines of (b) - avoiding the overloading of commands, the general
recommendation about atomic commands could also be a good addition to
the dime-app-design-guide ID - providing guidance for future cases...

Appreciate your thoughts.

Thanks and regards, Frank

> Ticket #10: http://trac.tools.ietf.org/wg/dime/trac/ticket/10
>
> During my WGLC review of draft-ietf-dime-nat-control-03 the reuse of
> NCR/NCA commands for almost everything looked strange. Why NCR/NCA
> during TERMINATE_REQUEST is not reusing RFC3588 STR/STA?
> 
> If there is no compelling reason of not reusing STR/STA, I would use
> commands what we have in RFC3588... as the document already makes an
> attempt to reuse ASR/ASA and ACR/ACA.

---

From: jouni korhonen <[email-masked]>
Date: Mon, 20 Sep 2010 18:04:47 +0300

Hi Frank,

Sorry for the delay (same excuse as earlier..)

> behaviors into a single command, which points to the more general

Right. I would not take e.g. 3GPP as an example how to design Diameter applications ;)

> but defining distinct commands per required atomic operation. 

I would say that if you bring a document to IETF, although its primary use case/deployment would clearly be in other SDO architectures, then better do it in IETF way.

> the dime-app-design-guide ID - providing guidance for future cases...

I recommend going for (a). ASR/ASA and ACR/ACA are already reused, and for session termination STR/STA would follow that path. I did not see anything on this particular case what would require a new command for "STR/STA purposes". If there is something that we cannot just achieve using STR/STA and its current ABNF, then I think a new command can be justified.

- Jouni

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Sat, 25 Sep 2010 07:08:10 +0530

Hi Jouni,

Regarding overloading and reusing a single command with type attribute
to define different behaviour, along with many Diameter applications
designed in 3GPP, DCCA application - RFC 4006 does that too. It will be
good to have some guidelines  on command overload in
draft-ietf-dime-app-design-guide.

Thanks,
Shwetha
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
jouni korhonen
Sent: Monday, September 20, 2010 8:35 PM
To: Frank Brockners (fbrockne)
Cc: [email-masked]
Subject: Re: [Dime] on the use of Diameter commands (was WGLC comments
ofdraft-ietf-dime-nat-control-03)

Hi Frank,

On Sep 6, 2010, at 4:03 PM, Frank Brockners (fbrockne) wrote:

> Hi Jouni, all,
> 
> Thanks for your detailed review of draft-ietf-dime-nat-control-03. 
> Apart from the immediate issue mentioned, it brings up a wider 
> question on how we use of commands.
> 

> behaviors into a single command, which points to the more general

Right. I would not take e.g. 3GPP as an example how to design Diameter
applications ;)

> overloads this command with different behaviors based on the value of 
> a parameter/AVP (e.g. Gq' with the "Specific-Action AVP"). With this 
> approach all the behaviors for an application are thus contained under

> a single "umbrella command" - specific to this application. This 
> results in a smaller set of commands with a bit of a "hierarchical" 
> structure - which some folks see as more readable - but also means 
> that you have to provide differentiation below the command level if 
> you implement the state machine.

> IETF usually takes a cleaner approach, avoiding overloading of 
> commands, but defining distinct commands per required atomic
operation.

I would say that if you bring a document to IETF, although its primary
use case/deployment would clearly be in other SDO architectures, then
better do it in IETF way.

> the dime-app-design-guide ID - providing guidance for future cases...

I recommend going for (a). ASR/ASA and ACR/ACA are already reused, and
for session termination STR/STA would follow that path. I did not see
anything on this particular case what would require a new command for
"STR/STA purposes". If there is something that we cannot just achieve
using STR/STA and its current ABNF, then I think a new command can be
justified.

- Jouni

>> attempt to reuse ASR/ASA and ACR/ACA.

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

---

From: jouni korhonen <[email-masked]>
Date: Tue, 28 Sep 2010 10:52:36 +0300

Hi,

> draft-ietf-dime-app-design-guide.

Yes that would definitely be a good thing to discuss in the app-design document.

- Jouni