[CWG-Stewardship] For your review - version V3.3

Wed Apr 22 04:40:25 UTC 2015

On Apr 21, 2015, at 7:17 PM, Avri Doria <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>
>> Date: Tuesday, April 21, 2015 at 11:32 AM
>> To: 'Martin Boyle' <Martin.Boyle at nominet.org.uk>
>> Cc: CWG Mailing List <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] On Behalf Of Martin Boyle
>> Sent: Tuesday, April 21, 2015 12:33 PM
>> To: Greg Shatan; Alissa Cooper
>> Cc: 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] On Behalf Of Greg Shatan
>> Sent: 21 April 2015 17:14
>> To: CW Lists
>> Cc: 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> 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> wrote:
>> I prefer the existing text, unchanged.
>>  
>> CW
>>  
>>  
>> On 21 Apr 2015, at 16:47, Brenden Kuerbis <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> 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
>> 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
>> 
>>  
>>  
>> 
>> 
>> _______________________________________________
>> CWG-Stewardship mailing list
>> CWG-Stewardship at icann.org
>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
> 
> 
> 
> 	
> This email has been checked for viruses by Avast antivirus software. 
> www.avast.com
> 
> 
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-stewardship

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150421/df87d677/attachment-0001.html>