Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

Adam Roach <adam@nostrum.com> Fri, 23 September 2011 22:22 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: rai@ietfa.amsl.com
Delivered-To: rai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA2D21F8C2A for <rai@ietfa.amsl.com>; Fri, 23 Sep 2011 15:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.348
X-Spam-Level:
X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4myFHBb2-zZV for <rai@ietfa.amsl.com>; Fri, 23 Sep 2011 15:22:50 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 25FE821F8C22 for <rai@ietf.org>; Fri, 23 Sep 2011 15:22:49 -0700 (PDT)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p8NMPK9R074681 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 23 Sep 2011 17:25:20 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4E7D0750.10405@nostrum.com>
Date: Fri, 23 Sep 2011 17:25:20 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: "Worley, Dale R (Dale)" <dworley@avaya.com>
References: <38726EDA2109264987B45E29E758C4D6022778@MISOUT7MSGUSR9N.ITServices.sbc.com> <CD5674C3CD99574EBA7432465FC13C1B222B1F5902@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B222B1F5902@DC-US1MBEX4.global.avaya.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: "rai@ietf.org" <rai@ietf.org>
Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2011 22:22:50 -0000

On 9/23/11 10:26 AM, Worley, Dale R (Dale) wrote:
>> From: PFAUTZ, PENN L [pp3129@att.com]
>>
>> The outstanding issues seemed to be
>>
>> 1. Is a new resource assignment necessary for the URN or could an
>> existing one, Private Enterprise Numbers or ITADs be used with a URN
>> defined to provide a fixed length parameter as requested in the I-D?
>>
>> 2. Assuming a fixed length parameter will be used, what’s the right
>> length?
> I am in favor of using one of the existing identifiers so as to avoid
> the proliferation of registries.

I think Dale is 100% correct here. We already have a couple of candidate 
registries, one of which has exactly and precisely the properties 
required. At least, for the properties that have been expressed so far 
(except possibly a hierarchical system; which, as Dale pointed out, is 
fully at odds with the requirement for a fixed-length identifier).

http://www.iana.org/assignments/trip-parameters/trip-parameters.xml#trip-parameters-5

These numbers are 32 bits long, which you can model syntactically as a 
fixed-length ten-digit number by zero-padding anything shorter than ten 
digits. For example, ITAD 1020 would be represented as "0000001020".

I don't think it makes even a little bit of sense talking about setting 
up another registry until someone can lucidly explain what properties 
the ITAD registry has that diverge from the properties being proposed 
for the new registry.

/a