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

["Shwetha Bhandari (shwethab)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
jouni korhonen
Sent: Monday, September 20, 2010 8:35 PM
To: Frank Brockners (fbrockne)
Cc: [e-mail]
Subject: Re: [Dime] on the use of Diameter commands (was WGLC comments
ofdraft-ietf-dime-nat-control-03)

Hi Frank,

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

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.
> 
> 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:

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

> 
> 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.

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.

> 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...

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


> 
> 
> 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.

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