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

Seun Ojedeji <seun.ojedeji@gmail.com> Sat, 08 November 2014 18:04 UTC

Return-Path: <seun.ojedeji@gmail.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 97D1D1A6F39 for <ianaplan@ietfa.amsl.com>; Sat, 8 Nov 2014 10:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level:
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] 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 rIKwjTc5ENW7 for <ianaplan@ietfa.amsl.com>; Sat, 8 Nov 2014 10:04:40 -0800 (PST)
Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1BA1A1A92 for <ianaplan@ietf.org>; Sat, 8 Nov 2014 10:04:39 -0800 (PST)
Received: by mail-qa0-f45.google.com with SMTP id dc16so3712494qab.18 for <ianaplan@ietf.org>; Sat, 08 Nov 2014 10:04:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=u+W7uIt60NboIgrsfr+l6J74qCX151QTErAPfMOWlmc=; b=Ozx1j4V2c+HUW9JoJOJ8++pPKGzIXi5h1J6soZt7+DreiK6I67+u9uJpkPgsTHthl4 h9iQu45ImUKeykOxFsTxfOduUSG8D4aQSac/pXXfYO5XAnTmiiUW3Nup0S7TW8OFwySp PGTYlCxkDbGdS75DcHu7hfs3X2G0bEuZIlQq1VGKIoHCjAwf+JS8uduf8X+QT1qk5Ogj SGdu7ynjYC8AD79DSB4H8RuC4r90m9nVG+9PJdmk1qz1T96meSW3KX/6Hkh9jgAy8Tss 8461cgiP3tglriIVeXstZp6iNVfc/q4mqoYJTHnyKOk8uUxMccIfN6DrBIOO9P3MLPL3 v4vA==
X-Received: by 10.224.55.70 with SMTP id t6mr29217998qag.83.1415469879008; Sat, 08 Nov 2014 10:04:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.229.87.66 with HTTP; Sat, 8 Nov 2014 10:04:08 -0800 (PST)
In-Reply-To: <ED92F18D-AEFF-4A02-A22F-7CD3E6C72FB5@gmail.com>
References: <GLEAIDJPBJDOLEICCGMNIEOJCNAA.rhill@hill-a.ch> <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> <545ABCB0.5080206@meetinghouse.net> <8f3dcda6c3db4cd8be1b77444f987d59@EX13-MBX-13.ad.syr.edu> <D0805C27.136BE7%jon.peterson@neustar.biz> <059f2b06a7b44f09b7568d8966861fb8@EX13-MBX-13.ad.syr.edu> <D0824FAD.137A42%jon.peterson@neustar.biz> <bcb86b6995de41feba256567c114265d@EX13-MBX-13.ad.syr.edu> <CAD_dc6jaDbiw4kwy3yv9CwxK3SUDun1cC2Z1tSA1drGT+-qfig@mail.gmail.com> <ED92F18D-AEFF-4A02-A22F-7CD3E6C72FB5@gmail.com>
From: Seun Ojedeji <seun.ojedeji@gmail.com>
Date: Sat, 08 Nov 2014 19:04:08 +0100
Message-ID: <CAD_dc6h-F1Hk6-RyxfCc4NDg0XJobSbAPf_X2juEgps6hG6EDA@mail.gmail.com>
To: Suzanne Woolf <suzworldwide@gmail.com>
Content-Type: multipart/alternative; boundary="047d7bd7568a5427ca05075cc393"
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/peSOzGYxTF40LDTHD6DivHmPtG4
Cc: "ianaplan@ietf.org" <ianaplan@ietf.org>
Subject: Re: [Ianaplan] IETF's role Re: 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: Sat, 08 Nov 2014 18:04:43 -0000

On Sat, Nov 8, 2014 at 3:59 PM, Suzanne Woolf <suzworldwide@gmail.com>
wrote:

>
> On Nov 7, 2014, at 4:16 PM, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
>
> Have been following the discussions and it's been quite interesting; much
> more interesting that it almost seem iana.org ownership is the deciding
> factor in this process[1].
>
> Have you read the draft?
>
> It seems to me that if you review both the mailing list and the draft, the
> work that's necessary for the IETF to reach consensus on what should go
> into the RFP response is mostly done.
>

Yes i have and as you may have noticed i referred to "discussion" and not
the "actual draft" which was my reason for wondering on why iana.org is
getting discussed in such a detail. However by interpreting your response i
presume its saying "....discussions can continue in an unstable manner but
the actual proposal is stable....". which is fine!

>
> It should perhaps also seem that most of the experienced IETF participants
> here don't regard anything about the iana.org domain name as "the
> deciding factor" in much of anything. Most of the pressure to make more of
> a point of what should happen to it in the event of a dispute is coming
> from people who are obviously deeply concerned about the future of the
> Internet, but whose primary experience of the IANA functions is not in the
> protocol parameters area or in how the IETF and its user communities
> interact with the IANA operator.
>

Well yes i observed that. However, i would also note that the young shall
grow, i for one am learning in all these ;)

