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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Tue, 04 October 2011 16:05 UTC

Return-Path: <keith.drage@alcatel-lucent.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 C7B1A21F8D82 for <rai@ietfa.amsl.com>; Tue, 4 Oct 2011 09:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.99
X-Spam-Level:
X-Spam-Status: No, score=-105.99 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 1V2r501c76T9 for <rai@ietfa.amsl.com>; Tue, 4 Oct 2011 09:05:22 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id A7A4321F8D80 for <rai@ietf.org>; Tue, 4 Oct 2011 09:05:21 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p94G8Lhi032318 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Oct 2011 18:08:22 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 4 Oct 2011 18:08:21 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, Dean Willis <dean.willis@softarmor.com>
Date: Tue, 04 Oct 2011 18:08:19 +0200
Thread-Topic: [RAI] [drinks] FW: Global Service Provider ID - draft-pfautz-service-provider-identifier-urn-01
Thread-Index: AQHMgqTNDpEYKfxfL0+qmMhIJxKbtpVsWTeA
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE220D4BD46@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <38726EDA2109264987B45E29E758C4D6022778@MISOUT7MSGUSR9N.ITServices.sbc.com> <76AC5FEF83F1E64491446437EA81A61F8190C94665@srvxchg> <38726EDA2109264987B45E29E758C4D6022834@MISOUT7MSGUSR9N.ITServices.sbc.com> <94C682931C08B048B7A8645303FDC9F355A8E5AC67@PUEXCB1B.nanterre.francetelecom.fr> <C0F18337-E780-46D4-9D51-BD788CDC3CDF@cablelabs.com> <38726EDA2109264987B45E29E758C4D6022AA0@MISOUT7MSGUSR9N.ITServices.sbc.com> <94C682931C08B048B7A8645303FDC9F355A8E5ACE7@PUEXCB1B.nanterre.francetelecom.fr> <00a101cc7d30$1abda480$5038ed80$@us> <94C682931C08B048B7A8645303FDC9F355A8F48F72@PUEXCB1B.nanterre.francetelecom.fr> <4E8A1752.9010406@softarmor.com> <09A47EDD-34BC-4027-8F96-01B95C03A80C@acmepacket.com>
In-Reply-To: <09A47EDD-34BC-4027-8F96-01B95C03A80C@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
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Cc: "<rai@ietf.org>" <rai@ietf.org>
Subject: Re: [RAI] [drinks] FW: 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, 04 Oct 2011 16:05:22 -0000

A couple of people have mentioned reclamation, almost in passing, without further detail of what and why and how.

At least people I have talked to in terms of other identifiers have said reclamation is hard, and involves a lot of work, and that is for an identifier with a smaller set of potential customers, although with a larger number of allocated values. How many of the contact details in the ITAD registry are still valid, and how many of those registered entities have now changed name to something else.

As far as I am aware, reclamation is also something that IANA have not been tasked to do in the past.

If you want reclamation, then you will need to describe how this is done, and the criteria for reclaiming, in any RFC setting up the registry.

Keith

> -----Original Message-----
> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of
> Hadriel Kaplan
> Sent: 04 October 2011 15:49
> To: Dean Willis
> Cc: <rai@ietf.org>
> Subject: Re: [RAI] [drinks] FW: Global Service Provider ID - draft-pfautz-
> service-provider-identifier-urn-01
> 
> 
> I don't think they want a "private-club" identifier.  For example I'd
> expect they'd be perfectly happy with Facebook, Harvard, and Jabber.org
> getting SPIDs.  This is really something we should all want.
> 
> When I think of what one would do with these SPIDs, though, they feel a
> lot like BGP AS numbers to me.  I would want to have the list of SPIDs be
> kept up-to-date, with dead numbers reclaimed, with recent contact
> information, and without random people like me just getting one on a whim.
> [note: these are my desires, I have no idea if the people asking for SPIDs
> agree]
> 
> So it's not so much a "private-club" as a club with a cover charge, to
> make sure people entering it are serious.
> 
> -hadriel
> 
> 
> On Oct 3, 2011, at 4:13 PM, Dean Willis wrote:
> 
> > On 10/3/11 8:31 AM, mohamed.boucadair@orange.com wrote:
> >> Dear Richard,
> >> I must admit that I didn't found in your answer no valid technical
> >> argument why ITADs can not be used.
> >> Perhaps there are some subtleties I missed.
> >>
> >
> > Richard makes no technical arguments here. Rather, his arguments are
> political; some of the people driving the need for SPID do not think their
> problem space is them same as ITAD and want a separate number space. As
> there is little cost in adding a distinct registry, it might be reasonable
> to honor their desires by making one.
> >
> > WHY they want a separate number space is unclear to me, and should, I
> think, be examined.
> >
> > One answer is that they see ITAD as being "internet telephony" specific,
> and have a broader service definition in mind.
> >
> > An alternate is that they see ITAD as being "too Internet", and that it
> shouldn't be mingled with their lofty carrier status. They may fear that
> having a pool of existing ITADs will increase the pressure on them to peer
> at the egalitarian ITAD level, which might impact their business models.
> Perhaps, then, they really want a "private club" identifier. Why then
> would they require action from the IETF, unless they want free
> administrative support for their private club? It seems like that line of
> argument makes little sense; they could easily have their own ITU "private
> club" without having to twiddle with the IETF.
> >
> > Perhaps we're really talking about is an identifier that has the
> potential to be used in egalitarian peering, but the fact that "It's not
> an ITAD" makes it easier to sell to carriers (because it doesn't come with
> the expectations of an ITAD and an existing pool of users), so the
> operators can hope to use it to protect or extend their private-club model
> at the same time as activist thinkers are expecting that the SPID will
> eventually have the same sort of egalitarian pressure on it as ITAD.
> >
> > In other words, using a new SPID registry instead of an existing ITAD
> registry might be just a sleight-of-hand mechanism to get it adopted, and
> I'm probably OKAY with that. The actual operation role of such an
> identifier will continue to evolve once it gets deployed.
> >
> > This leads me to suggest an alternative acronym: the "Generic Operation
> Numerical Administrative Domain", or GONAD. Think of it as a generative
> organ for future internet services that need numerically scoped
> identifiers. Besides, I've often thought that gonads should be registered;
> they cause a lot more damage than personal firearms.
> >
> > --
> > Dean
> > _______________________________________________
> > 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