[discuss] Options for root zone

Sat Jan 18 01:15:05 UTC 2014

Mike,

a standing, sonorous +1.

Next issue please (an orphan one, now, pleeeease!!)

Alejandro Pisanty

On Fri, Jan 17, 2014 at 5:12 PM, Mike Roberts <mmr at darwin.ptvy.ca.us> wrote:

> This discussion could benefit from a somewhat broader  and more
> substantive perspective.
>
> (1) In the early ICANN days, before gTLD expansion became a reality,
> questions revolved around whether countries should or should not be in the
> root.  Jon Postel fervently did NOT want to be in a decision loop on this
> subject, and deferred to the UN postal code table for guidance.  ICANN's
> Board felt as Jon did; this was a subject on which the UN should/would have
> the final word.
>
> In the entire existence of the DNS, there has never been an occasion in
> which Postel or ICANN entertained the notion of unilaterally adding or
> dropping a country's name servers from the root.  The UN holds sway in this
> area, and always has.  If there are genuine issues, they lie outside of
> ICANN.
>
> (2) A related, but lesser, question arose when there were issues of the
> validity of a claim by an in-country entity that it fairly and equitably
> represented the interests of the country in question and should have its
> name servers entered in the root.  ICANN's response to this type of issue
> was to tell any warring parties to settle their differences, and oh by the
> way, get your governmental authorities to vouch for you.  An imperfect
> solution?  Yes, but certainly superior to an ICANN effort to pick a winner.
>  Again, if there are issues here, they lie outside of ICANN, and probably
> outside of Internet Governance as well.
>
> (3) The next issue arose over the fairness and procedural adequacy of
> ICANN's process for granting entry to the root for new gTLDs.  This is well
> documented in the files and apart from the usual sore loser problem, the
> results were viewed as fair by the community, although ICANN was roundly
> criticized for limiting the number of new entries so severely.  Continuing
> debate over this issue lead ultimately to the long and involved process
> that is placing thousands of new entries in the root now.  Half a dozen
> years and thousands of pages of on-the-record deliberations later, we have
> extensive guidance which is being followed by ICANN to the best of its
> ability, with a lot of back benchers adding commentary daily.  Would yet
> another round of "consultation" improve things?   Not very likely.
>
> (4) The day to day operations of the several hundred root servers are
> essentially lodged in the hands of the Internet technical community.  Over
> the years, no credible source has ever impugned the integrity or efficacy
> of any of the root operators or technical experts who have collaborated
> with them, as in the case of Anycast, etc.  Does it need oversight or
> governance?  I dearly hope not, for the sanity of everyone involved.
>
> (5)  The "approval" of entries to the root, which is covered by a
> Cooperative Agreement (contract) between the Department of Commerce and
> Verisign, is an historical artifact that serves no useful purpose today but
> was, and perhaps still is, a matter of potentially complex legal dispute
> between Verisign and the U.S. Government if anyone chooses to challenge it,
> which is extremely unlikely.   The USG, as a founder, signatory, and
> Security Council member of the UN, would hardly act unilaterally to not
> fulfill a UN decision on what is a country entitled to a place in the root.
>  It is hard to see this as an IG issue except to very small minds.
>
> (6)  As a forum for settling contentious issues arising in the evolution
> of the Internet, there have been calls since ICANN's inception for
> oversight and review.  The organization is drowning in second guessing.
>  Those who would propose a new layer of oversight should be obligated to
> identify the layer to be removed first.
>
> I hope this adds a little substance to what can otherwise become an overly
> abstract debate.
>
> - Mike
>
>
>
>
>
>
>
>
>
>
> On Jan 17, 2014, at 11:47 AM, Ian Peter <ian.peter at ianpeter.com> wrote:
>
> > Yes.
> >
> > I think (and also taking into account Milton's comments) there are two
> elements
> >
> > 1. a clear, accountable, consultative internal ICANN process for
> authorisation of changes
> > 2. a secure, invoilable system to implement those changes
> >
> > On (1) - Milton I share your concerns re GAC - but I think the reality
> might be that the path of least resistance towards changes from the current
> unilateral control situation here might be an agreed role for GAC as part
> of internal process of ICANN. Yes that needs to be negotiated carefully
> (and I believe without a veto right for GAC) but something in this
> direction might be acceptable to governments - and it is a hell of a lot
> easier than establishing some new international convention or super
> organisation or whatever. And one reason I like a simple internal procedure
> is that root zone changes are on the whole simple administrative procedures
> that do not warrant or need huge inter governmental agreements. For
> proponents of multistakeholderism - as long as we have a strong
> multistakeholder model for these authorisations within ICANN, there should
> be no controversy requiring special sessions of the United Nations or some
> unilateral oversight function or new decision making bodies or whatever.
> >
> > On (2) I like Andrew's suggestion, and hope suggestions like this can be
> looked at thoroughly. I am sure there are other suggestions that could be
> looked at to add security to this part of the process. I think looking
> carefully at how we could improve this situation is an essential element of
> necessary reforms.
> >
> > But again we are maybe jumping the gun and need to go back to clear
> requirements before figuring out the solutions...
> >
> > Ian Peter
> >
> >
> >
> >
> >
> > Ian Peter
> >
> > -----Original Message----- From: Andrew Sullivan
> > Sent: Saturday, January 18, 2014 1:52 AM
> > To: discuss at 1net.org
> > Subject: Re: [discuss] Options for root zone (was Re: Interesting
> article)
> >
> > On Thu, Jan 16, 2014 at 08:17:26PM -0500, Suzanne Woolf wrote:
> >>
> >> of oversight for the contents of the root zone is that the US
> >> government (or, to generalize, any government) *can't* act in the
> >> way described. This requirement has not been met to date.
> >
> > Something along those lines became clear to me in an off-list
> > discussion with someone else (someone whose technical judgement I
> > respect a great deal), and it made me realise that we may be facing a
> > case where people are trying to solve a problem with the technology in
> > place rather than by stating the problem more generally.
> >
> > The way Suzanne frames it above, this problem is not about multiple
> > roots.  It is about a root zone provisioning regime that allows all
> > and only the relevant players change control over what affects them.
> >
> > We currently think of "the root zone" as a file (because we say "zone
> > file"), but we could as easily conceive of some other provisioning
> > system.  In that case, the provisioning system could be developed and
> > tested in the open before all the relevant parties (roughly, all the
> > operators of any zone actually in the root, plus whoever might be
> > interested in root zone operations generally).  I'm imagining here a
> > kind of rough consensus procedure, but something else might have to be
> > devised; anyway, that's procedural politics and above my pay grade.
> >
> > Once the code for this system is up and working, the provisioning
> > system becomes a master database into which changes are submitted.
> > The relevant parties (I guess in most cases, the root zone maintainer
> > IANA functionary and the relevant zone operator) then each have to
> > signal their approval of a change (including deletion) for it to take
> > effect in the zone.   In order to cope with dangerous zones (I'm
> > thinking particularly not ccTLDs here) that are abusing their
> > position, we'd probably also need some sort of n of m provision under
> > which a zone could be pulled from the root over the objections of one
> > of the relevant parties.  N probably needs to be high :)
> >
> > Root nameserver operators would fetch the data as they ever did,
> > except that probably the "master DNS server" they'd talk to would just
> > be this provisioning system (which presumably we'd teach to speak DNS
> > zone transfer).  Most (if not all) of this technology is already
> > pretty well-developed in the existing competitive registration market
> > for many TLDs, so this wouldn't be a major undertaking.
> >
> > The point here is that this kind of approach removes the control by
> > the US, and it does it without any important effects on the basic DNS
> > technology.  It does _not_ do any of the other things that partisans
> > of "alternate roots" seem to want, but I've never been able to to be
> > clear enough about what those requirements would be in order to have
> > an idea of what you could do about it.
> >
> > Best regards,
> >
> > A
> >
> > --
> > Andrew Sullivan
> > ajs at anvilwalrusden.com
> >
> > _______________________________________________
> > discuss mailing list
> > discuss at 1net.org
> > http://1net.org/mailman/listinfo/discuss
> >
> > _______________________________________________
> > discuss mailing list
> > discuss at 1net.org
> > http://1net.org/mailman/listinfo/discuss
>
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net.org/mailman/listinfo/discuss
>

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - -
     Dr. Alejandro Pisanty
Facultad de Química UNAM
Av. Universidad 3000, 04510 Mexico DF Mexico
+52-1-5541444475 FROM ABROAD
+525541444475 DESDE MÉXICO SMS +525541444475
Blog: http://pisanty.blogspot.com
LinkedIn: http://www.linkedin.com/in/pisanty
Unete al grupo UNAM en LinkedIn,
http://www.linkedin.com/e/gis/22285/4A106C0C8614
Twitter: http://twitter.com/apisanty
---->> Unete a ISOC Mexico, http://www.isoc.org
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140117/554cea33/attachment-0001.html>