> The extent of back and fourth deliberation on the list, makes me wanna
> mention here that it will be good for IETF to start handling/addressing
> issues not only as a protocol parameter community but as the overall source
> of all the whole function.
> For all it's worth, those who don't want to complicate the outcome of this
> process have great hope in IETF playing a leadership role in all these.
>
> I'm curious what you mean by this comment. Who thinks the IETF should be
> functioning here "not only as a protocol parameter community," what do they
> want instead, and how are they planning to make their requests or desires
> known?
>
>
Well there have been some throwing of question of authority on this mailing
list (and other lists as well) and from indication i sense IETF (at least
the experienced folks) does not want to own-up to the fact that it can
provide the minimal oversight to get things going administratively. IETF
has done this on the policy realm in the past and it has worked well, even
for names it worked because the names PDP has one of the highly inclusive
multistakeholder platform. Here is another call to do this in the
administrative side things.

As "the overall source of all the whole function," the IETF long ago
> delegated administration of certain protocol parameters to organizations
> deemed better able to address the related public policy concerns than the
> IETF is, or wants to be.  Are you suggesting revisiting that?
>

And here is my point, what was mainly separated and assigned is the
respective PDP and not necessarily the ability to move IANA (ofcourse there
was no need for that then). However we are now indirectly separating the
functions on paper in a manner going in the direction of policy. This IMHO
does not help this process; its going to be helpful if the function still
gets handled by a single operator. The current issue at hand is not a
policy issue, but an issue that i think requires the source(being IETF) to
indicate its willingness to take charge (minimal charge of being able to
move IANA to another operator)

> I am beginning to wonder if this is the case.
>
> It looks to me as if the IETF is playing its part in a multi-stakeholder
> process, in which each of the operational communities directly affected by
> the IANA functions is expected to propose a transition plan for its area of
> concern. As far as I'd understood, and the ICG members here can certainly
> elaborate but the extensive public record is pretty clear, the ICG is then
> responsible for addressing gaps or conflicts between operational community
> plans. Its primary mechanism for resolving those conflicts is by engaging
> the affected operational communities to do so.
>

Yeah and that splitting of the discussion IMO was one of the reasons why we
may end up having a issue when its time for a single proposal. I don't know
why we so much believe ICG will do some magic in putting the document
together especially if what was proposed already reflect an absolute
disconnect.[1]

>
> Certainly if later trouble can be avoided by communities collaborating
> now, we ought to try to make that happen. What do you think is missing?
>
> I would expect each of the 3 operational communities to be in sync
(perhaps through the chairs) and be available to directly answer question
on their present roles and future roles consideration in other to better
inform the proposal preparations. We generally need to address the
disconnect among the 3 operational communities because going forward, IANA
functions is still preferred to be handled centrally. This transition
process is something that we(at least I) don't want to repeat and if care
is not taken we may look back and realise we have wasted so much resources
without achieving an absolute goal

Thanks

Cheers!
1. According to the ICG process, it says it will go back to the community
if such happens. It will be interesting if we had to repeat that process

>
> thanks,
> Suzanne
>
> Thanks.
>
> Returning back to listening mode. ;)
>
> Cheers!
> 1. Which IMO should just be a minimal component in this process especially
> as ntia is not the owner of the domain in the first place.
> sent from Google nexus 4
> kindly excuse brevity and typos.
> On 7 Nov 2014 21:26, "Milton L Mueller" <mueller@syr.edu> wrote:
>
>> > -----Original Message-----
>> > Asking for a transfer sounds like a polite thing to do. Directing the
>> IAOC to
>> > "conclude a supplemental agreement" which "requires the transfer of any
>> > associated marks and identifiers" - as the -02 text of the document
>> reads
>> > - sounds to me like an ultimatum which would antagonize other
>> > stakeholders.
>>
>> OK. I see the difference in the attitude with which we approach this. I
>> am beginning to think it is a purely attitudinal matter and not all that
>> substantive. So I have more sympathy for your position now but I still
>> think you are focusing on the wrong things.
>>
>> A request to the IAOC to "conclude an agreement" that "requires the
>> transfer" is not an "ultimatum" it is a proposal for a rather impersonal
>> set of institutional changes that sets the stage for long-term
>> accountability improvements in Internet governance.
>>
>> To put it more concretely, we are not talking to "nice people" sitting
>> across the dinner table from us, asking them to pass the salt. We are
>> trying to set the parameters for long term interactions among impersonal
>> organizational entities and functions.
>>
>> So if I were you I would focus on whether it is a good idea - for the
>> general good of the Internet and for the IETF - for to have control of the
>> iana.org domain and the trademark in the hands of the IETF trust or
>> whether it is better for the public and the IETF to have it in the hands of
>> ICANN. That's all that matters. The purpose of this exercise is to
>> rearrange the institutional design to accommodate the withdrawal of the
>> NTIA. The purpose is not to be polite or nice, or to avoid offending
>> anyone. The purpose is to get it right.
>>
>> If you sincerely believe that IETF should be permanently locked in to
>> ICANN as IANA provider, should have no choice as to who performs those
>> functions for it, and therefore the marks and domain should stay with
>> ICANN, then fine. Please argue that position. I will engage with those
>> arguments respectfully. But please let's not argue about etiquette!
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> Ianaplan mailing list
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan
>
>


-- 
------------------------------------------------------------------------





*Seun Ojedeji,Federal University Oye-Ekitiweb:      http://www.fuoye.edu.ng
<http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email:
<http://goog_1872880453>seun.ojedeji@fuoye.edu.ng
<seun.ojedeji@fuoye.edu.ng>*

The key to understanding is humility - my view !