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

James Seng james.seng at gmail.com
Mon Jan 20 08:40:17 UTC 2014

The perceived problem of US Government involvement in IANA root zone is
actually bigger than the realty.

Most people against the US involvement are more concerned about the
"what-if" scenario and less about the "what-has".

-James Seng

On Mon, Jan 20, 2014 at 12:41 PM, 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
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net.org/mailman/listinfo/discuss

-James Seng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140120/e95a8774/attachment.html>

More information about the discuss mailing list