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

Dean Willis <dean.willis@softarmor.com> Tue, 04 October 2011 19:21 UTC

Return-Path: <dean.willis@softarmor.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 0CC0B21F8F83 for <rai@ietfa.amsl.com>; Tue, 4 Oct 2011 12:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.33
X-Spam-Level:
X-Spam-Status: No, score=-103.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 SR4SqcrDUtKT for <rai@ietfa.amsl.com>; Tue, 4 Oct 2011 12:21:29 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA7321F8F7E for <rai@ietf.org>; Tue, 4 Oct 2011 12:21:27 -0700 (PDT)
Received: by gyd12 with SMTP id 12so988531gyd.31 for <rai@ietf.org>; Tue, 04 Oct 2011 12:24:33 -0700 (PDT)
Received: by 10.150.133.13 with SMTP id g13mr1673860ybd.95.1317756273027; Tue, 04 Oct 2011 12:24:33 -0700 (PDT)
Received: from dwillis-mb1.local (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id h20sm46746784ani.16.2011.10.04.12.24.31 (version=SSLv3 cipher=OTHER); Tue, 04 Oct 2011 12:24:32 -0700 (PDT)
Message-ID: <4E8B5D6D.1080104@softarmor.com>
Date: Tue, 04 Oct 2011 14:24:29 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Richard Shockey <richard@shockey.us>
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> <4E8B45D9.60805@softarmor.com> <00fb01cc82c4$3e7e0970$bb7a1c50$@us>
In-Reply-To: <00fb01cc82c4$3e7e0970$bb7a1c50$@us>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: 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 19:21:30 -0000

On 10/4/11 1:34 PM, Richard Shockey wrote:
> Reclamation is hard ..been there done that with phone numbers.
>
> I haven't seen any use case other than a casual suggestion from Hadriel that
> one may be necessary.
>
> Contact data ..maybe but in any event I don't see the immediate need for a
> cost recovery mechanism.

Okay, if you don't NEED reclamation, and you don't NEED a contact 
mechanism, and you don't NEED a cost-recovery mechanism to pay for the 
administration, then you don't appear to NEED anything other than an ITAD.

You might WANT something that walks like an ITAD, talks like an ITAD, 
and quacks like an ITAD, but that "just isn't an ITAD". As many people 
have pointed out, that's not a strong justification for doing anything 
other than ITAD, because we already have ITAD.

So, why should the IETF satisfy that which you WANT but do not NEED, 
when we've already satisfied that which you NEED? We like you, Rich, but 
we're really lazy. We REQUIRE a stronger reason.

If, on the other hand, there were some sort of operational requirement 
or behavior that makes SPID different from ITAD, or that makes the 
administration of SPID different from the administration of ITAD, then 
we might have a justification for doing it.

--
Dean