Re: [Ianaplan] Fwd: [CWG-Stewardship] ICG request concerning IANA trademark and iana.org domain name

JFC Morfin <jefsey@jefsey.com> Thu, 25 June 2015 10:30 UTC

Return-Path: <jefsey@jefsey.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 5151C1B346B for <ianaplan@ietfa.amsl.com>; Thu, 25 Jun 2015 03:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.134
X-Spam-Level: *
X-Spam-Status: No, score=1.134 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334] autolearn=no
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 CuYVrmN8bysf for <ianaplan@ietfa.amsl.com>; Thu, 25 Jun 2015 03:30:54 -0700 (PDT)
Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5BC1B346D for <ianaplan@ietf.org>; Thu, 25 Jun 2015 03:30:54 -0700 (PDT)
Received: from 251.47.14.81.rev.sfr.net ([81.14.47.251]:53090 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.85) (envelope-from <jefsey@jefsey.com>) id 1Z84Qm-0007K0-6t; Thu, 25 Jun 2015 03:30:52 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 25 Jun 2015 12:30:47 +0200
To: Russ Housley <housley@vigilsec.com>, Ted Hardie <hardie@qualcomm.com>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <F5E6D5A8-F59D-4F1C-B3F6-0F347559E798@vigilsec.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> <F5E6D5A8-F59D-4F1C-B3F6-0F347559E798@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.presenceweb.org
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Message-Id: <20150625103054.3A5BC1B346D@ietfa.amsl.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/3T34B0tvgxsin-lNg_QgyIRh_sA>
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] 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: Thu, 25 Jun 2015 10:30:56 -0000

Thank you both.

I think that Andrew Sullivan, in explaining why IAB was exceptionally 
giving me the extra short delay that I/our community needed, has made 
a good evaluation of the exceptional nature of the situation and of 
my appeal. It might certainly call for an ISOC response if IAB is 
unable to address it (let see their response first) because the whole 
thing was co-triggered by Lynn St-Amour, and because RFC 2026 says so 
(cf. end of my appeal).

Let's understand: we all try to do our best to better address a 
biased demand in a unique situation. We also are put under the 
political pressure resulting from the date of the Iowa Caucus.

Due to the way the IETF was created in 1986, most of its people are 
under the RFC 3774 "affinity group" paradigmatic influence, whatever 
its formal status (cf. RFC 6852) and they accept the Iowa Caucus date 
as a technical constraint. I am not. The many other communities of 
world are not either.

This is because the world is as Russ' RFC 6852 describes it, and 
misses the multitech SuperIANA that should have resulted from the 
"enhanced cooperation" mechanism consensually adopted by the WSIS. It 
was planned to be defined by practical consensus over the last 10 
years: RFC 6852 principles seem to be a good but incomplete basis … 
that also seems to be opposed/ignored by most at IETF.

We failed to reach that consensus through discussions (mostly for the 
same reason as in 1986: the lack of IP built-in security). I submit 
that, along with our long standing multiple experiences, we can 
eventually find it through experimentation. And that ICP-3 is a good 
starting basis for an experimentation spirit based upon 
"permissionless innovation" (and for us, our preceding "dot-root" 
community experimentation).

Now, I would wish for you to not react so obviously in the way that 
you think that I want you to do. I do not try to manipulate you. All 
I want is your help in being innovatively smart in your reactions. In 
reacting the way some do, they believe they do, but do not contribute.

Let me be clear and loyal to you:

1. My appeals are not internal. They are for the real decision makers 
(US, EU, BRICS, UN, ITU, LIBRE, people, IETF free minds) and 
processes (press, history, R&D, Libre imagination) to pragmatically 
consider their alternatives to the IETF system, now that the IETF has 
consensually chosen to copy the NTIA and align on ICANN. The question are:

1.1. which replacement to use for the IETF in each of the various 
Global Communities you are consensually quitting as their referent 
SDO for their local needs, problem and guidance,
1.2. and how to make them concert in cooperation, coopetition, or 
reasonable competition. That is, if one wishes peace on nets.

2. these addressees are not very concerned by goodwill internal fuzzy 
rules. They care about common sense. Respecting mini-rules for 
giga-issues might disqualify rather than comfort a position. The only 
rule I had to respect was the two-month delay (quite short in the 
transition dynamic context) just to get it accepted and published by 
the IESG and IETF.

3. disqualifying (and claiming not to have read it) my common sense 
question of its users to the IETF "your consensus does not show 
whether we are friends or foes, please clarify first" may only lead 
to disqualifying who disuqlifies it. As well as considering quick and 
dirty responses, just to match a politically imposed calendar. 
Publishing the IANAPLAN Draft as an RFC would only mean "I do not 
care about the world's continuing contributions: here is my ukase".

After all, this is YOUR rough consensus. Just please accept that the 
multi and omnistakeholder consensual emergence from the rest of the 
world may differ. Like for the WCIT. To reach an understanding, a 
compromise, and may be a consensus, one needs to be at least two.

