Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)

Miles Fidelman <mfidelman@meetinghouse.net> Thu, 06 November 2014 15:25 UTC

Return-Path: <mfidelman@meetinghouse.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 AF0931A890F for <ianaplan@ietfa.amsl.com>; Thu, 6 Nov 2014 07:25:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Level:
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-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 ixsJs2TGl4XU for <ianaplan@ietfa.amsl.com>; Thu, 6 Nov 2014 07:25:02 -0800 (PST)
Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 56C3D1A3BA0 for <ianaplan@ietf.org>; Thu, 6 Nov 2014 07:25:00 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 8B228CC082 for <ianaplan@ietf.org>; Thu, 6 Nov 2014 10:24:59 -0500 (EST)
X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net
Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5Ckchr9-TnnZ for <ianaplan@ietf.org>; Thu, 6 Nov 2014 10:24:54 -0500 (EST)
Received: from new-host-3.home (pool-96-237-159-213.bstnma.fios.verizon.net [96.237.159.213]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 78546CC067 for <ianaplan@ietf.org>; Thu, 6 Nov 2014 10:24:54 -0500 (EST)
Message-ID: <545B92C6.2000107@meetinghouse.net>
Date: Thu, 06 Nov 2014 10:24:54 -0500
From: Miles Fidelman <mfidelman@meetinghouse.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30
MIME-Version: 1.0
To: ianaplan@ietf.org
References: <54594A50.4090305@meetinghouse.net> <20141105001731.GA30186@mx1.yitter.info> <54597BDB.7040305@meetinghouse.net> <5459BA98.1070006@gmail.com> <545A208A.7040304@meetinghouse.net> <631e3e3d29c843bd9c23151c63612989@EX13-MBX-13.ad.syr.edu> <20141105154903.GI30379@mx1.yitter.info> <498a39b81b774192bd2d609b3feab35f@EX13-MBX-13.ad.syr.edu> <20141105234444.GM31320@crankycanuck.ca> <0d10ba336c984561a1a5d6d81db5f26c@EX13-MBX-13.ad.syr.edu> <20141106144333.GA33081@mx1.yitter.info>
In-Reply-To: <20141106144333.GA33081@mx1.yitter.info>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/60aAdwexoS83zUL89_Mv9SI5BtA
Subject: Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)
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: <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: Thu, 06 Nov 2014 15:25:05 -0000

'Andrew Sullivan' wrote:
> On Thu, Nov 06, 2014 at 06:08:02AM +0000, Milton L Mueller wrote:
>> I know that. Never said it was the way it works. I am simply pointing out to you that your view is far from commanding consensus.
>>
> Right.  "There's no consensus on the topic," is the way I usually
> spell that.  Which is, IIRC, what I said in the first place.
>
>> procedure. I saw him say that we shouldn't misconceive THIS process
>> as being fundamentally about engineering. And he's right.
> Obviously it's not abou engineering.  But the plain meaning of his
> words is that we shouldn't use the same procedure we use for
> engineering things for non-engineering things, and I disagree.

We might be in violent agreement here.  Others, however, have opined 
that these issues are not important, are outside the WG's scope, 
shouldn't be addressed here, should be left to others, and so forth.  
I've been simply stating my opinion that these issues need to be 
addressed as part of preparing the ICG response - either here, or in 
some clearly defined way.

>
>> Oh man. Do you know how much money has been spent by trademark litigants on those supposedly meaningless shibboleths called domain names that correspond to trademarks?
> I have a small bit of experience about that, yes.  And if you're a
> trade mark litigant, you _have to_ spend that money, because your
> lawyer told you that your trademark is being diluted, and that's a
> problem.  And it could well be that, if you have a brand, people
> magically type it into their URL bar and get to your home page, and so
> someone else having control over that domain name is a problem.  (Of
> course, nobody actually does this any more, and your "URL bar" hasn't
> been exclusively for URLs in most browsers for about a billion years
> in Internet time.  But never mind that.)  In any case, neither of
> those is the problem we have.
>
> The problem we supposedly have, but which proponents of declaring that
> we have moral authority over IANA don't seem to want to analyse,
> happens just in case there is a separation of the IANA functions and
> it happens in an unfriendly manner.  Supposedly under those
> circumstances, whoever then controls iana.org is going to set up a
> competing protocol parameters registry, and sow confusion all over the
> Internet by sending people to ports 35 and 344 instead of 53 and 443.
> I claim that the risk of this is impossibly small, and that in the
> case of such a dispute anyone who actually cares about protocol
> parameters will learn pretty quickly how to get the IETF ones; or
> else, that the IETF's legitimacy will be so poor by that point that it
> will make no difference what we do because people will already be
> using someone else's protocols.  (Given the amount of time we waste on
> governance discussions, I'm betting on the latter long before any IANA
> split.)  So yes, I believe that iana.org is a meaningless shibboleth.
> I don't think that all domain names are, but for this particular
> purpose it is one.
>
>> I do think the NTIA is in a position to require ICANN to provide what the final proposal posits, if it wants the transition to happen. I also think the U.S. Congress, the EC and the rest of the world would not look favorably upon any attempt by ICANN to extort the IETF in some way, and that such disfavor could have severe consequences for ICANN as it moves into the second, "enhanced accountability" phase of the transition.
>>
> Yet you apparently believe that the IETF can extort ICANN, which is
> what is actually being proposed: they have property, and some are
> proposing that they have to give it to us without compensation.

