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

"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Mon, 06 September 2010 13:03 UTC

Return-Path: <fbrockne@cisco.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E16C3A6926 for <dime@core3.amsl.com>; Mon, 6 Sep 2010 06:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zm5zvqoCImFH for <dime@core3.amsl.com>; Mon, 6 Sep 2010 06:03:03 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1F8953A67FF for <dime@ietf.org>; Mon, 6 Sep 2010 06:03:03 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJ6DhEyrR7H+/2dsb2JhbAChEnGgXJpahT0EjRY
X-IronPort-AV: E=Sophos;i="4.56,325,1280707200"; d="scan'208";a="250374040"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 06 Sep 2010 13:03:31 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o86D3PXf019240; Mon, 6 Sep 2010 13:03:31 GMT
Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Sep 2010 15:03:28 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 06 Sep 2010 15:03:26 +0200
Message-ID: <0D212BD466921646B58854FB79092CEC02E37774@XMB-AMS-106.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: on the use of Diameter commands (was WGLC comments of draft-ietf-dime-nat-control-03)
Thread-Index: ActNvBSPWSxVW/48QumkODADJU0BAAABHvWg
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: jouni korhonen <jouni.nospam@gmail.com>
X-OriginalArrivalTime: 06 Sep 2010 13:03:28.0815 (UTC) FILETIME=[E64FEBF0:01CB4DC3]
Cc: dime@ietf.org
Subject: [Dime] on the use of Diameter commands (was WGLC comments of draft-ietf-dime-nat-control-03)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2010 13:03:04 -0000

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.