Re: [Ianaplan] update on trademarks and domains & IETF trust

Russ Housley <housley@vigilsec.com> Wed, 17 February 2016 18:47 UTC

Return-Path: <housley@vigilsec.com>
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 B8D681B2AB0 for <ianaplan@ietfa.amsl.com>; Wed, 17 Feb 2016 10:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 p3PSO2DTZ0i4 for <ianaplan@ietfa.amsl.com>; Wed, 17 Feb 2016 10:47:32 -0800 (PST)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id C32801AD0EA for <ianaplan@ietf.org>; Wed, 17 Feb 2016 10:47:32 -0800 (PST)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 8E4D1F9C018; Wed, 17 Feb 2016 13:47:32 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id KyO+GcvdZIsO; Wed, 17 Feb 2016 13:46:14 -0500 (EST)
Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D6D79F9C013; Wed, 17 Feb 2016 13:47:21 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20160217181807.GK66257@mx2.yitter.info>
Date: Wed, 17 Feb 2016 13:47:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <96C90464-4D0D-48A5-AC43-89BC1963AC3A@vigilsec.com>
References: <1ECCDCCB-234E-4201-9E20-F236D665766D@piuha.net> <950DAF9B-6F3B-4A8C-B270-78BFC25861FE@piuha.net> <20160217181807.GK66257@mx2.yitter.info>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/bcSdMwVP3QYixexhrh3bjkEbOeU>
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] update on trademarks and domains & IETF trust
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 17 Feb 2016 18:47:34 -0000

Andrew:

Hopefully 3.g will never be need in practice, but this does deserve some
careful thought.

I worry that mediation is required before the Trust can move on to step
3.g.iii.  None of these steps will be quick, which is good.  However, if
an operational community decides that the IANA Operator is not acting
promptly to resolve the issue, the the Trust should not require a
mediation step.  In other words, the could be a last straw that causes an
operation community to see a new IANA operator and the Trust should not
impact that decision in either direction.
Russ


On Feb 17, 2016, at 1:18 PM, Andrew Sullivan wrote:

> Dear colleagues,
> 
> On Tue, Jan 26, 2016 at 05:16:47PM +0200, Jari Arkko wrote:
>> https://www.nro.net/pipermail/iana-ipr/
> 
> I will note that if you want to follow that list now as a subscriber,
> you can.  You too can get our deathless discussion of IPR issues
> delivered directly to your INBOX!  (It's still closed posting, however.)
> 
> We've also started work on a document of principles.  The draft is not
> complete yet, and there are still some issues to work out, but I at
> least would be extremely happy to hear remarks about what you see
> there, if you have time to read and comment.  You can see the document
> at
> https://docs.google.com/document/d/1oR3nmHl1fK7BEWOBK65KyvnmhTJZX70j9q4Ne9i4ad4/edit?usp=sharing.
> Unfortunately, it seems that in Google docs when you have read-only
> access you can't see the comments either.
> 
> There are a couple issues that I think are quite important still to
> sort out.
> 
> First, there's a set of things about the registration of iana.org.
> The goal here is to use a registrar that can require multiple
> approvals from different parties before changes are made.  That way
> the IANA operator can have (and be assured of) technical control of
> the domain while the registration is yet held by the Trust.  I know
> there is at least one regisrtar that offers this sort of service
> (Network Solutions, "Web Lock"), but if there are more I'd be happy to
> hear about it so that we could point that out.
> 
> Second, there's the issue of the exclusive vs. non-exclusive license.
> We have some registries that we treat as IANA registries but that are
> strictly speaking not.  The enum registry, for instance, is not
> operated by IANA.  Also, according to RFC 6557 the TZ Database is
> operated by ICANN as if it were an IANA function under the IETF-ICANN
> MoU but it is carefully called out as not an IANA function.  I'm not
> sure whether this affects the license discussion (I'll be seeking
> expert legal advice on this, but I wanted to note it as unsettled
> business).
> 
> Third, and perhaps most important, is the discussion in 3.g.  There's
> a tricky problem here.  The Trust will own the trademarks.  Under
> trademark law, this means that the Trust will have a duty and a right
> to enforce uses of the trademark.  So, if the Trust thinks that
> there's a problem and it's gone unresolved, the Trust needs to be able
> (in its sole discretion) to cancel the trademakk license to an IANA
> operator.  At the same time, we want the individual operational
> communities to have the power to select their operators.  The key
> thing here in 3.g. is to see whether the balance is right given what
> we want and the constraints of trademark law.
> 
> Obviously, any comments are welcome, but those are some substantive
> issues that I think need attention.  Remember that this is not a
> contract, but a set of principles under which we're going to work out
> the final arrangements.  
> 
> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> ajs@anvilwalrusden.com
> 
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan