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

"Richard Shockey" <richard@shockey.us> Tue, 27 September 2011 16:16 UTC

Return-Path: <richard@shockey.us>
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 499BC21F8EAA for <rai@ietfa.amsl.com>; Tue, 27 Sep 2011 09:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.432
X-Spam-Level:
X-Spam-Status: No, score=-98.432 tagged_above=-999 required=5 tests=[AWL=-1.529, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_PENIS1=3.592, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 QDj-z0hr19bY for <rai@ietfa.amsl.com>; Tue, 27 Sep 2011 09:16:21 -0700 (PDT)
Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 7927D21F8EA9 for <rai@ietf.org>; Tue, 27 Sep 2011 09:16:21 -0700 (PDT)
Received: (qmail 19080 invoked by uid 0); 27 Sep 2011 16:19:05 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 27 Sep 2011 16:19:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=2QuovKQ4RKRht5ZE7QURToS3N14/hlIhSfG/5h75KUY=; b=m5N/1oKHZjcKpltdQbDpdO4nxR39BUWaV2az6R/NPbPg+b/PJ5M7zDuXr4PoQCZ9nzsA4a8vcpoUX82RAlSD+bTw6lPoXpio7YA4QhWRv7/iZjcNOg5TYXJ17vfA02G/;
Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from <richard@shockey.us>) id 1R8aN7-0006nk-8i; Tue, 27 Sep 2011 10:19:05 -0600
From: Richard Shockey <richard@shockey.us>
To: "'PFAUTZ, PENN L'" <pp3129@att.com>, "'Livingood, Jason'" <Jason_Livingood@cable.comcast.com>, "'Worley, Dale R (Dale)'" <dworley@avaya.com>, 'Hadriel Kaplan' <HKaplan@acmepacket.com>
References: <CD5674C3CD99574EBA7432465FC13C1B222B1F590A@DC-US1MBEX4.global.avaya.com> <CAA62EE0.3B275%jason_livingood@cable.comcast.com> <38726EDA2109264987B45E29E758C4D6022C0F@MISOUT7MSGUSR9N.ITServices.sbc.com>
In-Reply-To: <38726EDA2109264987B45E29E758C4D6022C0F@MISOUT7MSGUSR9N.ITServices.sbc.com>
Date: Tue, 27 Sep 2011 12:19:02 -0400
Message-ID: <00ab01cc7d31$2cfa1c40$86ee54c0$@us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acx6AcDeNS0NeSsqR7m50XF38KY7vgAY41iAAIe6+gD//9vjgP///yyQ//6CdYA=
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us}
Cc: 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: Tue, 27 Sep 2011 16:16:22 -0000

+1

Of all the things to worry about here I doubt this is one of them. 

Personally I think folks and enterprises small or large prefer buy services
from service providers even if the service provider is internal to the
enterprise or cloud. Life is too short. 


-----Original Message-----
From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of
PFAUTZ, PENN L
Sent: Monday, September 26, 2011 1:54 PM
To: Livingood, Jason; Worley, Dale R (Dale); Hadriel Kaplan
Cc: rai@ietf.org
Subject: Re: [RAI] Global Service Provider ID -
draft-pfautz-service-provider-identifier-urn-01

Jason:
Because of the issues alluded to, of finding you've locked someone out you'd
like to be in, we were inclined *not* to set up specific qualifications.
So although the focus was service providers, it clearly went beyond ITU
recognized operating authorities or even US OCN-eligible parties.
I understand the concern about being too short but not the basis for 10
digits (10 billion) not being enough as the thinking was entities, not end
points or individuals in general. ITADs at 2**32-1 will top out below 10B.
I'm not sure there's a direct limit on PENs in terms of OID syntax but I'm
guessing SNMP implementations might constrain it to the same range as ITADs.

I remain concerned about being too big because of the desire of some parties
to do prefixing with them or to incorporate into domain name frames.


Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
Sent: Monday, September 26, 2011 1:32 PM
To: Worley, Dale R (Dale); Hadriel Kaplan; PFAUTZ, PENN L
Cc: rai@ietf.org
Subject: Re: [RAI] Global Service Provider ID -
draft-pfautz-service-provider-identifier-urn-01

Along these lines, who qualifies for a SPID? Could it be a small business
with their own SIP proxy / softswitch? If so, a 10-digit-length registry
will be wholly insufficient.


Jason

On 9/26/11 11:41 AM, "Worley, Dale R (Dale)" <dworley@avaya.com> wrote:

>> From: Hadriel Kaplan [HKaplan@acmepacket.com]
>>
>> So I asked some people about why ITAD wasn't what they wanted to use
>> for SPIDs, and they said exactly what you said above:
>>
>> > because the existing ones were intended for other purposes and
>> > already had many registrations
>>
>> It's the latter part (that they already have many registrations) that
>> I think is really why people don't want to use ITADs, and that's what
>> worries me in a weird way... because it implies they think some new
>> SPID registry won't be populated with junk.  It will be.
>
>I think there are two overlapping flavors of this distaste.  One is
>the symbolism of membership in a registry.  There is going to be a
>visceral desire that the registry is "for service providers, but not
>limited to traditional telephony".  However, if there are enough
>identifiers that we don't risk running out, it really doesn't matter
>who or what is allowed into the registry.
>
>The other flavor is what Hadriel says, "we don't want the registry
>filled with junk".  But the reality, the *meta-design principle*, is
>that if you have a system that can actually keep the junk out, you
>will also be keeping out something you want to let in.
>
>Dale
>_______________________________________________
>RAI mailing list
>RAI@ietf.org
>https://www.ietf.org/mailman/listinfo/rai

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