IETF Logo Mail Archive

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

"Livingood, Jason" <Jason_Livingood@cable.comcast.com> Mon, 26 September 2011 17:29 UTC

Return-Path: <jason_livingood@cable.comcast.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 99B0B1F0C3D for <rai@ietfa.amsl.com>; Mon, 26 Sep 2011 10:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.001
X-Spam-Level:
X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 c67rlI0X7nKa for <rai@ietfa.amsl.com>; Mon, 26 Sep 2011 10:29:13 -0700 (PDT)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id AF7A41F0C3C for <rai@ietf.org>; Mon, 26 Sep 2011 10:29:13 -0700 (PDT)
Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.54505590; Mon, 26 Sep 2011 11:38:33 -0600
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Mon, 26 Sep 2011 13:31:48 -0400
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>, Hadriel Kaplan <HKaplan@acmepacket.com>, "PFAUTZ, PENN L" <pp3129@att.com>
Thread-Topic: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01
Thread-Index: Acx6AcDeNS0NeSsqR7m50XF38KY7vgAY41iAAIe6+gD//9vjgA==
Date: Mon, 26 Sep 2011 17:31:48 +0000
Message-ID: <CAA62EE0.3B275%jason_livingood@cable.comcast.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B222B1F590A@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [147.191.227.152]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <F5F6E7D9E4836A43B500B346CDA9995F@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 26 Sep 2011 17:29:14 -0000

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

v2.23.0 | Report a Bug | By Email