I am sure both of you, John, each of you all may help. Let just 
accept that the internet architecture is just a step in the catenet 
natural development. We face the complexity of the next step. Thank 
you Louis Pouzin, thank you Vint Cerf, thank you the US, thank you 
IETF, thank you ICANN, what next?

Best
jfc



At 19:16 23/06/2015, Russ Housley wrote:
>Jefsey, this is not the process.
>
>In 2007, we had a discussion on this point.  Here is a pointer to 
>that discussion in the archive.
>
>I started a discussion, and I recall it quite clearly because the 
>community was very clear in their wishes.  The mail thread starts here:
>
> 
>https://mailarchive.ietf.org/arch/msg/ietf/3_fzQrJl-IUYbNBjAe7mvZqww3E
>
>and the consensus call is here:
>
> 
>https://mailarchive.ietf.org/arch/msg/ietf/9skOU3qdPkhwFuSkcrlTcmXg7LI
>
>I have copied the consensus call message below to save you time...
>
>Russ
>
>= = = = = = = =
>
>The discussion of this topic has died down, so it is time for me to
>make a consensus call.  It is quite clear to me that the community
>does not want to delay the publication of RFCs.  Therefore, in this
>note, I am asking the RFC Editor to publish RFCs as soon as Auth48 
>is complete.
>
>If there is a successful appeal against the approval of an
>Internet-Draft, then the IESG will offer a remedy.  One possible
>remedy is to classify the RFC as Historic, and another possible
>remedy is to progress a new RFC that obsoletes the earlier one and
>contains some appropriate correction.  These remedies are attractive
>because no new processes or procedures are needed.  Another possible
>remedy might be to withdraw the RFC.  This remedy is not as
>attractive because there is no procedure to do it.  However, this
>discussion has raised a few situations where this might be considered
>the appropriate action.
>
>The IAB, in their oversight role, must approve the general policy
>followed by the RFC Editor.  So, I am asking the IAB to consider the
>potential need to withdraw an RFC.  Hopefully this will never be
>needed, but some thought about the way that it would be handled will
>be useful, just in case.
>
>Many thanks,
>    Russ Housley
>    IETF Chair
>
>
>On Jun 23, 2015, at 12:19 PM, Ted Hardie wrote:
>
> > Jefsey recently put this forward on the IANAplan mailing list:
> >
> > "Draft is subject to my appeal. It should not therefore be 
> published before the RFC 2026 procedure - which may involve ISOC - 
> is completed"
> >
> > This is a pretty clear signal that he will further appeal to the 
> ISOC board should we deny his appeal.  It seems further likely that 
> he will do so at the last possible moment, to delay the publication 
> as much as possible.
> >
> > I think this means we should examine the appeal as quickly as 
> possible so that the response and shift up the chain do not add to 
> the potential delay.
> >
> > I am willing to help prepare a draft response from the IAB, if 
> there are one or two others who will join in.
> >
> > Ted
> > _______________________________________________
> > Iab-Vote mailing list
> > Iab-Vote@lists.i1b.org
> > http://lists.i1b.org/listinfo.cgi/iab-vote-i1b.org
>
>On Jun 23, 2015, at 11:56 AM, Jefsey 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.
> >
> > 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.
> >
> > jfc
> >
> >
> >
> > At 15:51 23/06/2015, Eliot Lear wrote:
> >
> >
> >
> >> On 6/23/15 8:36 AM, Brian E Carpenter wrote:
> >> > I'm not sure I understood Dave's plan, but what I would suggest (which
> >> > doesn't involve any bargaining chips as far as I can see) is:
> >> >
> >> > 1. State that the IETF Trust is the most appropriate vehicle to hold
> >> > the IANA IPR as an asset for the entire Internet community. I think
> >> > that would be a useful addendum to the IANAPLAN document, but it
> >> > shouldn't be allowed to hold up the RFC publication.
> >>
> >> That document is in the RFC Editor queue but is being held for the final
> >> combined document (that has been the plan all along) so that we can
> >> either reference or append it to make clear what the final outcome was,
> >> for the record.  We do not normally amend other text beyond the
> >> agreement, but this is entirely up to the area director.  I do wonder if
> >> it would be useful to include as appendices consensus positions such as
> >> that reached on February 19th in response to the ICG query.
> >>
> >> If rough consensus has evolved to a different point, that would be
> >> useful to clarify.  But again, I would suggest that the point here is
> >> not to tell the Trust that we require that the domain and the trademark
> >> and IPR be held, but rather that we simply state that it is our desire
> >> to retain rights to use of them, should the IFO change, and how that
> >> happens is a matter of discussion between lawyers and those who are
> >> negotiating on our behalf, and not engineers.
> >>
> >> Eliot
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Ianaplan mailing list
> >> Ianaplan@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ianaplan
> >
> > _______________________________________________
> > Ianaplan mailing list
> > Ianaplan@ietf.org
> > https://www.ietf.org/mailman/listinfo/ianaplan