IETF Logo Mail Archive

Re: [Dime] Diameter Group: Type?

Mark Jones <mark@azu.ca> Tue, 25 January 2011 13:30 UTC

Return-Path: <mark@azu.ca>
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 E8A423A6858 for <dime@core3.amsl.com>; Tue, 25 Jan 2011 05:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.905
X-Spam-Level:
X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 rhuejFkv4bKq for <dime@core3.amsl.com>; Tue, 25 Jan 2011 05:30:00 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id A4EFA3A686D for <dime@ietf.org>; Tue, 25 Jan 2011 05:30:00 -0800 (PST)
Received: by qyk34 with SMTP id 34so4150580qyk.10 for <dime@ietf.org>; Tue, 25 Jan 2011 05:32:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.85.207 with SMTP id p15mr4780832qcl.167.1295962377959; Tue, 25 Jan 2011 05:32:57 -0800 (PST)
Received: by 10.229.219.197 with HTTP; Tue, 25 Jan 2011 05:32:57 -0800 (PST)
In-Reply-To: <3EB9A6A055A0A74D816B7BA703D4054101A889C37F@ILHODMAIL1.corp.amdocs.com>
References: <3EB9A6A055A0A74D816B7BA703D4054101A889BD37@ILHODMAIL1.corp.amdocs.com> <C9636A72.C0C0%avi@bridgewatersystems.com> <3EB9A6A055A0A74D816B7BA703D4054101A889C37F@ILHODMAIL1.corp.amdocs.com>
Date: Tue, 25 Jan 2011 14:32:57 +0100
Message-ID: <AANLkTingbTDk5mwQgevCjCUjkF2KLxUG5jRCexB4qOaT@mail.gmail.com>
From: Mark Jones <mark@azu.ca>
To: Erez Nassimi <erez.nassimi@amdocs.com>
Content-Type: multipart/alternative; boundary="00163683206c2e3934049aabc1a9"
Cc: "dime@ietf.org" <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 13:30:02 -0000

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