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

"Worley, Dale R (Dale)" <dworley@avaya.com> Mon, 26 September 2011 15:38 UTC

Return-Path: <dworley@avaya.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 2EC5821F8C8E for <rai@ietfa.amsl.com>; Mon, 26 Sep 2011 08:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.471
X-Spam-Level:
X-Spam-Status: No, score=-103.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 J7BlEpAWYve5 for <rai@ietfa.amsl.com>; Mon, 26 Sep 2011 08:38:30 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4A28621F8AFC for <rai@ietf.org>; Mon, 26 Sep 2011 08:38:30 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAM+bgE6HCzI1/2dsb2JhbABBqBF4gVMBAQEBAgESKD8FCwIBCA0BByEQMiUCBA4FCBqHVp8AApsnhitgBJkTjA4
X-IronPort-AV: E=Sophos;i="4.68,445,1312171200"; d="scan'208";a="269801672"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Sep 2011 11:41:11 -0400
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Sep 2011 11:31:29 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 26 Sep 2011 11:41:06 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, "PFAUTZ, PENN L" <pp3129@att.com>
Date: Mon, 26 Sep 2011 11:41:04 -0400
Thread-Topic: [RAI] Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01
Thread-Index: AQHMekPLBuCz/bBhxEqu+n4PAwjj/pVfzpyT
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B222B1F590A@DC-US1MBEX4.global.avaya.com>
References: <38726EDA2109264987B45E29E758C4D6022778@MISOUT7MSGUSR9N.ITServices.sbc.com>, <5C947F1D-A87B-4096-87F8-1C5E8E2AD7E1@acmepacket.com>
In-Reply-To: <5C947F1D-A87B-4096-87F8-1C5E8E2AD7E1@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
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 15:38:31 -0000

> 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