Re: Multiple Namespaces Re: Split the IANA functions?

Phillip Hallam-Baker <hallam@gmail.com> Thu, 09 January 2014 22:58 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD551AC421 for <ietf@ietfa.amsl.com>; Thu, 9 Jan 2014 14:58:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZpsRwPQqDhZ for <ietf@ietfa.amsl.com>; Thu, 9 Jan 2014 14:58:52 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id BF0881ACD00 for <ietf@ietf.org>; Thu, 9 Jan 2014 14:58:50 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id x18so2874739lbi.31 for <ietf@ietf.org>; Thu, 09 Jan 2014 14:58:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VOjia0gbtW9rKGYRFZmRyJg73k27EHTborjGz/bK25g=; b=ZjedYOHA8mtwnkDjFO7JOSsxMv37nG2FUKGs7l6sz5tVqd2+7aUC8B6m19VcodVkvz LqbPBljIy5ZhPTjmnYlA1wti41OGJOLc5k8v4L0Jm8HIVmfKKCNWDp7ztW0vm6y0VFE3 24YgWNM0XpjpzOo/AmBvpqM+puyE/Q2nWFVp+JfNjwAjnZkNLBLm+cLeTkkvovWCsqiR wRNL4Z4j4WKCEcKTH8CO+Nb54uxc7cwV036bvD2fgr70XxWZLKOL6nBKBHDDs/ZtsXix xC7VuJ99waPROCUXX3PQ8jC8fAycxCGGYNh3WoXgJtthnBYUdETrTRrLiV9/UQQXG7TP nB+Q==
MIME-Version: 1.0
X-Received: by 10.152.120.7 with SMTP id ky7mr1385024lab.83.1389308320321; Thu, 09 Jan 2014 14:58:40 -0800 (PST)
Received: by 10.112.37.172 with HTTP; Thu, 9 Jan 2014 14:58:40 -0800 (PST)
In-Reply-To: <52CF11D7.5040209@dcrocker.net>
References: <94F13021-48B9-4CE9-995A-1081DC75A52D@isi.edu> <CAMm+LwinAb6+7BoMzwBWyu63vofndxK9VY6DSNN0Ykza4SxuMQ@mail.gmail.com> <52CB0010.5010407@gmail.com> <CAMm+LwhN8+z9q4KQXVY9bWA6TAqxx1=Qg0OUfK=VGCSDg5uWEA@mail.gmail.com> <DD618936-0D13-41F1-8D89-2E3171D864B5@istaff.org> <52CB31F4.3090703@cs.tcd.ie> <52CB987A.20300@cisco.com> <20140107144412.GB11068@mx1.yitter.info> <2520.1389225982@perseus.noi.kre.to> <03224C28-8623-41FE-839F-A544D174DDB3@ogud.com> <52CEF4E9.1070505@gmail.com> <87AA61A3-DC75-44AA-9E87-93DC4210A404@virtualized.org> <52CF11D7.5040209@dcrocker.net>
Date: Thu, 09 Jan 2014 17:58:40 -0500
Message-ID: <CAMm+Lwg=n8y20Q9K1stXvASxbn=u6GJwUGyjhENTCDAisiJTvA@mail.gmail.com>
Subject: Re: Multiple Namespaces Re: Split the IANA functions?
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Dave Crocker <dcrocker@bbiw.net>
Content-Type: multipart/alternative; boundary="089e0117690dea940304ef918cb9"
Cc: "ietf@ietf.org Discussion" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 22:58:54 -0000

On Thu, Jan 9, 2014 at 4:17 PM, Dave Crocker <dhc@dcrocker.net> wrote:

> On 1/9/2014 11:40 AM, David Conrad wrote:
>
>> The problem is that this issue keeps repeating, particularly in (shall we
>> say) non-technical venues. In a private message I semi-seriously suggested
>> someone should write an RFC that deprecates classes other than IN.
>>  However, I'm beginning to think this might not be that bad of an idea --
>> at least there would be a document that the non-technical folks who keep
>> raising the issue could be pointed at...
>>
>
>
> The premise to your line of thinking is that deprecating other classes
> will reduce these periodic demands for new name spaces.
>
> One of the benefits of having had so many of these cycles of demands, over
> the last 15+ years, is that we can see that straightforward technical
> discussion and explanation does not dissuade the proponents. They want what
> they want and they reject information that counters what they want.
>
> As I've become too fond of suggesting, the real requirement here is to
> move the work back onto those seeking the change.
>
>      It is /their/ burden to do the work of proposing and specifying the
> change, in sufficient technical detail.
>
>      It is /their/ burden to do the detail work of explaining how it can
> be viable.
>
>      It is /their/ burden to recruit sufficient community support.
>
> For the rest of us, the only burden is to put the burden back onto those
> folk.  Rather than saying "that won't work" and rather than trying to
> explain why it won't work, and rather than trying to narrow their
> opportunities for making criticisms, we merely need to recite some version
> of the above litany.
>
> If they are so certain what they want is viable, they need to do the work
> of making it viable.


+1

This is the way to deal with technical issues. Just lay out the facts and
make sure that every fact that is laid out is completely supportable.

When people draw the conclusion that 'X is impossible', people like me take
that as a challenge.


-- 
Website: http://hallambaker.com/