IETF Logo Mail Archive

Re: [Dime] Diameter Group: Type?

"Glen Zorn" <gwz@net-zen.net> Sat, 29 January 2011 05:58 UTC

Return-Path: <gwz@net-zen.net>
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 B71513A696F for <dime@core3.amsl.com>; Fri, 28 Jan 2011 21:58:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.397
X-Spam-Level:
X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 58phfH8QRkf6 for <dime@core3.amsl.com>; Fri, 28 Jan 2011 21:58:33 -0800 (PST)
Received: from smtpout05.prod.mesa1.secureserver.net (smtpout05-01.prod.mesa1.secureserver.net [64.202.165.218]) by core3.amsl.com (Postfix) with SMTP id E6D913A6895 for <dime@ietf.org>; Fri, 28 Jan 2011 21:58:32 -0800 (PST)
Received: (qmail 4767 invoked from network); 29 Jan 2011 06:01:40 -0000
Received: from unknown (110.168.98.197) by smtpout05.prod.mesa1.secureserver.net (64.202.165.218) with ESMTP; 29 Jan 2011 06:01:39 -0000
From: Glen Zorn <gwz@net-zen.net>
To: 'Mark Jones' <mark@azu.ca>, 'Erez Nassimi' <erez.nassimi@amdocs.com>
References: <3EB9A6A055A0A74D816B7BA703D4054101A8963DCF@ILHODMAIL1.corp.amdocs.com> <AANLkTin1r1hJsOusMyYcfo-0efNdsJVQNSp1j3o0E=by@mail.gmail.com>
In-Reply-To: <AANLkTin1r1hJsOusMyYcfo-0efNdsJVQNSp1j3o0E=by@mail.gmail.com>
Date: Sat, 29 Jan 2011 13:01:23 +0700
Organization: Network Zen
Message-ID: <015c01cbbf79$f7338d50$e59aa7f0$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_015D_01CBBFB4.A3926550"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acu+5M/mNZrQwCZ/TnOZgI2vokQTrwAktllg
Content-Language: en-us
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: Sat, 29 Jan 2011 05:58:38 -0000

Mark Jones [mailto://mark@azu.ca] <mailto:[mailto://mark@azu.ca%5d>  writes:

 

Hi Erez, 

Will you be raising an issue on 3588bis so the authors can fix this bug?

Maybe it's just me, but I'm having a hard time finding a bug here (certainly
not in the same category as the IANA mess): Diameter applications can define
AVPs, so why not the flags for those AVPs, as well?  As for subsequent
versions of Diameter, those future versions (if any) don't need the
permission of 3588bis to change anything at all...



Thanks
Mark

On Fri, Jan 28, 2011 at 1:20 AM, Erez Nassimi <erez.nassimi@amdocs.com>
wrote:

Guys,

 

Thank you for the comments. I think everyone agrees there is a bug in RFC.
But this can lead us to 2 different interpretations:
1.  Based on "an unrecognized bit SHOULD be considered an error", we could
assume that "subsequent Diameter applications MAY define additional bits
within the AVP Header", should have read "subsequent Diameter versions".
2.  But the words are very clear and as of now it says "subsequent Diameter
applications".

In any case, my point was rather conceptual than technical. Defining a
Grouped AVP as a type, is similar to classifying C++ classes in the same
category as simple types as int, char, etc. There is a difference after all.


A different (& more accurate IMHO) example would be the difference between
an int & a float.

v2.23.0 | Report a Bug | By Email