IETF Logo Mail Archive

Re: [Dime] Diameter Group: Type?

"David Lehmann" <dlehmann@ulticom.com> Tue, 25 January 2011 15:02 UTC

Return-Path: <dlehmann@ulticom.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 A38863A67EA for <dime@core3.amsl.com>; Tue, 25 Jan 2011 07:02:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 6H9EeLQ+Q3uL for <dime@core3.amsl.com>; Tue, 25 Jan 2011 07:02:03 -0800 (PST)
Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 8FB4D3A67E9 for <dime@ietf.org>; Tue, 25 Jan 2011 07:02:03 -0800 (PST)
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id FCD8B04D05E22413; Tue, 25 Jan 2011 10:04:52 -0500 (EST)
Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id p0PF4Tv2002610; Tue, 25 Jan 2011 10:04:33 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBBCA1.2A309F0E"
Date: Tue, 25 Jan 2011 10:04:29 -0500
Message-ID: <A51D8ACD861B7E41BFC7FE5C64BE9648135ADE20@MTLEXVS01.ulticom.com>
In-Reply-To: <AANLkTingbTDk5mwQgevCjCUjkF2KLxUG5jRCexB4qOaT@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Dime] Diameter Group: Type?
Thread-Index: Acu8lGahSFqXuhBqSgmjeTPnxzsbYQADCv1A
References: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com><C9636A72.C0C0%avi@bridgewatersystems.com><3EB9A6A055A0A74D816B7BA703D4054101A889C37F@ILHODMAIL1.corp.amdocs.com> <AANLkTingbTDk5mwQgevCjCUjkF2KLxUG5jRCexB4qOaT@mail.gmail.com>
From: David Lehmann <dlehmann@ulticom.com>
To: Mark Jones <mark@azu.ca>, Erez Nassimi <erez.nassimi@amdocs.com>
Received-SPF: pass
Cc: dime@ietf.org
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: Tue, 25 Jan 2011 15:02:04 -0000

I agree the RFC text should read "subsequent Diameter versions".
Applications should not be defining new flags.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of
Mark Jones
Sent: Tuesday, January 25, 2011 8:33 AM
To: Erez Nassimi
Cc: dime@ietf.org
Subject: Re: [Dime] Diameter Group: Type?

 

Hi Erez,

The G-bit addition would not be backwards compatible with
implementations of existing Diameter applications. Looking at section
4.1 in RFC3588:

      The 'r' (reserved) bits are unused and SHOULD be set
      to 0.  Note that subsequent Diameter applications MAY define
      additional bits within the AVP Header, and an unrecognized bit
      SHOULD be considered an error.

This text appears to allow the definition of your G-bit in some future
Diameter applications (though I wonder if this is a bug in the RFC which
should read "subsequent Diameter versions"). However implementations of
existing Diameter applications SHOULD reject the AVPs with your G-bit
set and return a permanent failure of DIAMETER_INVALID_AVP_BITS. 

How do you propose to make the G-bit addition harmless to existing
implementations?

Regards
Mark

v2.23.0 | Report a Bug | By Email