[discuss] P1 version 2 - I will update from time to time - this one is important

Ben fuller ben at fuller.na
Mon Jan 20 16:43:28 UTC 2014


Jorge,

I count three instances, DNSSEC, IDN and the new gTLDs where the ICANN model and process have worked. I hope these are documented. Those who criticise it mush show that they can do substantially better. 

Ben

On Jan 20, 2014, at 6:23 PM, Jorge Amodio <jmamodio at gmail.com> wrote:

> 
> Let me add that in the course of DNSSEC implementation and the signing of the root zone that could also be perceived by many as another point of USG influence, the process for doing it the people that participated in it and the distribution of key fragments in case is necessary has been an open, transparent and international process.
> 
> Many of us watched real time the video streaming of the multiple ceremonies of key generation, signing and distribution of memory cards to the key keepers that were flown in from all around the world and committed to the storage, security and availability of their key portions at any time, and all of them are highly respected individuals from the Internet Community.
> 
> So also in this case the alleged USG influence is more myth than reality and is being use to feed an anti-US phobia that does not make any sense and has no arguments.
> 
> -Jorge
> 
>> On Jan 20, 2014, at 9:33 AM, Ben fuller <ben at fuller.na> wrote:
>> 
>> David,
>> 
>> A great response. You answered many of my points. That said, I urge ICANN to do a statistical analysis because they want to be able to say something to the effect of "we have made x changes to the root zone and have received y complaints that were resolved thusly ..." My guess is that the value for x will far exceed the value for y.  
>> 
>> I thought that the actual changes to the root zone were/are/will be very straightforward. From reading up on Internet Governance I sense a misperception of the root zone and what it can and cannot do. It is not "the one ring that binds them all." (Apologies to the Tolkien estate.) It is a text file that basically gives directions. Demystifying the root zone might be a useful exercise. This should include your list of the types of changes that can be made. 
>> 
>> You point to the NTIA contract and how "ICANN's IANA staff can only propose changes to NTIA.  NTIA verifies ICANN has followed documented policies before authorizing the changes. The changes, once authorized are then implemented by Verisign.  In both the ICANN steps and the Verisign steps, various syntactic and semantic checks are made prior to the change being moved to the next step (being sent to NTIA in ICANN's case, being signed and pushed to the master distribution server in Verisign's case)." This may actually be a place where changes could be made to satisfy those who are fearful of US government influence. You have outlined where checks and balances occur, and this would be the place to add or strengthen them should that ever be decided. 
>> 
>> But, as you mention with the possible exception of .HT, there are few, if any, instances where controversial/problematic changes to the root zone have been made. Jorge Amodio echoes your point in another post to this thread, "As far as I know from the IANA/ICANN side the answer is most probably NO. As far as I remember most of the problems were associated with different organization/institutions claiming the right to manage the ccTLD delegation." In other words, over the past 18 years we haven't had any reason why the ICANN/IANA - NTIA arrangement needs an overhaul. 
>> 
>> For me the burden of proof now shifts to those who are critical of this arrangement. There needs to be some good solid evidence to spend the funds and effort needed to create new structures. For those who are worried about US political influence, they again need to show how this has occurred. It might also be useful for them to come up with a structure that would NOT be susceptible to political influence from one source or another -- if such an organisation could ever exist. 
>> 
>> Ben
>> 
>> 
>>> On Jan 20, 2014, at 6:41 AM, David Conrad <drc at virtualized.org> wrote:
>>> 
>>> Ben,
>>> 
>>>> On Jan 19, 2014, at 10:52 AM, Dr. Ben Fuller <ben at fuller.na> wrote:
>>>> What are the kinds of changes that ICANN/IANA recommend?
>>> 
>>> In the context of what is authorized by the US government, root zone changes proposed by ICANN consist of additions, modifications, or deletions (very rare) of top-level domain delegations and associated "glue" records. ICANN also makes changes to the entries in the IANA registration ("Whois") database.
>>> 
>>>> Can we develop a typology?
>>> 
>>> Maybe -- I'm unclear as to what would be typed though.
>>> 
>>>> The aim being to divide changes into those that are mainly operational/technical and those that would be viewed as problematic.
>>> 
>>> At the IANA functions level, the only changes that would be problematic would be those that were perceived to have violated documented policy. There has been discussion in other venues of cases that occurred prior to the establishment of ICANN (.HT, I believe) and at one point in the distant past, ICANN refused to implement modifications to delegations inappropriately (something that was subsequently expressly disallowed in the IANA Functions contract).  Beyond those cases, I'm not aware of changes that would be viewed as problematic.
>>> 
>>>> I assume that operational/technical changes can go through in a straightforward manner.
>>> 
>>> Yes.
>>> 
>>>> We analyse the problematic changes and then focus on what kinds of structures/procedures would be needed to deal with them in a way that is acceptable the widest number of parties. ICANN has 16 years of data.
>>> 
>>> Within the context of the IANA functions contract, I believe part of the issue is that there aren't really any problematic changes anymore.  My impression is that the issue that has people concerned is the optics of the US government authorization role and the potential for mischief that role implies.
>>> 
>>>> Three points. One I have a sense that many, and I include myself, don't have a grasp of what takes place when root zone changes are made. What are the procedures?
>>> 
>>> http://www.iana.org/domains/root/help may help. If you have any questions, I'd be happy to answer them in public or in private (with the proviso that I left ICANN in 2010, so my information may be a bit dated).
>>> 
>>>> What are the checks and balances?
>>> 
>>> In the context of root zone changes, ICANN's IANA staff can only propose changes to NTIA.  NTIA verifies ICANN has followed documented policies before authorizing the changes. The changes, once authorized are then implemented by Verisign.  In both the ICANN steps and the Verisign steps, various syntactic and semantic checks are made prior to the change being moved to the next step (being sent to NTIA in ICANN's case, being signed and pushed to the master distribution server in Verisign's case).  
>>> 
>>> In the case of ICANN, I can't actually think of a unilateral action that can be made that is not checked by at least 2 other parties.
>>> In the case of NTIA, to my knowledge, there is no direct mechanism by which NTIA staff can modify or inject their own request.
>>> In the case of Verisign however, since Verisign edits, signs, and publishes the zone, they could in theory make any arbitrary modification to the root zone and put that zone on the master distribution server.  In such a scenario, the root server operators and resolver operators around the world may take exception to the modification (not to mention my suspicion that the US government might take a dim view of such an action).
>>> 
>>> In the context of Root registration database modifications, any changes proposed by ICANN must be authorized by NTIA.  NTIA has no way of directly injecting changes into the Root registration database. ICANN staff could in theory make any arbitrary modification to the root registration database, however the impact of such a modification would likely be confusion for anyone trying to look up the TLD administrators' contact information.  Similarly, I suspect the US government might not take such a modification very lightly.
>>> 
>>>> Two, I assume that there have been controversial/problematic changes to the root zone. Have there been?
>>> 
>>> Other than the possible case of .HT ('possible' because I don't know the details), none that I'm aware of that were the responsibility of ICANN.  Back in 2004, there was a glitch in Verisign's root zone generation software that caused a faulty zone to be generated, but we've been told that has long since been fixed.
>>> 
>>>> How were they dealt with?
>>> 
>>> Part of the formalization of how IANA functions are operated was due, I believe, in part to removing the possibility of badness occurring.
>>> 
>>>> There is the possibility that some are complaining just because it is the US that has the final approval. Still, it will be useful to get those who complain to put forward their concerns as clearly as possible so they can be addressed.
>>> 
>>> I would be interested in this as well.
>>> 
>>>> Three, the US House and Senate have both overwhelmingly voted resolutions that direct the US Government to maintain control over the root. Given the current climate in Washington, we cannot expect much of a change here, hence solutions also have to be acceptable inside the Beltway. Peter Dengate Thrush spoke of this a few days ago from a different angle.
>>> 
>>> This is not my area of expertise.
>>> 
>>> Regards,
>>> -drc
>> 
>> **********************************************
>> Dr. Ben Fuller
>> +264-61-224470  (O)    +264-88-63-68-05 (F)
>> ben at fuller.na             http://www.fuller.na
>> skype: drbenfuller
>> **********************************************
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> discuss mailing list
>> discuss at 1net.org
>> http://1net.org/mailman/listinfo/discuss

**********************************************
Dr. Ben Fuller
+264-61-224470  (O)    +264-88-63-68-05 (F)
ben at fuller.na             http://www.fuller.na
skype: drbenfuller
**********************************************












More information about the discuss mailing list