Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt

ken carlberg <carlberg@g11.org.uk> Tue, 15 June 2010 13:58 UTC

Return-Path: <carlberg@g11.org.uk>
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 8EC623A6801 for <dime@core3.amsl.com>; Tue, 15 Jun 2010 06:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 XbBS1RMS95Hc for <dime@core3.amsl.com>; Tue, 15 Jun 2010 06:58:38 -0700 (PDT)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 5E6053A67D4 for <dime@ietf.org>; Tue, 15 Jun 2010 06:58:38 -0700 (PDT)
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:53868 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1OOWey-0001w5-J1; Tue, 15 Jun 2010 13:58:36 +0000
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <D109C8C97C15294495117745780657AE0C9CA94C@ftrdmel1>
Date: Tue, 15 Jun 2010 09:58:36 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <75D214AC-F5F2-41EC-862D-60F18D5F9028@g11.org.uk>
References: <D109C8C97C15294495117745780657AE0C9CA866@ftrdmel1> <OF4D93F050.FDC2B636-ON85257743.004163F4-85257743.0043E1DC@csc.com> <D109C8C97C15294495117745780657AE0C9CA94C@ftrdmel1>
To: lionel.morand@orange-ftgroup.com
X-Mailer: Apple Mail (2.1078)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
Cc: James Polk <jmpolk@cisco.com>, dime@ietf.org
Subject: Re: [Dime] Additional comments on draft-ietf-dime-priority-avps-00.txt
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 Jun 2010 13:58:42 -0000

Lionel,

> [Lionel Morand] I was assuming that this mapping was provided, considering the text in IANA considerations inhttp://tools.ietf.org/html/draft-ietf-tsvwg-emergency-rsvp-15#section-7 and the updated version ofhttp://www.iana.org/assignments/sip-parameters. 
> If I'm wrong, please ignore my comment.
> If I'm correct, there is a one-to-one mapping between any namespace in string format and associated numerical value. It is therefore possible to rely on one single AVP to convey name space and priority value, for SIP of RSVP or whatever... Right?

the mapping described in the IANA considerations of the tsvwg-emergency-rsvp draft was designed to help ensure interoperability concerning a priority value that could be found from different protocols -- namely SIP (with its alphanumeric representation, and RSVP (with its numeric only representation).  We specifically wanted to avoid two different registries because even with the most careful of individuals, there would eventually be a mistake in trying to make sure that different representations of the same priority value would be misaligned.

At first glance, your proposal of a single group AVP versus two distinct AVPs has an appeal because of its potential simplicity through reduction/subtraction.  However, taking this one step further in terms of the scenarios that these AVPs could be applied would seem to add more complexity than originally intended.  For example, if a policy decision point received an RSVP message with an ALRP policy element (but whose packet payload did *not* contain a SIP message with an RPH header), then it would have the information for the SIP-Resource-Priority-Namespace-Value but nothing for the SIP-Resource-Priority-Namespace-String.  Do we then require a null entry for the latter?

In addition, your suggested format in the previous email is incomplete because we would still need a group entry defining a string and numeric entry for the Value portion of the RPH tuple.

As such, I have a preference to keep the defined AVPs as is.  If there is still some concern or confusion, we can discuss this offline or in person at the July IETF meeting.

cheers,

-ken

ps, James and Francois, I cc'ed you just to make sure you were in the loop.

pps, Lionel, thanks a lot for the additional review and thoughts on the topic!