[CWG-Stewardship] ICANN Board as "regulator" (was: A liaison from the Board to CWG)

Wed Feb 25 08:42:11 UTC 2015

As a reminder, if you have any issues that you think are relevant for a
design team please provide the group with a submission of name, a brief
description of topic and scope and finally an indication of who should to
be lead of the team.

Included are an example of relevant design teams, the ³Draft Working
methods² and ³Draft Design team Guidelines². These have also been posted
on the wiki (see https://community.icann.org/x/pAknAw).

Best regards,

Marika

On 24/02/15 22:30, "Milton L Mueller" <mueller at syr.edu> wrote:

>David
>I view these as highly constructive comments and would support creation
>of a "design team" around them. Indeed, it's the only one I see as being
>really needed at the present time. You may recall that I supported also
>your earlier comment about root signing.
> 
>Not sure we agree 100% on the independence of these issues from the
>accountability models, but I do agree that we can discuss them
>productively and perhaps develop requirements for them without committing
>anyone to a particular model, especially now that the ASK model has moved
>us toward some kind of middle ground.
>
>--MM
>
>> -----Original Message-----
>> From: David Conrad [mailto:david.conrad at icann.org]
>> Sent: Tuesday, February 24, 2015 1:58 PM
>> To: Milton L Mueller
>> Cc: cwg-stewardship at icann.org
>> Subject: Re: [CWG-Stewardship] ICANN Board as "regulator" (was: A
>>liaison
>> from the Board to CWG)
>> 
>> Milton,
>> 
>> >I am flattered that you view me as personally responsible for keeping
>>the
>> >CWG on mission.
>> 
>> I'll bill you for the replacement of my irony meter.
>> 
>> >You are of course correct that the NTIA is in the loop for all root
>>zone
>> >changes.
>> 
>> NTIA being "in the loop" for root zone changes is a relatively minor
>> issue, easily dealt with in a variety of ways.
>> 
>> Traditionally (well, since the creation of ICANN), NTIA has also been
>>"in
>> the loop" for pretty much all substantive changes related to the
>>structure
>> and operation of the root of the DNS, e.g., the decision on whether and
>> how to sign the root (requiring proposals from both ICANN and Verisign
>>and
>> ultimately choosing the Verisign proposal after their internal
>> evaluation), the mechanism by which the plan for rolling the root Key
>> Signing Key is defined, the decision about whether and how to add
>> internationalized top-level domains, etc. Even the very definition of
>>the
>> "three-legged stool" by which NTIA has inserted itself into the
>>operation
>> of all root zone changes via the IANA Functions Contract and the
>> Cooperative Agreement with Verisign must change.
>> 
>> Yet, to my knowledge, the mechanism(s) by which issues like these are
>> addressed in the post-NTIA world have not yet been discussed in any
>> detail.  Hopefully a "design team" will be spun up to look at the
>> mechanism by which issues like these can be addressed.
>> 
>> >But it cannot be discussed independently of the issue of whether IANA
>>is
>> >separable from ICANN or permanently locked into ICANN or structurally
>> >separated from the policy making entity.
>> 
>> Oh sure it can.
>> 
>> The mechanisms by which accountability of the IANA Function operator can
>> be ensured that have been discussed to date seem primarily to revolve
>> around pulling the IANA Functions away from ICANN and giving them to
>> someone else (even though no one actually wants to do that now as far
>>as I
>> can tell -- we're told it's for the future).
>> 
>> What the IANA Root Management Function Operator actually DOES insofar
>> as
>> it involves NTIA should (must IMHO) be independent of who actually
>> performs the function. As such, it is eminently possible to discuss
>> independently of whether the IANA functions are separable from ICANN or
>> not.
>> 
>> >It might even be more productive for you to suggest specific models for
>> >changes in the operational practice of root zone changes minus NTIA.
>> 
>> If you might recall, I did, describing one way in which flaws I see in
>>the
>> existing "three-legged stool" could be addressed. Long ago, I also tried
>> to get folks to address NTIA's direct involvement in root zone
>>management.
>> To little avail -- a small number of folks seem to redirect all
>>discussion
>> towards the accountability stuff.
>> 
>> In my opinion, while I would agree the accountability stuff is important
>> and needs to be addressed, it should not preclude addressing the other
>> critical issues associated with the transition.
>> 
>> Regards,
>> -drc
>> (ICANN CTO but speaking only for myself)
>_______________________________________________
>CWG-Stewardship mailing list
>CWG-Stewardship at icann.org
>https://mm.icann.org/mailman/listinfo/cwg-stewardship

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CWG-WorkMethods-PostSingapore-Final.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 27156 bytes
Desc: CWG-WorkMethods-PostSingapore-Final.docx
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150225/bb3379db/CWG-WorkMethods-PostSingapore-Final-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CWG-DesignTeamList.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 12002 bytes
Desc: CWG-DesignTeamList.xlsx
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150225/bb3379db/CWG-DesignTeamList-0001.xlsx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CWG-Guidelines for a CWG DesignTeam-Final[1].docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 27546 bytes
Desc: CWG-Guidelines for a CWG DesignTeam-Final[1].docx
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150225/bb3379db/CWG-GuidelinesforaCWGDesignTeam-Final1-0001.docx>