Re: [Dime] Diameter Group: Type?

Avi Lior <avi@bridgewatersystems.com> Thu, 17 March 2011 21:34 UTC

Return-Path: <avi@bridgewatersystems.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 3B45B3A6A4A for <dime@core3.amsl.com>; Thu, 17 Mar 2011 14:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 AhBfYunupods for <dime@core3.amsl.com>; Thu, 17 Mar 2011 14:34:01 -0700 (PDT)
Received: from mail200.messagelabs.com (mail200.messagelabs.com [216.82.254.195]) by core3.amsl.com (Postfix) with ESMTP id 361663A693B for <dime@ietf.org>; Thu, 17 Mar 2011 14:34:00 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: avi@bridgewatersystems.com
X-Msg-Ref: server-5.tower-200.messagelabs.com!1300397727!92656684!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [72.35.6.119]
Received: (qmail 12501 invoked from network); 17 Mar 2011 21:35:28 -0000
Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-5.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 17 Mar 2011 21:35:28 -0000
Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Thu, 17 Mar 2011 17:35:26 -0400
From: Avi Lior <avi@bridgewatersystems.com>
To: "dime@ietf.org" <dime@ietf.org>, jouni korhonen <jouni.nospam@gmail.com>
Date: Thu, 17 Mar 2011 17:35:25 -0400
Thread-Topic: [Dime] Diameter Group: Type?
Thread-Index: Acvk6zq1Q3uz+VojT9O5fzRFlusDlA==
Message-ID: <C9A7F200.1214C%avi@bridgewatersystems.com>
In-Reply-To: <4D50A3C3.50809@nict.go.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.0.101115
acceptlanguage: en-US
x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Mark Jones <Mark.Jones@bridgewatersystems.com>, Erez Nassimi <erez.nassimi@amdocs.com>
Subject: Re: [Dime] Diameter Group: Type?
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: Thu, 17 Mar 2011 21:34:02 -0000

Hi All,

Just summarizing and reasserting my objection.

There are two issues here:
A) Should we have a bit definition for a grouped AVP.

B) Can bits be defined by Applications etc; and

WRT to (A). And putting aside (B).  I haven't heard any compelling reason
to add the G-bit.  As stated by more then one person: You either support
the
AVP based on its command code or not - whether its a grouped AVP or not
only becomes when you have to dive in to it - and you would only do that
for an AVP that you support. And you would know the type of the AVP
(whether it is an int or a group etc) if you support the AVP.



As to B) I agree with Glen.  As per the specification an Application can
define its own AVP flag.
Thus if an application writer can design a new Application and add a G-Bit
if they want.

What we cant do is add the G-bit as a general mechanism that can be
applied to all application (like the M-bit) and this is because (as
mentioned on this thread) the specification was not written properly and
we cant deal with such modification and not break things.  See "the
senders shall set to zero(clear) and receivers shall ignore" discussion.
We can't fix that in BIS since it will break existing applications.  We
could say that new applications shall include the above statement.  We can
also RECOMMEND that new application don't define their own AVP bits (if we
want).  This may create a bit of a war as those entities that have done so
come out of the wood work.  Do we know anyone that has done that?

Here is some text:

It is recommended that new Applications not define their own AVP flags
bits.

New Applications shall treat any reserved AVP flag bits as follows:  The
sender of the AVP shall clear (set to zero) all reserved AVP flag bits and
receivers shall ignore all reserved AVP flag bits.
 

Is there anything to fix in BIS.  Yes.

We need to state somewhere that if an existing application changes the
meaning/semantics of their AVP Flags then a new Application ID must be
assigned to that application.

This could be added to the section describing when to get a new
Application ID.

In V2 we can support properly the notion of applications defining their
own Flag bits (yuck) or not (my vote)


-- Avi Lior
--Bridgewater Systems




>