[discuss] Possible approaches to solving "problem no. 1"
Steve Crocker
steve at shinkuro.com
Sun Feb 16 20:19:15 UTC 2014
Nathalie,
You asked for elaboration regarding updates to the root zone.
The root zone consists of the following
1. a very short header and the DNSSEC key information
2. the DNS information for each root server operator and each top level domain.
Here's the information in the root zone for the L root server. Each of the other 12 root servers has similar entries.
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:3::42
Here's the information in the root zone for Switzerland's top level domain, ch. Each of the other to level domains looks similar. (For readability, I've omitted the DNSSEC related portions of the entry.)
ch. 172800 IN NS d.nic.ch.
ch. 172800 IN NS f.nic.ch.
ch. 172800 IN NS b.nic.ch.
ch. 172800 IN NS h.nic.ch.
ch. 172800 IN NS a.nic.ch.
ch. 172800 IN NS e.nic.ch.
ch. 172800 IN NS c.nic.ch.
a.nic.ch. 172800 IN A 130.59.1.80
b.nic.ch. 172800 IN A 130.59.211.10
c.nic.ch. 172800 IN A 147.28.0.39
d.nic.ch. 172800 IN A 200.160.0.5
e.nic.ch. 172800 IN A 194.0.17.1
f.nic.ch. 172800 IN A 194.146.106.10
h.nic.ch. 172800 IN A 194.42.48.120
a.nic.ch. 172800 IN AAAA 2001:620::4
b.nic.ch. 172800 IN AAAA 2001:620::5
c.nic.ch. 172800 IN AAAA 2001:418:1::39
d.nic.ch. 172800 IN AAAA 2001:12ff:0:a20::5
e.nic.ch. 172800 IN AAAA 2001:678:3::1
f.nic.ch. 172800 IN AAAA 2001:67c:1010:2::53
This information is fairly stable. Information about the root servers changes very rarely. Information related to a top level domain changes roughly once per year. I'm using "once per year" as a rough average, not a precise figure, to give you a feeling for the frequency of change.
Whenever an operator wants to change the information in its portion of the root zone, it communicates with the IANA group at ICANN to request the change. The IANA group makes sure the change is coming from an authorized representative of the operator and then initiates the change.
In my prior message I mentioned the contractual relationships with ICANN are different for each of the three groups, root server operators, ccTLD operators and gTLD operators. The gTLD operators operate under contract with ICANN. And by "ICANN" I do not mean IANA. The contract with ICANN is with the Global Domains Division.
In contrast, there are no formal contracts between ccTLD operators and ICANN nor between root server operators and ICANN. Those are covered under less formal arrangements that predate ICANN.
All of this has worked well, but there's room for bolstering the relationships with a bit more formality and additional processes for dealing with whatever technical and policy issues that may arise in the future.
Steve
On Feb 15, 2014, at 3:22 PM, Nathalie Coupet <nathaliecoupet at yahoo.com> wrote:
> Hello All,
>
> Could you please elaborate on what the common technical requirements are for the root zone "occupants" are, and how their contractual relationships to ICANN differ?
>
> Thank you!
>
> Sent from my iPhone
>
> On Feb 14, 2014, at 12:22 PM, Steve Crocker <steve at shinkuro.com> wrote:
>
>> Patrik,
>>
>> Good thoughts. Let me add a small bit of additional color.
>>
>> Add and remove are obviously sensitive operations and require careful approval by authorities outside of IANA's clerical role. In my view, there are three different groups of root zone "occupants." Two are the ccTLD and gTLD operators. While they have the same technical requirements, their policy and contractual relationships with ICANN are qualitatively different, so I put them in different groups. The third set of "occupants" are the root zone operators because each of them has NS and glue records in the root zone.
>>
>> The update function might seem less sensitive, but it's part of the attack surface. A seemingly innocuous series of updates can lead to loss of control. The IANA folks check carefully to make sure updates are authorized. Nonetheless, an update is, as you've said, qualitatively different from add and remove.
>>
>> More to say at an appropriate time, but this is enough for now.
>>
>> Steve
>>
>>
>> On Feb 14, 2014, at 12:08 PM, Patrik Fältström <paf at frobbit.se> wrote:
>>
>>> I must say I do not think we really can get into more details on
>>> "problem no. 1" unless we define what we mean by "IANA root zone
>>> function" because I see many different things IANA does. To make it
>>> simple, they "add", "remove" and "update" information related to TLDs,
>>> and maybe each one of the operations are such that they do need
>>> different oversight?
>>>
>>> For example, I think related to the "update" operation, the registry for
>>> whatever the TLD the update is about is the authoritative source, and I
>>> have no idea what, why or who should intervene in such an operation.
>>>
>>> Regarding "add" and "remove" we have maybe other constraints, where
>>> specifically "remove" is a very very destructive operation.
>>>
>>> Patrik
>>>
>>> On 2014-02-13 15:20, Ian Peter wrote:
>>>> George,
>>>>
>>>> I must admit I was hoping for more than an interesting discussion here.
>>>> I think we have been talking about this for well over a decade.
>>>>
>>>> I think we would achieve broad consensus here for Option 3 – which is
>>>> internalisation of the previous IANA processes within ICANN. That itself
>>>> would be quite a milestone and a first achievement for 1net.
>>>>
>>>> I also think that that direction would be supported by the EU – it is
>>>> multistakeholder – and by many other governments. I also think that USA
>>>> which often indicates its support for multistakeholder would, under the
>>>> weight of such a multistakholder consensus, eventually feel it necessary
>>>> to support this direction.
>>>>
>>>> If we could get to Brazil with a clear forward direction, I believe
>>>> there is a strong chance that Brazil could actually have a useful
>>>> outcome – acceptance of a direction for solution of the IANA oversight
>>>> issue. That would be a good achievement.
>>>>
>>>> So if we wanted to try and achieve that, I wouldn’t try to arrive at any
>>>> firm solution as regards GAC involvement at this stage. Indeed, I would
>>>> try to throw a statement of direction and principles back at ICANN to
>>>> figure out the details. Yes, as you say, the devil is in the details, so
>>>> I would leave the devil locked up there for a while until we get a clear
>>>> consensus and agreement on a direction. And also discussions on the role
>>>> of GAC would best involve GAC so are not so useful here.
>>>>
>>>> Starting from the recent EU declaration, we would need to include
>>>> security, stability and a timeframe. And I think your (5) below is a
>>>> good start for a brief.
>>>>
>>>> “5. Acceptable solutions for assignment of the IANA root zone function
>>>> should meet several criteria: (1) protection of the root zone from
>>>> political or other improper interference; (2) integrity, stability,
>>>> continuity, security and robustness of the administration of the root
>>>> zone; (3) widespread [international] trust by Internet users in the
>>>> administration of this function; (4) support of a single unified root
>>>> zone; and (5) agreement regarding an accountability mechanism for this
>>>> function that is broadly accepted as being in the global public interest.”
>>>>
>>>> I would like to see us aim towards a request, perhaps for adoption in
>>>> Brazil, for ICANN to produce an internalised solution meeting the
>>>> criteria in (5) (and any others we might like to add) with a timeframe .
>>>> I would suggest IGF this September would be good for a report to be
>>>> developed further. I could see implementation in that case within 12 months.
>>>>
>>>> Then we are left with one related question – internationalisation of
>>>> ICANN. But again the options here have been discussed for some time. But
>>>> perhaps our consensus request could also ask ICANN (with a timeframe) to
>>>> present a solution to this.
>>>>
>>>> Ian Peter
>>>>
>>>> PS I would also suggest that ICANN utilise an outside independent
>>>> consultancy based outside of the USA to conduct this study and consult
>>>> all stakeholders and prepare the directions paper, in the interests of
>>>> expediency and efficiency.
>>>>
>>>>
>>>> *From:* George Sadowsky <mailto:george.sadowsky at gmail.com>
>>>> *Sent:* Friday, February 14, 2014 3:30 AM
>>>> *To:* Milton L Mueller <mailto:mueller at syr.edu> ; mailto:discuss at 1net.org
>>>> *Subject:* Re: [discuss] Possible approaches to solving "problem no. 1"
>>>>
>>>> Milton,
>>>>
>>>> Thanks for bringing up your original writing. I looked for it in my own
>>>> archives, couldn’t find it, and so depended upon memory. That’s not
>>>> always a good option for an aging brain. I apologize for misstating
>>>> your position.
>>>>
>>>> I don’t think I’m avoiding coming to grips with any differences. I’m
>>>> glad that you were able to sharpen the options as you’ve done below. My
>>>> comments were an attempt to describe and delineate the space of possible
>>>> solutions, and you have helped to do that.
>>>>
>>>> I am not trying to discredit the denationalization option. It’s clear
>>>> that the GAC will stay. However, under your #3 option, will the GAC have
>>>> any say whatsoever in any IANA (or son of IANA, or new-name) decisions
>>>> regarding the root zone file, and if so, under what terms? The devil is
>>>> in such details.
>>>>
>>>> Milton, you may have thought I was waffling because I was just
>>>> describing and delineating what I regarded as the space of
>>>> alternatives. I wasn’t waffling; I was trying to invoke discussion of
>>>> those alternatives. I can tell you that:
>>>>
>>>> A. I am personally in favor of option 3, and have been for some time.
>>>>
>>>> B. Given the current structure of ICANN, including the GAC, it will be
>>>> really important to get any revised denationalized (your words)
>>>> structure defined well with respect to the new interrelationships.
>>>>
>>>> Others, however, may disagree, and I did not want to push the
>>>> discussion, at that point in time, toward my own preferences.
>>>>
>>>> Oh the other hand, so far most of the comments seem to favor option #3,
>>>> so perhaps it’s worth concentrating some discussion on it. I am not a
>>>> lawyer, but it’s clear to me (assuming that IANA stays coupled to ICANN)
>>>> that ICANN’s legal status changes. Are there anti-trust or
>>>> competitiveness law implications? My guess is that there surely are,
>>>> and from multiple countries.
>>>>
>>>> What legal structure should such a born-again ICANN take. Here’s where
>>>> I was hoping that Jovan’s text below would be interesting to discuss; so
>>>> far, no one has picked that up. If #3 is the correct path to take, i.e.
>>>> if we know where we want to go. and we know where we are now, what are
>>>> the feasible paths that could get us there? I refer back to item 5 in
>>>> the problem statement. It is not going to go away:
>>>>
>>>>> 5. Acceptable solutions for assignment of the IANA root zone function
>>>>> should meet several criteria: (1) protection of the root zone from
>>>>> political or other improper interference; (2) integrity, stability,
>>>>> continuity, security and robustness of the administration of the root
>>>>> zone; (3) widespread [international] trust by Internet users in the
>>>>> administration of this function; (4) support of a single unified root
>>>>> zone; and (5) agreement regarding an accountability mechanism for this
>>>>> function that is broadly accepted as being in the global public interest.
>>>>
>>>> So, where do we go from here? Milton, since you are clearly also in
>>>> favor of this option, perhaps you would describe for us your proposed
>>>> structure of the post-transition organizations and relationships between
>>>> them, in sufficient detail to address the various conflicts and dangers
>>>> that might arise, and what paths we might choose to arrive there. That
>>>> could be a basis for interesting further discussion on this list.
>>>>
>>>> George
>>>>
>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> On Feb 12, 2014, at 4:47 PM, Milton L Mueller <mueller at syr.edu
>>>> <mailto:mueller at syr.edu>> wrote:
>>>>
>>>>>
>>>>>
>>>>> George. You did not quite get the 3 options right. They were:
>>>>>
>>>>> <!--[if !supportLists]-->1) <!--[endif]-->Unilateral control by 1
>>>>> govt (the status quo)
>>>>>
>>>>> <!--[if !supportLists]-->2) <!--[endif]-->Multilateral control
>>>>>
>>>>> <!--[if !supportLists]-->3) <!--[endif]-->De-nationalization of
>>>>> the IANA function; ie., removal of USG control and delegation of it to
>>>>> ICANN. Note well: this does NOT require exclusion of governments from
>>>>> all involvement in ICANN.
>>>>>
>>>>>
>>>>>
>>>>> What you propose as a solution, “one based upon multistkeholderism,”
>>>>> is actually an attempt to avoid coming to grips with difference
>>>>> between #2 and #3. By attempting to do this, you are seriously
>>>>> muddying the waters at a time that we need absolutely clarity.
>>>>>
>>>>>
>>>>>
>>>>> EITHER root zone changes are the responsibility of ICANN, in which
>>>>> case you are advocating #3 (because ICANN is not an intergovernmental
>>>>> organization) OR governments have some kind of special authority over
>>>>> root zone changes, in which case your solution devolves to #2. Please
>>>>> decide which one you are advocating. I will not let you waffle.
>>>>>
>>>>>
>>>>>
>>>>> What you’ve done in an attempt to discredit the de-nationalization
>>>>> option is to pretend that if we devolve control to ICANN, that
>>>>> governments are excluded entirely from the process. This is obviously
>>>>> false. Governments currently play a major role in ICANN, via GAC
>>>>> advice. So one could easily cut the cord to the USG, vest the IANA
>>>>> function in ICANN fully, and governments would still be involved. Even
>>>>> if the GAC were dismantled, as some of us favor, it is still
>>>>> completely possible and indeed desirable for individuals who work for
>>>>> or are contracted by governments to participate in ICANN.
>>>>>
>>>>>
>>>>>
>>>>> Some of us are proposing to reform the role of governments in ICANN to
>>>>> make it consistent with a truly equal-status, multistakeholder
>>>>> governance process. I am really getting tired of hearing, as a
>>>>> response to these proposals, that “governments are a part of our world
>>>>> and we can’t ignore or exclude then.” That is either a dishonest or a
>>>>> completely clueless response. By eliminating special powers for
>>>>> governments and avoiding intergovernmental control, we are not
>>>>> proposing to completely exclude governments from the process. We are
>>>>> simply proposing to adhere more consistently to the MS model and give
>>>>> government agencies and employees the same status as everyone else.
>>>>>
>>>>>
>>>>>
>>>>> Milton Mueller
>>>>>
>>>>> Professor, Syracuse University School of Information Studies
>>>>>
>>>>> http://faculty.ischool.syr.edu/mueller/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> The third approach is in my view equally unrealistic. Governments are
>>>>>
>>>>>> a part of our world. They have useful and essential functions We
>>>>> depend upon the creation and evolution of legal structures along with
>>>>> the administrative and judicial mechanisms that institutes and
>>>>> implement them. We may be concerned with their inappropriate use of
>>>>> power, but we can’t deny that they have a place at the table. We are
>>>>> likely, however, to differ about what that place is and what
>>>>> limitations might be put upon them.
>>>>>
>>>>> The second approach, one based upon multistakeholderism, seems like
>>>>> the only viable and significantly acceptable one. While that choice
>>>>> may be comforting in terms of its inclusive orientation, the space of
>>>>> solutions that could be called multistakeholder is vast and
>>>>> multidimensional, with the only necessary condition for being in the
>>>>> set is that all relevant stakeholder groups, however defined, have
>>>>> some degree of inclusion into the process and that no one group has an
>>>>> absolute veto over the activities of the group. Distributions of
>>>>> power, representation, and decision making authority all vary,
>>>>> possibly enormously among stakeholder groups. The very choice of what
>>>>> groups are included and who they include contributes to the diversity
>>>>> among solutions. (For example, while ICANN correctly claims to be
>>>>> organized according to a multistakeholder model, in fact it is
>>>>> organized in accordance with a very specific and well-defined
>>>>> instantiation of the multistakeholder model.)
>>>>>
>>>>> So if we are going to talk about multi-stakeholder approaches to the
>>>>> problem, we will need to differentiate between a variety of them that
>>>>> might be suggested. Saying that an approach is a multi-stakeholder
>>>>> approach is not sufficient; it will need to be characterized in a more
>>>>> definite manner.
>>>>>
>>>>> Finally, any approach that will be successful must make the great
>>>>> majority of us comfortable with its ability to maintain security,
>>>>> stability, and independence of the Internet’s fundamental naming and
>>>>> addressing systems, and with its ability to withstand takeover by any
>>>>> special interests. Governments, including the US government, must be
>>>>> an integral part of that majority if any transition is to be feasible
>>>>> and ultimately successful. Solutions that do not meet this criterion,
>>>>> and are not demonstrably better than what we have now, should not and
>>>>> will not be adopted.
>>>>>
>>>>>
>>>>> *_Incremental approaches_*
>>>>>
>>>>> Assuming that there are continuity and stability virtues in minimizing
>>>>> the amount of change that is made, I ask myself: are there acceptable
>>>>> solutions to the problem that minimize the account of change needed?
>>>>> In which direction would they go? I personally don’t have a good
>>>>> answer for that. Perhaps others do.
>>>>>
>>>>>
>>>>> *_Diplomatic approaches, from Jovan Kurbalija_*
>>>>>
>>>>> In a recent provocative article, Jovan Kurbalija has outlined a
>>>>> number of scenarios that find their rationale in established
>>>>> diplomatic behavior. The article, at:
>>>>>
>>>>>
>>>>> http://www.diplomacy.edu/blog/international-inviolability-root-zone
>>>>>
>>>>> contains the following scenarios. I include them here because I think
>>>>> they represent serious approaches to the issue we’re discussing. They
>>>>> may or may not be practical.
>>>>>
>>>>>
>>>>> USE DIPLOMATIC LAW APPROACH TO SOLVE THE POLICY PROBLEM OF THE
>>>>> ROOT ZONE
>>>>>
>>>>> The predominantly symbolic relevance of the root zone issue has
>>>>> created the basis for an analogy with diplomatic law, which deals
>>>>> with another highly symbolic issue: representation of countries.
>>>>> It includes diplomatic precedence, the protection of diplomatic
>>>>> buildings, and the main functions of representation.[3] How can
>>>>> the regulation of symbolic aspects of diplomatic relations help in
>>>>> regulating the symbolic aspects of Internet politics? Here are two
>>>>> possibilities:
>>>>>
>>>>> The first possibilit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140216/222d11aa/attachment-0001.html>
More information about the discuss
mailing list