[Chapter-delegates] [IANAxfer] [Internet Policy] An initial proposalregarding IANA development
Veni Markovski
veni at veni.com
Wed Apr 2 07:35:19 PDT 2014
All documents are published on the link I've sent earlier - it's below
in the message:
http://www.icann.org/en/about/agreements/cctlds
more specifically, the .nl is here:
http://www.icann.org/en/about/agreements/cctlds/nl/nl-icann-af-28jun07-en.pdf
(PDF)
v.
On 04/02/14 09:55, Carlos Gutierrez wrote:
> Thank you Veni. Can you please direct me to the link for the
> Accountability Framework the Dutch ccTLD signed?
>
> best regards
> Carlos Raul
>
> ISOC Costa Rica
>
>
>
> El 31/03/2014, a las 16:42, Veni Markovski <veni at veni.com
> <mailto:veni at veni.com>> escribió:
>
>> Good thing is - the agreements are public, and everyone can see them,
>> however they differ - e.g. the Russian ccTLD has exchanged letters
>> with ICANN, while the Netherlands has signed an Accountability
>> Framework.
>> It is up to the ccTLD to decide what's acceptable for them.
>>
>> Best,
>> Veni
>>
>> On 03/31/14 18:08, Burkov Dmitry wrote:
>>> imho - I don't think that it is acceptable to sign standardized
>>> ageements for ccTLDs
>>>
>>> What is ICANN - and what is real community?
>>>
>>> Dmitry
>>> On 31 Mar 2014, at 18:51, Veni Markovski <veni at veni.com
>>> <mailto:veni at veni.com>> wrote:
>>>
>>>> Vint,
>>>> Indeed, some of the ccTLDs do that - they seek for some agreement
>>>> with ICANN. This is all public information, and the agreements can
>>>> be found here: http://www.icann.org/en/about/agreements/cctlds
>>>>
>>>> One may notice that the form of the agreements have changed through
>>>> the years.
>>>>
>>>>
>>>>
>>>> On 03/31/14 05:42, Vint Cerf wrote:
>>>>> ICANN mistakenly tried to insist on agreements with ccTLD
>>>>> operators and that provoked a lot of tension, so Steve's position
>>>>> is consistent with experience. Personally, I think the ccTLD
>>>>> operators would be wise to seek such an instrument to reinforce
>>>>> their roles in the operation of the Internet (and it would also
>>>>> help with cryptographic control of changes to the root zone).
>>>>>
>>>>> vint
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 31, 2014 at 4:22 AM, Steve Crocker <steve at shinkuro.com
>>>>> <mailto:steve at shinkuro.com>> wrote:
>>>>>
>>>>> Patrik, Seun, et al,
>>>>>
>>>>> Here’s a small detail worth thinking about. Although some
>>>>> ccTLDs have agreements with ICANN, many do not. Further, many
>>>>> ccTLDs are not members of the ccNSO, the Supporting
>>>>> Organization that represents the ccTLDs within ICANN. None of
>>>>> this matters when it comes to providing each ccTLD with
>>>>> updates to its portion of the root zone. ICANN serves *every*
>>>>> ccTLD, even those that operate in locations the U.S.
>>>>> Government imposes trade restrictions.
>>>>>
>>>>> This is the way it’s been since the inception of ICANN. I
>>>>> don’t see any reason this needs to change. I would not
>>>>> envision ICANN *requiring* any sort of agreement with each of
>>>>> the ccTLDs. (We have sometimes sought such an agreement and
>>>>> may do so in the future, but it will not be a requirement.)
>>>>>
>>>>> Re the arrangements with Verisign, I would expect the
>>>>> adjustments to be only the minimum that’s required. I would
>>>>> expect their operational role and ICANN’s operational re
>>>>> updates and publishing of the root zone and the creation and
>>>>> use of DNSSEC keys to remain the same. It’s the *stewardship*
>>>>> not the actual operation that’s the subject of discussion.
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mar 31, 2014, at 4:10 AM, Patrik Fältström
>>>>> <patrik at frobbit.se <mailto:patrik at frobbit.se>> wrote:
>>>>>
>>>>>> On 31 mar 2014, at 03:57, Seun Ojedeji
>>>>>> <seun.ojedeji at gmail.com <mailto:seun.ojedeji at gmail.com>> wrote:
>>>>>>
>>>>>>> On Sun, Mar 30, 2014 at 10:22 PM, Patrik Fältström
>>>>>>> <patrik at frobbit.se <mailto:patrik at frobbit.se>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 30 mar 2014, at 13:49, Patrick Ryan
>>>>>>> <patrickryan at google.com <mailto:patrickryan at google.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I think personally one could think of a model where we
>>>>>>> have the various responsibilities layered:
>>>>>>>
>>>>>>> A. Primary layer:
>>>>>>>
>>>>>>> A.1. ICANN (as the party running the IANA function)
>>>>>>> signs an AOC with each body that asks for IANA services.
>>>>>>> A.2. ICANN to be able to provide the service required
>>>>>>> signs whatever AOC/MOU/Contract needed with Verisign and
>>>>>>> whoever else that have to be involved, so that ICANN can
>>>>>>> deliver whatever it promises under A.1.
>>>>>>>
>>>>>>>
>>>>>>> Unless i am forgetting/missing something, I think this part
>>>>>>> is already inplace, and there may be no need to have to
>>>>>>> repeat the signing process(re-call the scope of those who
>>>>>>> require the IANA service is quite broad). The only aspect
>>>>>>> which perhaps needs to be updated is the relationship
>>>>>>> between ICANN and Verisign (since verisign contract is with
>>>>>>> the USG). So ICANN needs to sign a contract with Verisign
>>>>>>> (just as he already have signed contract with other registries)
>>>>>>
>>>>>> There is today a cooperative agreement between NTIA and
>>>>>> Verisign that contain things I do believe are related to the
>>>>>> root zone management. Those details in that agreement should,
>>>>>> I think, be replaced by a contract between ICANN and
>>>>>> Verisign. This is not these operational actions that Verisign
>>>>>> do are to be moved elsewhere (to IANA). But if the basis for
>>>>>> the discussion is to not change operations of the root zone
>>>>>> management, then I would like to see ICANN take over the
>>>>>> pieces of the Cooperative Agreement related to the root zone
>>>>>> management.
>>>>>>
>>>>>>>
>>>>>>> B. Secondary layer:
>>>>>>>
>>>>>>> B.1. ICANN signs whatever paperwork with the parties
>>>>>>> that for example uses the parameters that are allocated
>>>>>>> according to the policies set up under category A.
>>>>>>>
>>>>>>> I am wondering how this differ from Item A2.1 that you
>>>>>>> mentioned above?
>>>>>>
>>>>>> B1 has to do with for example the registries for each TLD be
>>>>>> able to get an agreement with ICANN. In the same way as each
>>>>>> organisation getting any other parameter from ICANN (i.e. the
>>>>>> RIRs, each entity that have something in the IANA registry).
>>>>>> This for the protocol parameters have to be discussed
>>>>>> somewhat more whether it is for example for most of them IAB
>>>>>> that is the other end of the agreement, ISOC or whether it is
>>>>>> really each individual. For PEN it could be the organisation.
>>>>>> For character sets...
>>>>>>
>>>>>>> C. Tertiary layer:
>>>>>>>
>>>>>>> That way, at least via A.1 and B.1 we get a mesh of
>>>>>>> accountability agreements that should ensure that things
>>>>>>> works.
>>>>>>>
>>>>>>>
>>>>>>> Speaking about accountability, i think the bylaw should
>>>>>>> drive the accountability process. The role of the board
>>>>>>> needs to be reviewed. Now i know they always say board
>>>>>>> members represent the interest of the organisation. Yes i
>>>>>>> agree, however i believe the interest of the organisation
>>>>>>> should be in the bylaw and board should respect such. Now
>>>>>>> the content of the bylaw should respect the PDP of ICANN. It
>>>>>>> is well know that the PDP of ICANN has a bottom up approach
>>>>>>> hence the community interest is represented.
>>>>>>>
>>>>>>> So for me, i think more work needs to be done in reviewing
>>>>>>> the exiting bylaw and ensuring it holds the board members
>>>>>>> accountable and then the board members holds the
>>>>>>> organisation (in this case the CEO) accountable in an open
>>>>>>> and transparent manner.
>>>>>>
>>>>>> But to whom are they accountable? I was more thinking of to
>>>>>> whom the accountability was. But of course you talk about the
>>>>>> internal implementation of the accountability and that is
>>>>>> also important discussion.
>>>>>>
>>>>>> Patrik
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> To manage your ISOC subscriptions or unsubscribe,
>>>>>> please log into the ISOC Member Portal:
>>>>>> https://portal.isoc.org/
>>>>>> Then choose Interests & Subscriptions from the My Account menu.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> As an Internet Society Chapter Officer you are automatically
>>>>> subscribed
>>>>> to this list, which is regularly synchronized with the
>>>>> Internet Society
>>>>> Chapter Portal (AMS): https://portal.isoc.org
>>>>> <https://portal.isoc.org/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> As an Internet Society Chapter Officer you are automatically subscribed
>>>>> to this list, which is regularly synchronized with the Internet Society
>>>>> Chapter Portal (AMS):https://portal.isoc.org
>>>>
>>>> --
>>>>
>>>> Best,
>>>> Veni Markovski
>>>> http://www.veni.com
>>>> https://www.facebook.com/venimarkovski
>>>> https://twitter.com/veni
>>>>
>>>> The opinions expressed above are those of the
>>>> author, not of any organizations, associated
>>>> with or related to him in any given way.
>>>> _______________________________________________
>>>> IANAxfer mailing list
>>>> IANAxfer at elists.isoc.org <mailto:IANAxfer at elists.isoc.org>
>>>> https://elists.isoc.org/mailman/listinfo/ianaxfer
>>>
>>
>> --
>>
>> Best,
>> Veni Markovski
>> http://www.veni.com
>> https://www.facebook.com/venimarkovski
>> https://twitter.com/veni
>>
>> The opinions expressed above are those of the
>> author, not of any organizations, associated
>> with or related to him in any given way.
>> _______________________________________________
>> As an Internet Society Chapter Officer you are automatically subscribed
>> to this list, which is regularly synchronized with the Internet Society
>> Chapter Portal (AMS): https://portal.isoc.org
>
--
Best,
Veni Markovski
http://www.veni.com
https://www.facebook.com/venimarkovski
https://twitter.com/veni
The opinions expressed above are those of the
author, not of any organizations, associated
with or related to him in any given way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://elists.isoc.org/mailman/private/chapter-delegates/attachments/20140402/270e445d/attachment.htm>
More information about the Chapter-delegates
mailing list