[Ianaplan] "IANA.ZONE" and other entities and strategies (was: Re: Fwd: [CWG-Stewardship] ICG request concerning IANA trademark and iana.org domain name_

John C Klensin <john-ietf@jck.com> Tue, 23 June 2015 17:29 UTC

Return-Path: <john-ietf@jck.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 7258F1B2E9E for <ianaplan@ietfa.amsl.com>; Tue, 23 Jun 2015 10:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 yPYxCc-G1ehH for <ianaplan@ietfa.amsl.com>; Tue, 23 Jun 2015 10:29:27 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339CF1B2E9B for <ianaplan@ietf.org>; Tue, 23 Jun 2015 10:29:27 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Z7S0e-0009P4-WF; Tue, 23 Jun 2015 13:29:21 -0400
Date: Tue, 23 Jun 2015 13:29:15 -0400
From: John C Klensin <john-ietf@jck.com>
To: Jefsey <jefsey@jefsey.com>
Message-ID: <0D43D8143E5C5F21538340A0@JcK-HP8200.jck.com>
In-Reply-To: <20150623155648.DDE9F1A6F11@ietfa.amsl.com>
References: <20150619170708.84611.qmail@ary.lan> <3F18936E1587B5F2BB89E800@JcK-HP8200.jck.com> <55847BE9.9040507@gmail.com> <5584BC64.7060403@gmail.com> <alpine.OSX.2.11.1506192151170.47260@ary.local> <5584D664.90003@gmail.com> <alpine.OSX.2.11.1506201928040.47864@ary.local> <55863ABF.8020903@dcrocker.net> <alpine.OSX.2.11.1506211008240.48224@ary.local> <5586EB11.5030404@dcrocker.net> <alpine.OSX.2.11.1506211400250.48860@ary.local> <5587A015.9030700@cisco.com> <alpine.OSX.2.11.1506221032250.50421@ary.local> <55881331.9070902@dcrocker.net> <alpine.OSX.2.11.1506221056420.50578@ary.local> <5588FE8B.3040806@gmail.com> <55896464.2040803@cisco.com> <20150623155648.DDE9F1A6F11@ietfa.amsl.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/ZlisBNd0CtuO2WjCBbWao5C_9Sw>
Cc: ianaplan@ietf.org
Subject: [Ianaplan] "IANA.ZONE" and other entities and strategies (was: Re: Fwd: [CWG-Stewardship] ICG request concerning IANA trademark and iana.org domain name_
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: Tue, 23 Jun 2015 17:29:29 -0000


--On Tuesday, June 23, 2015 17:56 +0200 Jefsey
<jefsey@jefsey.com> wrote:

> The Draft is subject to my appeal. It should not therefore be
> published before the RFC 2026 procedure - which may involve
> ISOC - is completed. In order to have a better hands-on
> experience of this IANA trademark issue, it is my intent to
> give the "iana.zone" domain name to the "international
> all-network association" in order for them to set, experience
> and operate a mutual documentation and registry system.

Jefsey,

(speaking, as always, only for myself but that seems worth
stressing given what I'm about to say, which is just my opinion)

I don't intend to comment on the details of your appeal (and
have not read it recently), but do suggest that the IAB would be
entirely justified in rejecting an appeal preemptively if, after
making a sincere effort, no one can figure out what you consider
a problem and/or because your recommendations make no sense.  I
also note that the appeals process is intended to permit a
review of issues that are significant but have not achieved
adequate attention, unfair treatment of particular positions,
etc.

In general, if an appeal is found to have merit, the result is a
request that the topic be considered further.  Appeal bodies
beyond the IESG can actually change a decision directly as the
result of an appeal only under a _very_ limited set of
circumstances.  The IESG can, of course, reconsider its own
decisions while processing an appeal but, if those decisions are
about WG consensus, the appropriate (and most-used) action is to
ask the WG to consider them again.

It seems to me that new proposals that could reasonably have
been made during WG discussions should be considered out of
order in an appeal, at least absent strong evidence that they
could not reasonably have been introduced earlier.  

Specifically relative to the above:  

(1) You seem to be the registrant of "iana.zone" ("zone" is one
of the new commercial TLDs, for those on the IANAPlan list who
don't know).  I have questions about whether ICANN should have
allowed either of those confusion-prone strings, but it is done
(and probably not the IETF's problem).  Since you are the
registrant, you are free to assign the domain name wherever you
like, and use it however you like, subject only to your
agreements with your registrar and registry.  The IETF should
not be interested and cannot comment; were the the IETF to do so
in a way that singled you out, _that_ would be grounds for an
appeal.   

(2) Now, should you try to use "iana.zone" in a way that creates
confusion with any or all of the three sets of IANA registries,
that might be grounds for either a trademark infringement action
or a dispute resolution complaint that might result in taking
control of the domain away from you.  Neither would be an issue
for the IETF to take a formal position on.  Consequwntly, the
uses of a name that you have obtained is not a topic for either
this list or part of any appeal.   Whether anyone should pay any
attention to your domain if it does not cause confusion or get
attention from the broader community (or if you run it simply as
a mirror of the existing registries with no different or
incompatible ones) may be a more interesting question but,
again, it is not a question for the IETF (or this list or an
appeal more specifically).   If that is an experiment you want
to perform, please enjoy yourself and let us know how it works
out for you.

> This way to proceed turned out to be positive with ISO where
> we eventually allied: in case of an UDRP I will not object to
> transfer the name to who will best protect the users
> interests. This "who" will then have to be legally
> determinated.

Of course, that raises questions about how the party who will
"best protect the users interests" will be chosen and by whom.
But, again, that is not an IETF problem, does not belong on this
list, and should not be part of any appeal.   

I also don't understand the ISO reference.  I'm at least vaguely
familiar with most of the TCs (and JTC1 SC2) that might take
positions relative to either naming or registration policies and
I'm not aware of any activities there with which you might be
"allied".   Certainly you might develop policies for
registration entities and maintenance that use ISO models;
personally, I think you could do much worse.  But whether you
are actually allied with ISO or not is ISO's problem and that of
relevant Member Bodies; I don't see any way in which that is
germane to the IETF or something the IETF should have an opinion
about.

Observation/ recommendation to the IAB and IESG for future
situations:  my instinct is to continue to resist moves that
would limit the right to appeal.  However, it may soon be time
to consider rejecting appeals that are unclear about what
problem is being identified or what remedies would be considered
appropriate... and being clear that is the reason.  I would
expect the first such action to go to the ISOC Board on the
grounds of unfairness, but I would hope that we could do that
with open discussion and only once and then more on with a more
focused and constructive process.

Again, just my opinion.
 
  best regards,
    john