[CWG-Stewardship] FW: Naming Function Agreement Review document
Arasteh
kavouss.arasteh at gmail.com
Tue Aug 30 09:43:24 UTC 2016
Dear Keith,
Tks for your valuables analysed BUT CWG should not act and decides on behalf of GAC in toto and make a unilateral interpretation of such a very complex and perhaps political issue
Regards
Kavouss
Sent from my iPhone
> On 30 Aug 2016, at 11:06, Lindeberg, Elise <elise.lindeberg at Nkom.no> wrote:
>
> Dear Keith, CWG colleagues
>
> I think this CWG-discussions on purpose of documents and different subsection of policies shows exactly why we should leave it clean in the Naming Function Agreement, - with a general reference to relevant policies without subsections.
>
> I`m not arguing on the meaning of the preamble of the GAC principles, complex and significantly differences between countries regarding relations between national governments and CC registries, the intention of the FOI to codify policies relating to ccTLD management and so on... - It's about the formulation and shape of the Naming Function Agreement, and the fact that it's the Contractor that must consider and substantiate the relevance of listed policies - possibly with delicate cross-references to relevant subsections. Since we can't foresee all complexity and variations in future cases the Contractor have to deal with,we shouldn't try to balance this out on behalf of the Contractor at this stage.
>
> Best
>
> Elise
>
>
> Elise Lindeberg
> Senior Legal Adviser
> Norwegian GAC representative
> Norwegian Communications Authority
> Dir. +47 22 824607 Mob. +47 90190947
> ekl at nkom.no
>
>
>
> -----Opprinnelig melding-----
> Fra: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] På vegne av Keith Davidson
> Sendt: 30. august 2016 01:06
> Til: cwg-stewardship at icann.org
> Emne: Re: [CWG-Stewardship] FW: Naming Function Agreement Review document
>
> Hi all,
>
> Becky is completely correct in her statement below.
>
> 1. The GAC developed what they refer to as their "Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains" - and it is impossible to determine what the GAC considered what might be an actual policy principle, and what might be a guideline. In any case, the paper has never been through any formal ICANN Policy process, and there is no consensus from the community as to its adoption.
>
> 2. The Preamble of these GAC Principles and Guidelines states as 1.1 "The purpose of this document is to set out a general framework of principles and guidelines for the associated with that country, and the Internet Corporation for Assigned Names and Numbers (ICANN). However, the situation varies significantly between countries.
> This framework is intended to help establish, not constrain or dictate, the development of the three-way relationship. Governments, country code Top Level Domain (ccTLD) Registries and ICANN share the responsibility for ensuring a Domain Name System that is stable, secure, open, and easily accessible." So right from the outset, it is an encouragement to engage in dialogue between ICANN, the ccTLD operator and the relevant Government
>
> 3. As Becky points out below, these GAC Principles can (as per 1.3 of the document) only ever apply bindingly when the Government, the ccTLD and the Government agree they should. This statement also validates that existing ccTLD operations remain valid if any party refuses to accept the GAC Principles.
>
> 4. The work of the FOI Working Group and its predecessor Delegations and Redelegations Working Group examined many documents which attempted to codify policies relating to ccTLD management, including several RFC's, some ICANN created documents, and the two versions of the GAC Principles (from 2000 and 2005). These Working Groups were cross-constituency groups within ICANN, and included multiple members of the GAC constituency amongst the groups. The clear decisions of the Working Groups were that RFC1591 provided the founding policy principles for ccTLD Delegation and Redelegation, and that some useful guidance and enhancement of the understanding of RFC1591 could be derived from the guidelines included in the 2005 GAC Principles. But it must be clearly understood that clause 1.3 of the GAC Principles does confine the applicability to those instances where there is a 3 way agreement between the Government, the ccTLD and ICANN
>
> 5. One aspect that seriously needs to be considered in this is the lack of clarity in many instances over who is (or is not) the valid Government of a country. A useful example might be Antarctica, where at least 13 different Governments claim some form of sovereignty. Which of these Governments is the proper authority for the operation of the .aq ccTLD ? Section 4.2 of RFC 1591 contains the powerful assertion that "The IANA is not in the business of deciding what is and what is not a country". Recognising that many wars have been fought over the "lines in the sand" that provide jurisdictional demarcation points is an important high level principle.
>
> 6. The ICANN Board has recognised the Framework of Interpretation, and is implementing its recommendations as part of its IANA responsibilities. The FoI develops some colour and depth on some of the vagueness of RFC1591, while at the same time, does not seek to create any new policy. The FOI has referred back to the ccNSO that there is need for policy development in some specific areas of ccTLD administration, most particularly the "Retirement" of a ccTLD and an Appeals Mechanism where there is dissent on a delegation / redelegation decision - as RFC1591 is largely silent on these topics.
>
> I hope this clarifies the thinking, and apologise for the long-winded post, but it is important for the CWG group to have a clear understanding of the issues, and status of these items.
>
> Cheers
>
> Keith Davidson
>
>
>
>> On 30-Aug-16 9:04 AM, Burr, Becky wrote:
>> If the concern is parallel construction or balance, I believe that
>> ccTLDs would be comfortable with referring to RFC 1591, as interpreted by the
>> FOI, and as applicable in accordance with its ³Status² statement. Is
>> there some argument that Section 1.3 does not, in fact, clearly
>> articulate the applicability of the 2005 Principles?
>>
>>
>>
>>
>> J. Beckwith Burr
>> Neustar, Inc. / Deputy
>> General Counsel & Chief Privacy Officer
>> 1775 Pennsylvania Avenue NW, Washington D.C. 20006
>> Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz
>> <http://www.neustar.biz>
>>
>>
>>
>>
>> On 8/29/16, 12:38 AM, "Jorge.Cancio at bakom.admin.ch"
>> <Jorge.Cancio at bakom.admin.ch> wrote:
>>
>>> I feel that every element quoted in the naming agreement has very
>>> particular characteristics (the RFC has its own "status" description
>>> for instance), and we are not here to selectively quote such
>>> descriptions, which would lead us into debates that have different fora.
>>>
>>> Hence I would suggest that we do not engage in such an exercise and
>>> just refer to the different elements, be it request for comments, GAC
>>> principles, etc. in general and "as applicable".
>>>
>>>
>>> best
>>>
>>> Jorge
>>>
>>> Von meinem iPhone gesendet
>>>
>>> Am 28.08.2016 um 23:33 schrieb Burr, Becky
>>> <Becky.Burr at neustar.biz<mailto:Becky.Burr at neustar.biz>>:
>>>
>>> RFC 1591 is generally applicable policy that applies (at a minimum)
>>> to all ccTLDs delegated since its promulgation in 1994. On the other
>>> hand, the GAC Principles (2005) are not, as the GAC text clearly sets
>>> out, principles that IANA can apply absent the agreement of the
>>> relevant government and the ccTLD manager. Rather, as the text of
>>> the GAC Principles (2005) explicitly provide:
>>>
>>> 1.3. These principles are intended as a guide to the relationships
>>> between Governments, their ccTLD and ICANN. They are not intended to
>>> be binding and need both Governments and Registries voluntarily to
>>> agree to apply them within their legal framework. If either the
>>> Government or the Registry decide not to adopt the principles, this
>>> cannot be held against the Registry, and the Registry still has a valid existence.
>>>
>>> Accordingly, I do not understand why it is inappropriate to refer to
>>> the text of the GAC Principles (2005) to ensure absolute fidelity to
>>> those principles.
>>>
>>> J. Beckwith Burr
>>> Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer
>>> 1775 Pennsylvania Avenue NW, Washington D.C. 20006
>>> Office: +1.202.533.2932 Mobile: +1.202.352.6367 /
>>> neustar.biz<http://www.neustar.biz>
>>>
>>> From: Kavouss Arasteh
>>> <kavouss.arasteh at gmail.com<mailto:kavouss.arasteh at gmail.com>>
>>> Date: Sunday, August 28, 2016 at 10:46 AM
>>> To: Yuko Green <yuko.green at icann.org<mailto:yuko.green at icann.org>>
>>> Cc: "cwg-stewardship at icann.org<mailto:cwg-stewardship at icann.org>"
>>> <cwg-stewardship at icann.org<mailto:cwg-stewardship at icann.org>>
>>> Subject: Re: [CWG-Stewardship] FW: Naming Function Agreement Review
>>> document
>>>
>>> Dear Elise,, Dear Beckie
>>> I did make the same comments in different occasions that addition of
>>> such qualifier is unacceptable But someone whom I do not want to
>>> name, referred me in an INAPPROPRIATE CONTEXT to the practice of some
>>> courts in one country to which I totally disagrred but the co-chairs
>>> concerned did not listen to me.
>>> Now I am happy that you raised this issue to which I fully agree and
>>> request its removal Regards Kavouss
>>>
>>>
>>> 2016-08-26 18:56 GMT+02:00 Yuko Green
>>> <yuko.green at icann.org<mailto:yuko.green at icann.org>>:
>>> Dear Elise,
>>>
>>> Thank you for your comment. I am forwarding this to the correct CWG
>>> mail list.
>>>
>>> Regards,
>>> Yuko
>>>
>>> From: Lindeberg, Elise
>>> [mailto:elise.lindeberg at Nkom.no<mailto:elise.lindeberg at Nkom.no>]
>>> Sent: Friday, August 26, 2016 6:29 AM
>>> To:
>>> cwg-stewardship-bounces at icann.org<mailto:cwg-stewardship-bounces at ican
>>> n.org
>>>> ; Yuko Green <yuko.green at icann.org<mailto:yuko.green at icann.org>>
>>> Subject: Naming Function Agreement Review document
>>>
>>>
>>> Dear Yuko
>>>
>>> Regarding the comments made by Paul Kane on section 4,7 - n/a in the
>>> Naming Function Agreement Review document.
>>>
>>> - Section 4.7 and subsequent is formulated as a general reference to
>>> relevant and equivalent policies that must be considered by the
>>> contractor. Special reference to section 1.3 , - and the ³where
>>> applicable² in connection with the GAC principles in section 4.7 and
>>> subsequent is unbalanced in this context - the contractor will have
>>> to consider and substantiate the relevance of all mentioned/listed
>>> policies in its decisions and actions. So, in short form - I don¹t
>>> agree with the adding of ³²were applicable² or special reference to
>>> any subsection of the referenced documents such as section 1.3 of the GAC principles.
>>>
>>>
>>> 4.7
>>>
>>> 2. The reference to the GAC Principles should read: ³Where applicable
>>> in accordance with Section 1.3 thereof, the 2005 Governmental
>>> Advisory Committee Principles and Guidelines for the Delgation and
>>> Administration of Country Code Top Level Domains (³GAC 2005 ccTLD Principles²).
>>>
>>> We¹d like to understand more about the need for specific reference to
>>> Section 1.3. We are interested in accommodating this request, but
>>> need a bit more information.
>>>
>>> ICANN would like more information regarding the need for specific
>>> reference to Section 1.3.
>>>
>>> n/a
>>>
>>> Any subsequent reference to the GAC Principles should read, ³where
>>> applicable in accordance with Section 1.3 thereof, the GAC 2005 ccTLD
>>> Principles.²
>>>
>>> See above.
>>>
>>> ICANN would like more information regarding the need for specific
>>> reference to Section 1.3.
>>>
>>>
>>>
>>> Elise Lindeberg
>>> Senior Legal Adviser
>>> Norwegian GAC representative
>>> Norwegian Communications Authority
>>> Dir. +47 22 824607<tel:%2B47%2022%20824607> Mob. +47
>>> 90190947<tel:%2B47%2090190947> ekl at nkom.no<mailto:ekl at nkom.no>
>>>
>>>
>>>
>>> _______________________________________________
>>> CWG-Stewardship mailing list
>>> CWG-Stewardship at icann.org<mailto:CWG-Stewardship at icann.org>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mai
>>> lman_
>>> listinfo_cwg-2Dstewardship&d=DQIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFO
>>> ifzm6
>>> X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=8vZRXNclUd3WadryHcFyWk5m-0k-qzLBtS
>>> 6NaDh wgrQ&s=EERZc4YI6S0SPfLhVuwGVFSg0ZlCSDjZ_1rvcm-dQak&e=
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_ma
>>> ilman
>>> _listinfo_cwg-2Dstewardship&d=DQMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJF
>>> Oifzm
>>> 6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=BGrSIgRFMeTRdXfe1DnItybCuVH36kHis
>>> s8EaN WMy3c&s=TW65U4Hl9kja9BVIMuuVHL0gy2m0WMjTyVE9BkkYnxI&e=>
>>>
>>>
>>> _______________________________________________
>>> CWG-Stewardship mailing list
>>> CWG-Stewardship at icann.org<mailto:CWG-Stewardship at icann.org>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mai
>>> lman_
>>> listinfo_cwg-2Dstewardship&d=DQIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFO
>>> ifzm6
>>> X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=8vZRXNclUd3WadryHcFyWk5m-0k-qzLBtS
>>> 6NaDh wgrQ&s=EERZc4YI6S0SPfLhVuwGVFSg0ZlCSDjZ_1rvcm-dQak&e=
>>
>>
>>
>> _______________________________________________
>> 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.
> https://www.avast.com/antivirus
>
> _______________________________________________
> 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
More information about the CWG-Stewardship
mailing list