IETF Logo Mail Archive

Re: [Dime] RFC3588bis; Result-Codes and AVP flags

"David Lehmann" <dlehmann@ulticom.com> Tue, 15 March 2011 18:39 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 822773A6B1C for <dime@core3.amsl.com>; Tue, 15 Mar 2011 11:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 kfXfowtUR73C for <dime@core3.amsl.com>; Tue, 15 Mar 2011 11:39:06 -0700 (PDT)
Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 9F08D3A6B10 for <dime@ietf.org>; Tue, 15 Mar 2011 11:39:06 -0700 (PDT)
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 F76AA37D8DC2DDB2; Tue, 15 Mar 2011 14:40:29 -0400 (EDT)
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 p2FIeSYE016575; Tue, 15 Mar 2011 14:40:28 -0400 (EDT)
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: Tue, 15 Mar 2011 14:40:28 -0400
Message-ID: <A51D8ACD861B7E41BFC7FE5C64BE9648135ADF1B@MTLEXVS01.ulticom.com>
In-Reply-To: <D6B4881B-A60D-4938-8452-91E1D19C42F5@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Dime] RFC3588bis; Result-Codes and AVP flags
Thread-Index: AcviLn/wUx5aNdPwRN62aS9IreeCpQA4ocOQ
References: <4D3F8796.1090100@nict.go.jp> <D6B4881B-A60D-4938-8452-91E1D19C42F5@gmail.com>
From: David Lehmann <dlehmann@ulticom.com>
To: jouni korhonen <jouni.nospam@gmail.com>, dime@ietf.org
Received-SPF: pass
Subject: Re: [Dime] RFC3588bis; Result-Codes and AVP flags
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, 15 Mar 2011 18:39:07 -0000

> 2) Discussion on AVP flags. RFC3588bis-26 Section 4.1 says:
> 
>       The AVP Flags field informs the receiver how each attribute must
>       be handled.  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.
> 
> See the discussion around here, which ended without a firm conclusion:
> http://www.ietf.org/mail-archive/web/dime/current/msg04626.html
> 
> I would say we stay with the existing text. Any opinions against
keeping the
> existing text? If yes, propose the new text.

I propose to use the language which is used for the command flags:

"The AVP Flags field informs the receiver how each attribute must
be handled. The 'r' (reserved) bits are reserved for future use, and
MUST be set to zero, and ignored by the receiver."

--
David Lehmann
Ulticom, Inc.
856-787-2952

v2.23.0 | Report a Bug | By Email