[CWG-Stewardship] For your review - version V3.3
Avri Doria
avri at acm.org
Wed Apr 22 05:02:51 UTC 2015
Hi,
Steve. Yes it is those things you enumerated that I was referring to.
Thanks for helping me become clear.
And I am not lumping them in with any policy decisions currently being
made. In fact that is the crux of my question: where will these
decisions be made? The PTI Board? If so we should make sure it is
reflected in the list.
avri
On 22-Apr-15 00:40, Steve Crocker wrote:
>
> On Apr 21, 2015, at 7:17 PM, Avri Doria <avri at acm.org
> <mailto:avri at acm.org>> wrote:
>
>> Hi,
>>
>> Financial control is not the only kind of control. One form of
>> control that the protocol operational community has is that they
>> define all of the directories held by IANA and can change those with
>> protocol actions. The transition does not change this. Nor am I
>> recommending we tackle this particular problem at the moment. But I
>> want to make sure it is flagged.
>>
>> One of the long term issue we have is that the IETF is also the one
>> that controls the DNS protocols, DNSSEC, and any new protocl elements
>> that may be created in the future. The degree to which IANA adopts
>> future protocols and protocols elements is a decsion that is somehwat
>> orphaed at the moment. Who makes those decisions.
>
> Avri,
>
> I too am confused by your comment. The main job of IANA with respect
> to protocols is to publish the protocol parameters developed by the
> IETF. They make no decisions about the protocols or their adoption.
>
> In the particular area of the root, IANA functions as the single
> registrar for the root. Evolutions in the technology for DNS can
> affect the IANA operation, and thus there’s a practical question of
> when the IANA operation implements whatever is necessary to support
> the changes. The changes that I can recall are:
>
> o the addition of IPv6 records to the root for those servers that
> have IPv6 addresses, with the name servers for the root being a
> particular case that was dealt with separately,
>
> o the insertion of IDNs into the root zone, and
>
> o the support DNSSEC including signing the root and acceptance of DS
> records from TLD operators and publishing them in the root.
>
> If these are the sorts of things you’re referring to, I fully agree
> this is vital. It is also vital that the decisions related to these
> changes be managed by people who understand the technical issues.
> These are policy decisions in the sense that some value judgments are
> needed, but they are qualitatively different from the value judgments
> involved in, say, delegation or redelegation, and should not be lumped
> into the same basket.
>
> Steve
>
>
>
>
>
>>
>> And this is where the financial comes back in, because as the sole
>> financial source, ICANN does control the funds available to any
>> protocol innovation.
>>
>> In some sense this may seem an irrelevant issue, after all there are
>> no protocol actions pending at the moment, and I know I should not
>> worry about things that might happen but which are not currently
>> happening. I do, however, think that we have a hole in our solution
>> at the moment. Who makes these decisions? Is it the PTI? I assume
>> that up until now, this has been an ICANN management decision. Or
>> does the IETF have technical oversight over the IANA operations vis a
>> vis architecture, protocol and operational guidelines?
>>
>> I think we need to know the answers to these questions.
>>
>> avri
>>
>> On 21-Apr-15 15:27, Milton L Mueller wrote:
>>> David
>>> I think you are missing my point. I simply call attention to the
>>> fact that IANA is inside of and its staff are employees of an
>>> organization (ICANN) that is overwhelmingly driven by names
>>> community priorities and finances. Do you seriously dispute that?
>>>
>>> By “control” I meant that IANA’s management were all hired by ICANN
>>> and accountable to ICANN’s board and dependent on ICANN’s budget. I
>>> do not of course, mean that ICANN tries to control IETF processes or
>>> numbering processes.
>>>
>>> It is wildly inaccurate, and undermines the credibility of your
>>> comment, to suggest that IANA was “controlled” by the protocols
>>> community simply because maintaining protocol registries accounts
>>> for a lot of the work. The protocols community stopped participating
>>> in ICANN as a stakeholder more than a decade ago, when the PSO was
>>> ended; it contributes no money to ICANN and has no voting board
>>> member. It’s only ‘control’ over IANA is an MoU of unclear legal
>>> status which gives it the right to walk away from it and find
>>> another registry should it want to. That gives IETF a lot of control
>>> over who it uses for IANA, but very little control over the IANA
>>> that resides inside ICANN.
>>>
>>> ICANN as an organization is financed primarily by the names
>>> community (more than 95% of its revenues) and probably more than 95%
>>> of what it does is about names policy and naming-related issues. And
>>> that’s important, because as long as the management and
>>> accountability of the IANA functions for ALL operational communities
>>> are lodged inside an entity so dominated by ONE community there is
>>> an asymmetry in the institutional architecture that is problematic.
>>> NTIA oversight mitigated that somewhat, but that is going away.
>>>
>>> I know that ICANN employees don’t like to be reminded of ICANN’s
>>> design flaws, but I don’t think that gives you license to dismiss
>>> reasonable statements as exaggerated or unhelpful.
>>>
>>> --MM
>>>
>>> *From:* David Conrad [mailto:david.conrad at icann.org]
>>> *Sent:* Tuesday, April 21, 2015 2:55 PM
>>> *To:* Milton L Mueller
>>> *Cc:* 'cwg-stewardship at icann.org'
>>> *Subject:* Re: [CWG-Stewardship] For your review - version V3.3
>>>
>>> Milton,
>>>
>>> I don't think these sorts of exaggerated statements are helpful.
>>>
>>> Historically, in terms of workload and policy setting, IANA was
>>> "controlled" far more by the protocol parameter community than the
>>> names operational community (which is, of course, a subset of the
>>> ICANN community). And it is certainly not the case that the IANA
>>> functions were "operated" by the names operational community — IANA
>>> staff were not related to that community at all. I don't believe
>>> that has changed all that much since I ran the IANA functions.
>>>
>>> Regards,
>>> -drc
>>>
>>> *From: *Milton L Mueller <mueller at syr.edu <mailto:mueller at syr.edu>>
>>> *Date: *Tuesday, April 21, 2015 at 11:32 AM
>>> *To: *'Martin Boyle' <Martin.Boyle at nominet.org.uk
>>> <mailto:Martin.Boyle at nominet.org.uk>>
>>> *Cc: *CWG Mailing List <cwg-stewardship at icann.org
>>> <mailto:cwg-stewardship at icann.org>>
>>> *Subject: *Re: [CWG-Stewardship] For your review - version V3.3
>>>
>>>
>>> Martin
>>> I also think Andrew’s clear distinction between IANA and
>>> names-related IANA functions was correct.
>>>
>>> Because IANA is currently controlled and operated by the names
>>> operational community (ICANN), there is no way for a names
>>> proposal to _/not/_ touch on numbers or protocol parameters in
>>> some way. That is the “design flaw” that makes the names part of
>>> this hard. The legal separation makes this issue less of a
>>> problem but will require some coordination and adjustment by the
>>> other OCs. But that is not a big deal; the numbers proposal
>>> already required some adjustment and coordination by the
>>> protocols community. There is no way to avoid these
>>> interdependencies. But adjustments to facilitate compatibility
>>> are not the same as one OC telling another what to do.
>>>
>>> --MM
>>>
>>> *From:*cwg-stewardship-bounces at icann.org
>>> <mailto:cwg-stewardship-bounces at icann.org> [mailto:cwg-stewardship-bounces at icann.org] *On
>>> Behalf Of *Martin Boyle
>>> *Sent:* Tuesday, April 21, 2015 12:33 PM
>>> *To:* Greg Shatan; Alissa Cooper
>>> *Cc:* cwg-stewardship at icann.org <mailto:cwg-stewardship at icann.org>
>>> *Subject:* Re: [CWG-Stewardship] For your review - version V3.3
>>>
>>> I think that Greg is right, that we were not mandated in the CWG
>>> to look at numbers or protocol parameters. While that might sit
>>> uneasily, I’m not sure I really know about the flow of funding
>>> or the accountability/stewardship role in the light of Milton’s
>>> assertion.
>>>
>>> Specifically asking CRISP & IANAPLAN for views as to where they
>>> would see their relationship lying (given the ring-fencing of
>>> the IANA functions operator into a subsidiary in ICANN) would
>>> seem to me to be appropriate. They could, after all,
>>> contract/sign an MoU with either ICANN or ICANN’s affiliate.
>>>
>>> Martin
>>>
>>> *From:*cwg-stewardship-bounces at icann.org
>>> <mailto:cwg-stewardship-bounces at icann.org> [mailto:cwg-stewardship-bounces at icann.org] *On
>>> Behalf Of *Greg Shatan
>>> *Sent:* 21 April 2015 17:14
>>> *To:* CW Lists
>>> *Cc:* cwg-stewardship at icann.org <mailto:cwg-stewardship at icann.org>
>>> *Subject:* Re: [CWG-Stewardship] For your review - version V3.3
>>>
>>> I agree with Alissa that this needs to be clarified. Some of
>>> the lack of clarity is due to concern about having a proposal
>>> that goes beyond naming functions. This has resulted in some
>>> odd phrasings and odd proposals.
>>>
>>> In my view, splitting the IANA personnel and assets so this is a
>>> "names-only" proposal is unrealistic and unnecessary. Because we
>>> are within ICANN, we have a different relationship to the IANA
>>> Functions group. We should make it clear that the whole ball of
>>> wax would move to PTI, and put that out for public comment. We
>>> should flag this specifically for the CRISP and IANAPLAN group.
>>>
>>> Greg
>>>
>>> On Tue, Apr 21, 2015 at 11:58 AM, Greg Shatan
>>> <gregshatanipc at gmail.com <mailto:gregshatanipc at gmail.com>> wrote:
>>> In this instance, I agree with Christopher. I believe both
>>> statements are accurate (though the first is less than
>>> mellifluous in its phrasing).
>>>
>>> Greg Shatan
>>>
>>> On Tue, Apr 21, 2015 at 11:36 AM, CW Lists
>>> <lists at christopherwilkinson.eu
>>> <mailto:lists at christopherwilkinson.eu>> wrote:
>>> I prefer the existing text, unchanged.
>>>
>>> CW
>>>
>>>
>>> On 21 Apr 2015, at 16:47, Brenden Kuerbis <bnkuerbi at syr.edu
>>> <mailto:bnkuerbi at syr.edu>> wrote:
>>>
>>>
>>> Hi Marika,
>>>
>>> The first bullet in Section III.A says:
>>>
>>>
>>> ICANN, through an affiliate controlled by ICANN, to
>>> continue as the IANA Functions Operator for the Naming
>>> Related Services through the creation of a separate
>>> legal entity, Post-Transition IANA (PTI).
>>>
>>>
>>> Section III.A.i.a, which is text provided by Sidley in
>>> consultation with the CWG, says:
>>>
>>>
>>> A contract would be entered between PTI and ICANN, which
>>> would give PTI the rights and obligations as the IANA
>>> Functions Operator.
>>>
>>>
>>>
>>> I believe the latter statement is correct, and the prior
>>> bullet is inconsistent with it (or at least very unclear).
>>> Perhaps Sidley could provide more accurate text for the
>>> bullet in Section III.A, or I would suggest:
>>>
>>>
>>> ? Creation of a legally separated affiliate,
>>> Post-Transition IANA (PTI), to provide the IANA functions.
>>>
>>>
>>> This would be followed by the existing bullets:
>>>
>>>
>>> ? Establishment of service level agreement
>>> between ICANN and PTI, the IANA Functions Operator for
>>> the Naming Related Services.
>>> ? Changes proposed to root zone environment and
>>> relationship with root zone maintainer.
>>>
>>>
>>>
>>>
>>>
>>> -- Brenden
>>>
>>> On Mon, Apr 20, 2015 at 2:50 PM, Marika Konings
>>> <marika.konings at icann.org <mailto:marika.konings at icann.org>>
>>> wrote:
>>> Dear All,
>>>
>>> Please find attached an updated draft which now
>>> incorporates, amongst others, a summary for section III, DT
>>> X, information from the legal memo, updates as a result of
>>> comments received and proposed text for section IIIB. Note
>>> that we’ve also reorganised the annexes to match the flow of
>>> the document.
>>>
>>> _Please note that that there a number of comments that have
>>> been flagged that need further consideration by the
>>> different DTs. We would like to encourage the leads of the
>>> DTs to pick up on the items that have been flagged for
>>> review and provide feedback on those items to the CWG
>>> mailing list as soon as possible._
>>>
>>> Also, note that we’ve incorporated those edits and/or
>>> comments that we considered corrections and/or
>>> clarifications of existing content as well as responses to
>>> some of the Sidley comments. If you do not agree with those
>>> responses or updates or are of the view that these are more
>>> than corrections and/or clarifications, please flag those
>>> accordingly.
>>>
>>> You are encouraged to flag any items that you think warrant
>>> CWG consideration by Tuesday 20 April at 16.00 UTC at the
>>> latest. Other minor edits and/or clarifications can be
>>> submitted until Tuesday 20 April 23.59 UTC.
>>>
>>> For your convenience I’ve attached a redline and clean
>>> version both in Word as well as pdf.
>>>
>>> Thanks again for all your feedback!
>>>
>>> Marika
>>>
>>> _______________________________________________
>>> CWG-Stewardship mailing list
>>> CWG-Stewardship at icann.org <mailto:CWG-Stewardship at icann.org>
>>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> CWG-Stewardship mailing list
>>> CWG-Stewardship at icann.org <mailto:CWG-Stewardship at icann.org>
>>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> CWG-Stewardship mailing list
>>> CWG-Stewardship at icann.org
>>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>
>>
>>
>> ------------------------------------------------------------------------
>> Avast logo <http://www.avast.com/>
>>
>> This email has been checked for viruses by Avast antivirus software.
>> www.avast.com <http://www.avast.com/>
>>
>>
>> _______________________________________________
>> CWG-Stewardship mailing list
>> CWG-Stewardship at icann.org <mailto:CWG-Stewardship at icann.org>
>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150422/92763bd9/attachment-0001.html>
More information about the CWG-Stewardship
mailing list