Extort, or force, no.

Identify that control of the iana.org domain is an important 
consideration, and that everyone's life would be easier if control of 
the domain was tied to the accountability and delegation mechanisms 
associated with the authority to oversee, contract for, etc. the iana 
functions contractor - and that there are potential problems if the 
status quo is mainatined - yes.

Suggest that the ICANN ownership of IANA related trademarks and domain 
registrations might be less than appropriate or legitimate, and 
something to be addressed during the transition - maybe. Suggest that 
transition to someone other than the IANA contractor of the moment - 
seems like that's desirable.

Suggest, as a possible transition measure, that the IETF trust is an 
appropriate holder of the IANA and iana.org trademarks, and the iana.org 
domain registration - as one alternative, to be discussed with all the 
other stakeholders as proposals are merged.  Why not? It is certainly 
one reasonable place to locate ownership/control of the IANA 
intellectual property - let others propose alternatives.


>
>> Not only have you never provided any evidence that anything like that will happen, you have never explained why, if it does, the IETF can't simply say, 'no' to any unreasonable positions. If you want to be credible, you might start by identifying the 'something we want' that ICANN would be in a position to force you to give up if the transition plan included a requirement that they turn over the trademark and the domain.
>>
> You put the burden of proof on the wrong side.  I'm saying, "Do
> nothing," you're saying, "Do this," and then you want me to prove that
> your proposal is actually going to cost something.
>
>> I think ICANN cares about this, but I think it cares more about making sure the transition happens and continuing to be the home of the IANA.
> Right.  And as part of "continuing to be the home of the IANA",
> surely, it will be better for it if it controls the trademark.  I
> cannot see how that is even a little bit controversial.

Nor should it be controversial to point out that, by holding the 
trademark, it hinders that critical accountability measure - the right 
of other parties to designate some other contractor as the "home of 
IANA" (or, for that matter to assume registry responsibilities directly 
- something that hasn't really been talked about -- note that IEEE, for 
example, is both the standards body and the registry for quite a few 
protocol parameters in the 802.11 space).


>
>> I think most of the community, including ICANN, is coming to accept the position that if it wants to keep the IANA functions it has to be accountable, and that the most important form of maintaining accountability involves the ability to move the IANA functions provider to another entity.
> But we already have in the I-D the term that they have to agree to
> move the IANA trademark to some other entity in the event the
> functions move.  I'm not opposed to that at all, since it appears to
> be something they've already agreed to.  But what people seem to want
> is something else: that the trademark and iana.org domain name move to
> the IETF Trust _even if_ the functions aren't moving.  I don't see any
> reason to ask for that, and I don't see why ICANN should agree to it.

The main reasons to ask for are:
- to strengthen the accountability measures associated with the option 
of changing IANA contractor
- avoid, proactively, any wrangling and disruptions that might happen 
down the line, if IETF (or others) were to move to transition the IANA 
contractor
- address the possibility that, down the road, there might be different 
IANA contractors for different functions

Asking that the IETF trust be the home of iana.org is a stretch - but 
offering it as one option, and opening the discussion seems reasonable.  
As in...

"The iana.org domain is used to disseminate information related to the 
IANA functions, including protocol parameters, ..... .  In order to 
enhance accountability, enable the possibility of changes in designation 
of IANA Functions Contractor(s), and smooth any transition(s) associated 
with a future change in IANA Functions Contractor(s), we suggest that 
the ownership of IANA related trademarks and other intellectual 
property, including specifically the iana.org domain and registration 
thereof, be transferred to an appropriate 3rd party, and that rules and 
procedures for management, licensing, delegation, etc. of these be put 
in place.  We further offer the IETF Trust as one option of an 
appropriate "home" for these assets."  (Again, I suggest that the 
lawyers be involved in discussion of the intent, implications, and 
wording of such language.)

As to why ICANN should agree to anything: Well, isn't ICANN's basic 
starting point that it simply wants to maintain all its roles, 
responsibilities, and functions - but without an NTIA contract? It's 
going to agree to a lot of things, that aren't ideal (from it's 
viewpoint) before a transition occurs.  Why is what ICANN likes or 
doesn't like even an issue for us?


> Moreover, as someone pointed out upthread, the trademark might have
> been obtained as part of a function of a contract with the USG.  If
> so, and the usual rules apply, then it may actually be the property of
> the USG.  In that case, there's another problem: trasnferring USG
> assets around requires legislative action.  I don't think we want to
> open that possibility.
>

Again, a reason to get the lawyers involved in this discussion.

Personally, I don't THINK this has to require legislation.  I've been 
through a lot of contract negotiations, with the USG, over intellectual 
property rights.  For DoD, at least, the baseline ownership of rights is 
set by law, and then by the DFARs - but a lot of it is negotiable, and 
contracting officers have a lot of room when it comes to patents and 
trademarks - as long as the government ends up with "government purpose 
rights" to anything it pays for. In some cases, even then there are 
limits (for example, under SBIR contracts, only the agency that funds 
the SBIR ends up with a license to use software developed with SBIR 
funding - at least that was the case the last time I was involved).

Miles Fidelman


-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra