Re: [Ianaplan] Question from the ICG

Dave Crocker <dhc@dcrocker.net> Mon, 09 February 2015 15:04 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A496D1A19E4 for <ianaplan@ietfa.amsl.com>; Mon, 9 Feb 2015 07:04:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 vxbul86teG0u for <ianaplan@ietfa.amsl.com>; Mon, 9 Feb 2015 07:04:38 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0F11A079D for <ianaplan@ietf.org>; Mon, 9 Feb 2015 07:04:38 -0800 (PST)
Received: from [172.16.28.149] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t19F4WFc009574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Feb 2015 07:04:35 -0800
Message-ID: <54D8CC7E.7030100@dcrocker.net>
Date: Mon, 09 Feb 2015 07:04:30 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Andrew Sullivan <ajs@anvilwalrusden.com>, ianaplan@ietf.org
References: <F22D7C95-49EE-4BB9-9ED9-7475736A46C7@cooperw.in> <01870CB5-34E3-450A-910E-5A18D600B27B@piuha.net> <54D8C55F.9070007@dcrocker.net> <20150209144754.GA5582@mx1.yitter.info>
In-Reply-To: <20150209144754.GA5582@mx1.yitter.info>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 09 Feb 2015 07:04:35 -0800 (PST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/kgl7tha2sb_6jKrdzbbdg6b3-qk>
Subject: Re: [Ianaplan] Question from the ICG
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Feb 2015 15:04:40 -0000

On 2/9/2015 6:47 AM, Andrew Sullivan wrote:
> On Mon, Feb 09, 2015 at 06:34:07AM -0800, Dave Crocker wrote:
>> I took the earlier IANAPlan discussion as deciding that ownership of the
>> name was not worth a possibly contentious process, rather than an IETF
>> desire not to hold the name.
> 
> That was how I took the earlier discussion too.  I will also say that,
> in my own case, my opposition to adding iana.org and the IANA trade
> mark to our list of transitions must haves was exactly, "Not worth a
> possibly contentious process."  I think we should not bargain for such
> a change, because I don't think it gives us anything that would be
> worth giving anything up for.  But if someone else wants to engage in
> such bargaining, I think the IETF Trust is a fine place for the name
> or trademark or both to land.


In terms of making a discrete statement, perhaps this translates to:

     The IETF is willing to have the IETF Trust hold registration of
IANA.ORG, if that is the preference produced from the IANA Stewardship
Transition Coordination Group process.


This leaves a question of name /use/ policies and procedures that
probably need to be explicit as part of the hand-off to the Trust.  I'm
not clear whether that essentially means essentially defining a name
sub-registry, but it has to cover some set of administrative and
operational formalities.

In purely pro forma terms it does not seem prudent for the IETF Trust to
simple be passive and accept whatever is defined by others, if we are
taking on responsibility for asserting the policies and procedures
associated with maintenance and use of the name.


But it's entirely possible that we could come close to passivity,
leaving the IETF role merely as one of approval, along the lines of:

     as long as the associated policies and procedures are acceptable to
the IETF Trust.

And then we leave the details of that assessment to the Trust.  (And if
the Trust wants to be more active in formulating P&Ps that it finds
acceptable, that's dandy too...)



d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net