[CWG-Stewardship] A few additional comments for Š Two additional webinars on 6-7 May
Elise Gerich
elise.gerich at icann.org
Mon May 4 17:57:23 UTC 2015
Chuck,
Thank you for adding me to the cc list so that it is clear that the question
has been answered (thanks, Bernie and Bart).
Best,
-- Elise
From: <Gomes>, Chuck <cgomes at verisign.com>
Date: Monday, May 4, 2015 at 7:33 AM
To: Martin Boyle <Martin.Boyle at nominet.org.uk>, "ceo at auda.org.au"
<ceo at auda.org.au>
Cc: Milton L Mueller <mueller at syr.edu>, CW Lists
<lists at christopherwilkinson.eu>, Grace Abuhamad <grace.abuhamad at icann.org>,
"cwg-stewardship at icann.org" <cwg-stewardship at icann.org>, Elise Gerich
<elise.gerich at icann.org>
Subject: RE: [CWG-Stewardship] A few additional comments for Š Two
additional webinars on 6-7 May
> I just received the clarification I needed on this from Bernie and Bart. The
> IANA do the due diligence to ensure that the local laws/community issues are
> satisfied for ccTLDs. I had mistakenly thought that that was done by ICANN
> staff and reported to the IANA team. For gTLDs I do not believe that the IANA
> team needs to do any policy checking but just need the confirmation from the
> GDD team that policy is in order.
>
> I am fine with this. I see no problem at all that it is handled differently
> for gTLDs and ccTLDs. Also, if the ccTLD registries are fine with this, that
> is what matters.
>
> My only suggestion is that we are clear in communicating the difference in the
> IFO functions with regard to ccTLDs and gTLDs in cases where it is relevant.
>
> Note that I added Elise as a cc so that she knows that I have the answer to
> the question I asked her. Of course, if she wants to add more that is fine but
> may not be needed now.
>
> Chuck
>
>
> From: Gomes, Chuck
> Sent: Sunday, May 03, 2015 8:24 PM
> To: 'Martin Boyle'; Chris Disspain
> Cc: Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship at icann.org
> Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional
> webinars on 6-7 May
>
> Thanks Martin. I suspect that we are not far apart and much of what we are
> talking about may be semantics, i.e., terms that we are interpreting in
> different ways. That is probably easily fixable as Milton has indicated.
> Please see a few more comments below.
>
> Chuck
>
>
> From: Martin Boyle [mailto:Martin.Boyle at nominet.org.uk]
> Sent: Sunday, May 03, 2015 6:29 PM
> To: Gomes, Chuck; Chris Disspain
> Cc: Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship at icann.org
> Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional
> webinars on 6-7 May
>
> Chuck,
>
>> > What is the board doing when it approves a ccTLD delegation if it is not
>> making a decision?
>
> I think it is just checking that its operators have followed due process and
> have documented the final decision. The decision should have been made
> locally/nationally and it is not really for the ICANN Board to challenge or
> overrule a decision made in another country, just to check that the job has
> been done. The IANA Functions Operator usually encourages contending parties
> come to a mutual agreement and the whole process is pretty delicate.
> [Chuck Gomes] Who are Œits operators¹? I get the impression that you mean the
> IANA team? Is that correct? If so, I need to have a clearer understanding of
> what the IANA team does with regard to checking due process. As you can
> probably tell, I didn¹t think the IANA team did any checking with regard to
> policy due process whether it be GNSO policy for gTLDs or local law for ccTLDs
> or ccNSO policy (e.g., for IDN TLDs). My understanding has been that such
> checking is done by non-IANA ICANN staff in both cases. Regardless, I think
> it is possible for us to reach agreement with regard to PTI functions. But I
> do believe that it is essential for us all understand on what the IFO does
> with regarding to checking what you call due process. That is why I asked the
> questions of Elise.
>
>> > PTI does not make any decision regarding whether policy has been followed
>> except for technical policy
>
> I¹m still not really sure I know what you mean by technical policy. I think
> the PTI assesses whether requests fit the requirements of RFC1591 and
> encourages local resolution of disputes. In the case of continued disputes,
> the final decision would need to be according to local due process. Elise
> might be able to explain how they currently assure themselves that the process
> has concluded.
> [Chuck Gomes] The word policy is used very broadly by many people in the
> community. Technical standards and operational best practices are sometimes
> referred to as policy. That is what I mean by technical policy to distinguish
> it from TLD policy developed within ICANN. Technical policy would be
> developed by the ASO and IETF; any of those policies that relate to the DNS
> and the root zone are checked by the IFO and the Maintainer. What I mean by
> Œnon-technical policy¹ are policies like the New gTLD Policy developed by the
> GNSO or the IDN ccTLD Policy developed by the ccNSO.
>
> The Board of the new entity would, I guess, want to ascertain that its staff
> is doing a good job and that might include whether a delegation conforms to
> agreed policy and to local decisions (³C.2.9.2.c Š the Contractor will consult
> with the interested and affected parties, as enumerated in Section C.1.3;
> relevant public authorities; and governments on any recommendation that is not
> within or consistent with an existing policy framework. In making its
> recommendations, the Contractor shall also take into account the relevant
> national frameworks and applicable laws of the jurisdiction that the TLD
> registry serves.²) Due diligence would suggest a need to check that due
> process has been flowed within the IFO, and that the process and
> recommendation have been properly documented.
>
> However, as I said to Milton last night, it had not occurred to me to put the
> check back to the ICANN Board. I¹m still not sure I understand why that would
> be a good idea. In the case of a decision being made in the relevant
> jurisdiction, should verification of due process and documentation be able to
> do anything more than refer back and seek clarification? I think not. In
> which case, why would we separate an integral part of the SOW from the PTI
> when we are introducing legal separation?
>
>
> Does that answer your questions?
>
> Martin
>
>
>
> From: Gomes, Chuck [mailto:cgomes at verisign.com]
> Sent: 03 May 2015 15:54
> To: Chris Disspain; Martin Boyle
> Cc: Milton L Mueller; CW Lists; Grace Abuhamad; cwg-stewardship at icann.org
> Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional
> webinars on 6-7 May
>
> What is the board doing when it approves a ccTLD delegation if it is not
> making a decision?
>
> It seems to me that we are in agreement that PTI does not make any decision
> regarding whether policy has been followed except for technical policy. Is
> that correct?
>
> Chuck
>
>
> From: Chris Disspain [mailto:ceo at auda.org.au]
> Sent: Saturday, May 02, 2015 9:41 PM
> To: Martin Boyle
> Cc: Gomes, Chuck; Milton L Mueller; CW Lists; Grace Abuhamad;
> cwg-stewardship at icann.org
> Subject: Re: [CWG-Stewardship] A few additional comments for Š Two additional
> webinars on 6-7 May
>
> Matin + 1.
>
>
>
>
>
> Cheers,
>
>
>
> Chris
>
>
>
> On 3 May 2015, at 08:16 , Martin Boyle <Martin.Boyle at nominet.org.uk> wrote:
>
>
> Chuck, comments in line below.
>
>
>
> From: Gomes, Chuck [mailto:cgomes at verisign.com <mailto:cgomes at verisign.com> ]
> Sent: 01 May 2015 14:37
> To: Martin Boyle; Milton L Mueller; 'CW Lists'; 'Grace Abuhamad'
> Cc: 'cwg-stewardship at icann.org <mailto:cwg-stewardship at icann.org> '
> Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional
> webinars on 6-7 May
>
>
>
> Martin/Milton,
>
>
>
> Please note my understandings below.
>
>
>
> Chuck
>
>
>
> From: Martin Boyle [mailto:Martin.Boyle at nominet.org.uk
> <mailto:Martin.Boyle at nominet.org.uk> ]
> Sent: Friday, May 01, 2015 6:44 AM
> To: Milton L Mueller; Gomes, Chuck; 'CW Lists'; 'Grace Abuhamad'
> Cc: 'cwg-stewardship at icann.org <mailto:cwg-stewardship at icann.org> '
> Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional
> webinars on 6-7 May
>
>
>
> Obviously then I¹m misunderstanding something Milton.
>
>
>
>> > The IANA Functions operator (IFO) should simply take ICANN¹s instructions.
>
> [Chuck Gomes] I think this is mostly accurate but I qualify that below.
>
>
>
> Err, no! The IANA functions operator should base its decisions on agreed
> policy. In ccTLD cases, rfc1591 is now supplemented (informed) by the work of
> the Framework of Interpretation Working Group. It also has advice from the
> GAC 2005 Principles. ICANN (as the Board) does not have a role in telling the
> IANA functions operator what to do in the case of ccTLD delegations or
> revocations.
>
> [Chuck Gomes] With regard to technical policy (i.e., Internet Standards), my
> understanding is that the IFO would check for compliance and does not need
> specific direction from ICANN in that regard so I think Martin is correct that
> the IFO doesn¹t rely on ICANN¹s instructions for its technical checks. But
> with regard to ccTLD delegations or revocations, I believe that a Board
> approval is required. I do not believe that the IFO is involved in any
> interpretation of ICANN policy; rather, ICANN staff confirms that ICANN policy
> has been followed. I know In the case of gTLDs, no Board action is needed for
> a delegation of a gTLD but ICANN staff confirms that GNSO policy has been
> followed before it ever gets to IANA involvement; it is not the IFO
> responsibility to do that.
>
>
>
> MB: I believe and Chris Disspain has explained the role to the ccNSO and to
> others the Board sees its role on delegations and revocations of ccTLDs as
> assessing a traffic-light report from the IANA functions operator staff: it
> is essentially a process and documentation check, although it could be used to
> approve a decision where strict adherence to policy (eg on engagement with
> interested parties in countries where this sort of approach is not carried
> out). In my mind it is not an instruction and the role could be done by a PTI
> Board which has responsibility for the provision of the IANA functions
> operator role.
>
>
>
> This is fundamental clear separation of policy and the IANA functions
> operator should not be undermined by ICANN giving instructions. And if I
> remember correctly this principle is clearly embodied in the SOW. And ICANN
> does not have the power to overrule national due processes.
>
> [Chuck Gomes] Agreed on the principle of separation policy development and the
> IFO and I think what I described in my previous comments above demonstrates
> clear separation but I am pretty sure that ICANN staff must give confirmation
> (instructions) that ICANN policy (in contrast to technical policy) has been
> satisfied regarding delegations or revocations. And I do not think that
> violates the principle of separating policy development from the IFO. I of
> course also agree that ³ICANN does not have the power to overrule national due
> processes² but I don¹t think that means that the IFO would be involved in
> interpreting national due process; isn¹t that ICANN¹s task?
>
>
>
> MB: For ccTLDs, I do not see where this role is performed. I¹d also be
> alarmed at other ccTLDs (and hence non-nationals) having a say over a ccTLD.
>
>
>
>> > I don¹t think the IFO should have discretion to make those decisions, it
>> should simply edit the zone file as directed.
>
> [Chuck Gomes] I think this is a correct statement as I have tried to describe
> above.
>
>
>
> MB: The IANA functions operator¹s role is surely (again for ccTLDs) to
> ascertain that the decision for change has properly been made (and all other
> decisions can be automated anyway. But the disagreement is who does have the
> discretion to make those decisions.
>
>
>
> The issue and hence the complexity is about who actually has the right to
> make the decisions and direct the IANA functions operator. The role of the
> IANA functions operator is to identify that a decision is appropriate and
> the SOW gives some guidance to that, as does the work of the FOIWG. But it is
> absolutely not ICANN¹s decision.
>
> [Chuck Gomes] From a technical point of view I agree but not beyond that. We
> would be getting into a very different situation if the IFO has to make
> decisions regarding whether ICANN policy or national due process is followed.
> That would mean that the IANA functions are much more than technical and
> clerical and it would require very different skills sets.
>
>
>
> MB: the IANA functions operator (and the current ICANN Board) role is not to
> make the decision, but to verify that the decision is appropriate and
> correctly made.
>
>
>
> Your failure to understand this is perhaps why you feel quite casual about
> re-bidding the IANA functions operation and I do not.
>
>
>
> The ccTLD community has seen the friction caused by ICANN imposing arbitrary
> conditions or questioning legitimate national decisions. (This history of
> this high-handed approach was one of the motivations for the 2005 GAC
> Principles.) I do not think that I¹m alone in wanting to avoid as much as
> possible having to start the learning process again with a new contractor.
>
> [Chuck Gomes] I definitely do not think that ICANN should impose arbitrary
> conditions or question legitimate national decisions but I do not believe that
> that means that the IFO should make those decisions. If we have disagreement
> on this, then I think we need to have some serious discussions so that we are
> all on the same page.
>
>
>
> MB: I am not arguing that the IANA functions operator makes the decisions.
> It is that the ICANN Board does not make decisions and give instructions.
>
>
>
> Martin
>
>
>
>
>
> From: Milton L Mueller [mailto:mueller at syr.edu <mailto:mueller at syr.edu> ]
> Sent: 30 April 2015 18:48
> To: Martin Boyle; 'Gomes, Chuck'; 'CW Lists'; 'Grace Abuhamad'
> Cc: 'cwg-stewardship at icann.org <mailto:cwg-stewardship at icann.org> '
> Subject: RE: [CWG-Stewardship] A few additional comments for Š Two additional
> webinars on 6-7 May
>
>
>
>
>
> Thanks for helping to highlight where you and I diverge, Milton. I¹d take
> changing the operator a lot more seriously than you!
>
>
>
> MM: I don¹t think we actually do diverge on this issue, Martin. See below.
>
>
>
> So whoever takes the IANA functions operator role will need to be aware of the
> back story and be able to command trust. It is not straight-forward and while
> I am sure there¹s a long list of people who would be able to update names,
> protocol parameters and the gTLD part of the TLD registries, I still struggle
> to think of who might be able to do the ccTLD piece and would also be
> generally trusted. (Clue it is not a TLD or a consortium of TLDs.)
>
>
>
> MM: The IANA Functions operator (IFO) should simply take ICANN¹s instructions.
> One benefit of a separated IFO would be the ability to more clearly separate
> those sensitive policy decisions that should really be made by ICANN, and
> those implementations that should be done by the IFO. I agree with you that
> ccTLD redelegations can be more sensitive than gTLD delegations, I don¹t think
> the IFO should have discretion to make those decisions, it should simply edit
> the zone file as directed. Do you disagree?
>
>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org <mailto:CWG-Stewardship at icann.org>
> https://mm.icann.org/mailman/listinfo/cwg-stewardship
> <https://mm.icann.org/mailman/listinfo/cwg-stewardship>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150504/32e5a1f0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5037 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150504/32e5a1f0/smime-0001.p7s>
More information about the CWG-Stewardship
mailing list