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

"PFAUTZ, PENN L" <pp3129@att.com> Tue, 27 September 2011 17:52 UTC

Return-Path: <pp3129@att.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 9437C21F8C7A for <rai@ietfa.amsl.com>; Tue, 27 Sep 2011 10:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level:
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Bs+J5y9HIPkq for <rai@ietfa.amsl.com>; Tue, 27 Sep 2011 10:52:39 -0700 (PDT)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9864921F8C21 for <rai@ietf.org>; Tue, 27 Sep 2011 10:52:39 -0700 (PDT)
X-Env-Sender: pp3129@att.com
X-Msg-Ref: server-6.tower-119.messagelabs.com!1317146125!39346531!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 403 invoked from network); 27 Sep 2011 17:55:25 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Sep 2011 17:55:25 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8RHtp1F013498; Tue, 27 Sep 2011 13:55:52 -0400
Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8RHtm10013395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Sep 2011 13:55:48 -0400
Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([169.254.5.157]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0289.001; Tue, 27 Sep 2011 13:55:20 -0400
From: "PFAUTZ, PENN L" <pp3129@att.com>
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>, Dean Willis <dean.willis@softarmor.com>, "rai@ietf.org" <rai@ietf.org>
Thread-Topic: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01
Thread-Index: AQHMfTw3nJHAdSIvOkmjtjzxEJNMNZVhfzqw
Date: Tue, 27 Sep 2011 17:55:18 +0000
Message-ID: <38726EDA2109264987B45E29E758C4D6022F58@MISOUT7MSGUSR9N.ITServices.sbc.com>
References: <4E820778.1070807@softarmor.com> <CAA78216.3B564%jason_livingood@cable.comcast.com>
In-Reply-To: <CAA78216.3B564%jason_livingood@cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.91.160.51]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 27 Sep 2011 17:52:40 -0000

These are certainly good points and other things being equal I'd say better safe than sorry. It comes down to a balancing act. There are contemplated applications where 64 bits/20 digits might be too big or seen as too big: digit prefixing in a telephony scenario (this also drives the fixed decimal length requirement) and using SPID as part of a domain name per GSMA IR.67, SPN[SPID].ipxsp.org
My object is to meet the needs of a variety of stakeholders, some as yet unidentified, and avoid having multiple identifiers.
My own guess is 32 bits/10 decimal digits will be OK as I don't see this as a device or even person level resource although some persons will style themselves as SPs and that's OK. [but I've been wrong and I could be wrong again]
What I can do is go back to some of the stakeholders and see how they'd feel about going larger.



Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Livingood, Jason
Sent: Tuesday, September 27, 2011 1:38 PM
To: Dean Willis; rai@ietf.org
Subject: Re: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01

>On the other hand, perhaps we're being wildly optimistic about the
>importance of the SPID and the future demand for them.
>
>One might also note that 32 bits is a nice fixed-length number in binary
>(32 digits), quaternary (16 digits), or hexadecimal (8 digits). Why are
>we restricting ourselves to 10 decimal digits, which doesn't map to
>anything binary in a very nice way?

+1
Machines are going to process this stuff in practice anyway, so we needn't
worry that these #s are too long to remember or whatever. Also, now that I
am in the midst of IPv6 deployment I tend to be of the opinion that a
bigger initial address space is better. This is especially the case as
we're not exactly storage or processing constrained in key systems that
would be used.

Feel free to override this one opinion. I just don't want to be on a panel
discussion in 10+ years talking about why we choose such a small SPID
length. ;-)

Jason

_______________________________________________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai