<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On Tuesday 07 August 2012 12:26 PM,
David Conrad wrote:<br>
</div>
<blockquote
cite="mid:3FD80E83-82D0-4BD2-AC22-D2793A4AEE9B@virtualized.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Parminder,
<div><br>
</div>
<div>I was going to respond point by point to your message, but
decided it is a waste of time: it would appear clear your mind
is made up and further attempts at explaining technical reality
is unlikely to be helpful.</div>
</blockquote>
<blockquote
cite="mid:3FD80E83-82D0-4BD2-AC22-D2793A4AEE9B@virtualized.org"
type="cite">
<div>snip<br>
</div>
</blockquote>
<br>
<blockquote
cite="mid:3FD80E83-82D0-4BD2-AC22-D2793A4AEE9B@virtualized.org"
type="cite">
<div>- I won't bother going into the technical details as to why
exactly the number 13 is what it is and is hard to change since
it is clear you will choose not to listen. I will simply note
that there would be tremendous commercial advantage to the
company that came up with how to solve this particular issue in
a backwards compatible manner and I know of number of VCs here
in Silicon Valley who would undoubtedly be willing to throw
large barrels of money at the company. I'll be happy to make
introductions.</div>
</blockquote>
<br>
This is getting into a extreme 'cant be done' or at least 'is
extremely difficult to do' position. However let me quote what you
said in your email of Aug 3 responding to Siva.<br>
<br>
<blockquote>
<pre wrap="">The answer to "why?" is quite simple: the original DNS specification limited the guaranteed supported size of a DNS message to 512 bytes and 13 IP(v4) addresses is all you can fit in a message of that size. While the DNS specifications have evolved to support larger messages, it turns out a surprisingly (at least to me) large percentage of the infrastructure refuses to allow those larger messages (the refusals being largely due to old software, broken implementations, or security policy that mistakenly assumes DNS messages must be less than or equal to 512 bytes in length). </pre>
</blockquote>
<br>
It does not at all sound as an unfixable problem to me. And these
above are your own words! Now whether we get down to trying and
solving it simply depends on how badly we feel the political
necessity, which I understand we feel differently about. I hear that
changes to DNS message specifications have been done to accommodate
the security requirements of DNSEC application, am I right? Just
different political priorities then!<br>
<br>
I am indeed listening to you, proven by fact of the above quote
coming back to my mind.... <br>
<br>
In any case, for me the issue is geopolitically just distribution of
root server management, and if new servers are difficult, we should
reallocate the current ones. Is there any unsurmountable technical
problem there? <br>
<br>
snip<br>
<br>
<blockquote
cite="mid:3FD80E83-82D0-4BD2-AC22-D2793A4AEE9B@virtualized.org"
type="cite">
<div><br>
</div>
<div>P.S. Having been involved in multilingual DNS since the
mid-90s as well as in deploying the first IDN TLDs, it actually
was and is "a bit difficult to rely upon" (and I personally
think the solution the IETF came up with is broken, but at least
a solution was chosen).</div>
</blockquote>
<br>
That is the point I am making; when we need to , we do come up with
a solution. Similarly we can find the technical solution with regard
to root server management issue. Because the original 'capture'
logic for a distributed root management system requires a different
system response now. <br>
<br>
regards, parminder <br>
<br>
<blockquote
cite="mid:3FD80E83-82D0-4BD2-AC22-D2793A4AEE9B@virtualized.org"
type="cite">
<div><br>
<div>
<div>On Aug 6, 2012, at 10:17 PM, parminder <<a
moz-do-not-send="true"
href="mailto:parminder@itforchange.net">parminder@itforchange.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> David,<br>
<br>
<div class="moz-cite-prefix">On Sunday 05 August 2012
10:40 PM, David Conrad wrote:<br>
</div>
<blockquote
cite="mid:2F7C0136-DA33-4C00-A2DA-E368182FC0B1@virtualized.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
Parminder,
<div><br>
<div>
<div>On Aug 5, 2012, at 5:40 AM, parminder <<a
moz-do-not-send="true"
href="mailto:parminder@itforchange.net">parminder@itforchange.net</a>>
wrote:</div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">Now, we know
that there are three kinds of root servers, the
authoritative root server (in which changes are
made to the root file vide the IANA process), 13
root servers and then the any number of mirrors
that can allegedly be created by making an
investment of 3k usd .<br>
</div>
</blockquote>
<div><br>
</div>
<div>No.</div>
<div><br>
</div>
<div>
<div>There is a "distribution master". </div>
</div>
</div>
</div>
</blockquote>
<br>
So, well, apologies for referring to the root zone file as
the highest level of root zone server; I should perhaps
simply have said 'the highest level of Internet's root
architecture'. However, your chastising may be biased.
Someone, quite unlike me, with deep technical training
like Daniel said is a recent email; <br>
<blockquote>
<p style="margin-bottom: 0cm">"As already mentioned,
there are hundreds of root server instances. Each of
these is an actual root server."</p>
</blockquote>
<p style="margin-bottom: 0cm">Isnt this statement as or
more untrue, in a discussion where we are mainly
speaking about actual 'control' over the root file. The
hundreds of root servers mentioned above are NOT 'actual
root servers'. An actual root server is a shorthand for
an actual root server operator, who exercises control
(at least potentially) over the root zone file that he
publishes. (I learnt this from my earlier discussions
with you on the IANA authority and the US.) The
'ill-informed' Indian minister seems rather better
informed than 'technical experts' here on this
particular issue. He seems to know better which is a
true or actual root server and which is not. Quote from
the same interview where he quite wrongly said that
Internet traffic flows through 13 root servers (he
should have said, internet traffic, in a way, gets
directed by 13 root servers).<br>
</p>
<title></title>
<meta name="GENERATOR" content="LibreOffice 3.5 (Linux)">
<style type="text/css">
<!--
@page { margin: 2cm }
P { margin-bottom: 0.21cm }
--></style><br>
"Currently, India's mirror servers reflect the data but
without mechanisms of control and intervention."<br>
<br>
Clearly what some 'technical experts' stress and what they
suppress (or forget to mention) depends on their
techno-political proclivities. Isnt it obvious! <br>
<br>
In response to my another email, you have asked me to
"provide examples of supposed 'statements of technical
facts' that are ''thoroughly wrapped in a certain
techno-political viewpoint". Apart from the above example,
I will try and find others in your email below :) <br>
<br>
<blockquote
cite="mid:2F7C0136-DA33-4C00-A2DA-E368182FC0B1@virtualized.org"
type="cite">
<div>
<div>
<div>
<div>(snip)</div>
<div><br>
</div>
</div>
<div>That's all. There are no special "13" machines
that are the "true root servers" from which other
lesser machines mirror the root zone.</div>
</div>
</div>
</blockquote>
Well, you did understand early in this discussion that the
argument is not about 'true root servers' but about 'true
root server operators', so why dont we stick to the real
point of contestation rather than create strawmen and
defend against them. From your email of a few days ago <br>
<br>
<blockquote>"The concern (as I understand it) is that the
administration of those root servers is in the hands of
12 organizations, of which 9 are US-based. " (David) <br>
<br>
</blockquote>
Yes, true. It is this what we are discussing here, not the
network latency problem. In that email, you understood the
concern right. It is about root server operators, and the
term '13 root servers' is loosely used to mean '13 root
server operators'. That is the real issue, and it was the
issue that bothered the Indian and the African ministers
the latter being wrongly, if not mischievously, retorted
to in terms to availability of root server mirrors - a
very different issue. Similarly, this current discussion
is continuously pulled towards the convenient description
of geographic extensions through mirrors of root servers,
away from the real issue of 'concentration' (against
distribution) of power to change root file or resist
changes to root file that is with the root server
operators and none at all with anycast mirror operators.<br>
<br>
It is very interesting that when I did that long
discussion with you, David, on the US's unilateral IANA
authority, your almost entire case was based on how the
root server operators are really independent (which is the
same thing as saying they have 'power') and this is the
insurance against any US mischief with the root zone file.
However, now when we are discussing the power of root
server operators, which is geo-politically very unevenly
distributed, the 'power' with the root server operators is
sought to be so minimized as to be completely evaporated.
The focus is repeatedly sought to shifted to how anyone
can set up a root server and that those who speak about 13
root servers (meaning, root server operators) being not
distributed well enough are merely stupid!<br>
<br>
How does what appears to be the 'same fact' take such very
different manifestations in two different political
arguments? This is what I mean by 'technical advice' being
warped by strong techno-political viewpoints. I am not
making any personal accusation. I am stating a
sociological 'fact'. <br>
<br>
<blockquote
cite="mid:2F7C0136-DA33-4C00-A2DA-E368182FC0B1@virtualized.org"
type="cite">
<div>
<div>(snip)<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">What I see
is that, while there are of course clearly very
significant differences between these three
layers or kinds of root servers, much of the
'technical input' on this list that I have come
across seem to focus on the non-difference and
greatly underplay the difference. </div>
</blockquote>
<div><br>
</div>
<div>As discussed above, the distinction you are
making doesn't exist.</div>
</div>
</div>
</blockquote>
<br>
Well!! See above for the distinction. A clear distinction
that you did understand and articulate in your earlier
email in terms of concentration of ability for
"administration of those root servers is in the hands of
12 organizations, of which 9 are US-based. " There is
obvious and very important distinction between the 'power'
of root zone operator and someone operating a mirror. This
distinction is the very basis of the whole discussion in
this thread. But you have easily and conveniently
dismissed, or minimised, distinctions between the root
file layer, root zone layer and anycast mirror layer, esp
between these two latter layers . This is done through a
unilateral decision to speak about one thing when the
other party is speaking about quite another, or at least
another aspect of the issue - which here is the issue of
'control' rather than availability of root file for
resolving queries. <br>
<br>
<blockquote
cite="mid:2F7C0136-DA33-4C00-A2DA-E368182FC0B1@virtualized.org"
type="cite">
<div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">This I think
is politically motivated, though disguised as
factual neutral/ technical information.</div>
</blockquote>
<div><br>
</div>
<div>Conspiracy theories are tricky things as it
makes it difficult to communicate.</div>
</div>
</div>
</blockquote>
<br>
:). I made it clear at the onset that I am trying to argue
that when a group has strong political inclinations - as
the so called technical community has - its technical
advice gets accordingly wrapped... Call it my conspiracy
theory, but at least I am upfront. But also (try to ) see
how the technical community sees deep conspiracies in
every single political utterance from the South. Worse its
conspiracy theory is further compounded by a 'stupidity
theory'. Double insult! <br>
<blockquote
cite="mid:2F7C0136-DA33-4C00-A2DA-E368182FC0B1@virtualized.org"
type="cite">
<div>
<div>
<div><br>
</div>
(snip)
<div><br>
</div>
You misread. The 13 IP(v4) address limitation due
to the default maximum DNS message size still
exists. While there are now ways around this
limitation (specifically, the EDNS0 extension to the
DNS specification), these ways are not universally
supported and as such, cannot be relied upon,
particularly for root service.</div>
</div>
</blockquote>
No, I dont think I misread. Just that the fact remains
that the number 13 can be expanded without much
difficulty, but you are not too interested to explore that
direction while I am (again, political proclivities
intervene). Wasnt introducing multilingual gtlds also
considered a bit 'difficult to rely upon' just a few years
back. Finally, political considerations helped get over
that unnecessary and exaggerated fear. It depended who
were taking the decisions, the US centric ICANN
establishment earlier, but the same establishment with
some WSIS related fears and cautions in the second
instance. <br>
<br>
<blockquote
cite="mid:2F7C0136-DA33-4C00-A2DA-E368182FC0B1@virtualized.org"
type="cite">
<div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">So if indeed
it is not, why not breach it and make people of
the world happy. </div>
</blockquote>
<div><br>
</div>
<div>Even if it were possible, I sincerely doubt
everyone having their own root server would make
the people of the world happy.</div>
</div>
</div>
</blockquote>
This is 'the' most important point - whether there is any
justification at all to increase the number or root
servers and/or to reallocate / redistribute them in a
manner that is politically more justifiable and thus
sustainable. I will take it up in a separate email. <br>
<br>
regards<br>
parminder <br>
<br>
<blockquote
cite="mid:2F7C0136-DA33-4C00-A2DA-E368182FC0B1@virtualized.org"
type="cite">
<div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">Even within
the limit of 13, why not allocate root servers
in a geo-graphically equitable manner, as
Sivasubramanian has suggested, especially when
it seems to make no difference at all to anyone.
Why not make all these ill-informed ministers
happy. </div>
</blockquote>
<div><br>
</div>
<div>As mentioned in a previous note, the operators
of the root servers are independent (modulo "A"
and "J" (through the Verisign contract with the
USG) and "E", "G", and "H" (operated by USG
Departments), albeit each of these operators deal
with their root servers differently). How root
server operators distribute their instances is
entirely their decision. To date, there has
apparently been insufficient justification for
those root server operators to decide to
distribute their machines in a "geo-graphically
equitable manner".</div>
<div><br>
</div>
<div>With that said, there are at least two root
server operators ("L" (ICANN) and "F" (ISC)) who
have publicly stated they are willing to give a
root server instance to anyone that asks. Perhaps
the ill-informed ministers could be informed of
this so they could be happy?</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">I read that
there is no central control over the 13 or at
least 9 of these root servers. Is it really
true? </div>
</blockquote>
<div><br>
</div>
Yes. The diversity of architecture and lack of
centralized control is seen as a feature as it
reduces the opportunities for "capture".</div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">Is the 13
root server architecture not something that is
aligned to what goes in and from the
authoritative root server. </div>
</blockquote>
<div><br>
</div>
Root server architecture is independent of how the
root zone is distributed.</div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">If it is,
why can these root servers not be reallocated in
the way tlds have been reallocated. Can they be
reallocated or cant they? </div>
</blockquote>
<div><br>
</div>
<div>In practical terms, the "reallocation of a root
server" boils down to transferring the root
server's IP address and telling the new owner the
zone transfer password.</div>
<div><br>
</div>
<div>Before the DNS became a political battleground,
root server "reallocation" occurred (extremely
infrequently) when (a) the person to whom Jon
Postel "gave" the root server changed employers or
(b) the assets of the organization running the
root server were acquired by another company.
Today, "reallocation" of a root server would
either require the existing root server operator
voluntarily giving the root server IP address to a
different organization or that IP address would
have to be "taken" by eminent domain or somesuch.</div>
<div><br>
</div>
</div>
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">I also read
that the it is not about 13 physical root
servers, but 13 root server operators, </div>
</blockquote>
<div><br>
</div>
<div>Well, 12 operators (since Verisign operates two
root servers).</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">so the
number 13 is about the root server ownership
points, and not physical location points. </div>
</blockquote>
<div><br>
</div>
In the sense that there are 13 IP(v4) addresses that
are "owned" by 12 organizations. Geography is
largely irrelevant.</div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">Therefore
what is needed is to reallocate the ownership
points in a geo-politically equitious manner. As
Siva suggests, probably one to an Indian
Institute of Technology. </div>
</blockquote>
<div><br>
</div>
<div>Somewhat as an aside, my understanding is that
efforts to provide infrastructure (not root server
infrastructure specifically albeit the same folks
do provide anycast instances for a root server
operator) in India were blocked by demands for
bribes greater than the value of hardware being
shipped into the country (see <a
moz-do-not-send="true"
href="http://permalink.gmane.org/gmane.org.operators.nanog/100786">http://permalink.gmane.org/gmane.org.operators.nanog/100786</a>).</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">Why this is
not done, or cant be done are the real questions
in the present debate. Any answers?<br>
</div>
</blockquote>
<div><br>
</div>
<div>Sure. You are assuming a top-down model that
does not exist. There is no single entity that
can dictate to the root server operators "you will
give your root server to IIT". You and others
that care about this are free to make the case to
(say) Verisign that it would be in their corporate
best interests for them to relocate administrative
control of one of their root servers to India, but
it would be up to Verisign (or perhaps more
accurately, its shareholders) to make that
decision.</div>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">Is the real
problem here that if root server allocation
issue is opened up, countries would like to go
country-wise on root servers (as the recent
China's proposal for 'Autonomous Internet')
which will skew the present non-nation wise
Internet topology (other than its US
centricity), which is an important feature of
the Internet.<br>
</div>
</blockquote>
</div>
<br>
</div>
<div>No. Placement of root servers has no impact on
Internet topology. Really. Distributing root server
instances can be helpful in reducing root query
latency and improving resiliency in the event of
network disruption. That's pretty much it. Opening up
the "root server allocation issue" is a red herring,
particularly given pretty much anyone can get a root
server instance if they care and are willing to abide
by the restrictions inherent in operating a root
server. </div>
<div><br>
</div>
<div>Merging a subsequent note:</div>
<div><br>
</div>
<div>
<div class="moz-cite-prefix">On Sunday 05 August 2012
06:10 PM, parminder wrote:</div>
</div>
<div>
<blockquote type="cite"><span style="background-color:
rgb(255, 255, 255); ">' administrative access will
not be available' to the anycast operator to his
own anycast server. </span></blockquote>
<div><br>
</div>
<div>Yes. However, if you ask anyone familiar with
computer systems, you will be told that if you have
physical access to a machine, you can gain control
of that machine. Obtaining such control would
violate the terms by which the machine was granted,
but that's irrelevant.</div>
<br>
<blockquote type="cite"><span style="background-color:
rgb(255, 255, 255); ">This is a pretty centralised
control, </span><span style="background-color:
rgb(255, 255, 255); ">not at all the picture one
got from all the technically well informed
insiders who seem to suggest on this list that
everything is open, uncontrolled and hunky-dory
and kind of anyone can set up and operate root
servers.</span></blockquote>
<div><br>
</div>
<div>I'm getting the impression that you read what you
prefer to read, not what is actually written. No
one (to my knowledge) has suggested "everything is
open, uncontrolled and hunky-dory". Root service is
considered critical infrastructure and is treated as
such, so anyone asserting it is "open and
uncontrolled" would be confused at best. Can you
provide a reference to anyone making this
suggestion?</div>
<div><br>
</div>
<div>As for "hunky-dory", I suppose some folks would
say the way the root servers are operated is
"hunky-dory". I am not among them.</div>
<div><br>
</div>
<blockquote type="cite"><span style="background-color:
rgb(255, 255, 255); ">Was the African minister
really so wrong, or even the Indian minister? </span></blockquote>
<br>
</div>
<div>Yes. Really. </div>
<div><br>
</div>
<div>Regards,</div>
<div>-drc</div>
<div><br>
</div>
</blockquote>
<br>
<br>
</div>
____________________________________________________________<br>
You received this message as a subscriber on the list:<br>
<a moz-do-not-send="true"
href="mailto:governance@lists.igcaucus.org">governance@lists.igcaucus.org</a><br>
To be removed from the list, visit:<br>
<a moz-do-not-send="true"
href="http://www.igcaucus.org/unsubscribing">http://www.igcaucus.org/unsubscribing</a><br>
<br>
For all other list information and functions, see:<br>
<a moz-do-not-send="true"
href="http://lists.igcaucus.org/info/governance">http://lists.igcaucus.org/info/governance</a><br>
To edit your profile and to find the IGC's charter, see:<br>
<a moz-do-not-send="true"
href="http://www.igcaucus.org/">http://www.igcaucus.org/</a><br>
<br>
Translate this email: <a moz-do-not-send="true"
href="http://translate.google.com/translate_t">http://translate.google.com/translate_t</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>