<i>Comments on comments<br>Cheers. Louis<br></i>- - -<br><br><div class="gmail_quote">On Mon, Oct 29, 2012 at 12:48 PM, Carlos A. Afonso <span dir="ltr"><<a href="mailto:ca@cafonso.ca" target="_blank">ca@cafonso.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Parm, a few quick comments below.<br>
<br>
fraternal regards<br>
<br>
--c.a.<div><br>
<br>
On 10/29/2012 06:27 AM, parminder wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Hi All<br>
<br>
IT for Change had prepared our initial response to the current ITRs<br>
draft, and shared it with some civil society groups. Although the<br>
following is written as an email based input to the proposed ITR<br>
discussions at the BestBits civil society meeting, a version of it was<br>
also shared with the Indian government. Thought may be useful to post it<br>
here as well. parminder<br>
<br>
(begins)<br>
<br>
We see four sets of issues that are most important, and they are as<br>
follows:<br>
<br></div>
/1. State control over Internet routing system/<div>
<br>
This is perhaps the single most controversial issue in the ITR debate,
even more than the ITU-ICANN issue discussed above. It is rightly feared
that ITRs will be used by authoritarian countries like China and Iran to
develop strict state control over the routing of Internet traffic which
today is globally ordered to a large extent. Earlier inputs of these
countries into the ITR draft were rather more explicit in this regard.<br>
Even though rendered relatively bare-bone in the current draft, there is<br>
significant text still there that can be used for a tightly controlled<br>
Internet routing system, which if taken to its logical end can lead to
nation-wise balkanisation of the Internet.<br>
<br>
In the current draft, it is the text pertaining to section 30 which<br>
deals with this issue. Options range from 'states right to know which
routes are used', to 'states determining which routes are used', to<br>
'imposing any routing regulation in this regard'. My proposal is to go
with one of the listed options which is to suppress section 30<br>
altogether; so, no language on this issue at all.<br>
</div></blockquote>
<br>
Entirely agree. However, this is already done by certain countries independently of ITU's or any other international agreement, and will continue to happen.<br></blockquote><div><br><i>AFAIK this is an old practice. E.g. some mid-east countries don't want their phone calls routed through Israel. That sounds quite legitimate for security reasons. However it may be more complex to implement in IP nets than in POTS.</i><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
/2. ITU and CIRs management/<div><br>
<br>
One of the most important issues is whether ITU is seeking to, and vide<br>
the ITRs be enabled to, take up the functions being performed by the<br>
distributed CIR management system as it exists at present. In the<br>
current draft, section 31 A is of crucial import in this regard of ITU's<br>
feared encroachment of the remit of the ICANN plus system . The options<br>
in the current draft regarding this section range from 'naming,<br>
numbering, addressing and identification resources will not be mis-used'<br>
and 'assigned resources would only be used for the agreed purposes' to<br>
'all ITU recommendations will apply to naming, numbering, addressing and<br>
identification resources' (existing or also future ??) to 'nation<br>
states, if they elect to, can control these resources within their<br>
territories for the sake of international communication'.<br>
<br>
If ITU recommendations are made vide the new ITRs to apply to names and<br>
numbering systems, this may tend towards a creeping encroachment on<br>
ICANN's remit. One option in the current draft lists a set of specific<br>
ITU recommendations that will apply (these need to be studied<br>
individually which I havent). Other options are more open ended, which<br>
means future ITU recommendations may also apply, which, may mean that<br>
ITU can formally enter into doing and/or supervising ICANN's work. This<br>
becomes more problematic when seen along with draft options that make<br>
ITRs obligatory and not just a set of general principles. We should<br>
speak up against all such efforts to take over, or even substantially<br>
affect, the current distributed system of CIRs management.<br>
</div></blockquote>
<br>
I think there is overall consensus that the current names and numbers management system, despite its enormous mishaps (e.g, the recent problems in launching new gTLDs) and a "pluralist" governance which is biased towards the domain name business is currently operationally sound and should not be replaced. If we want a single example of ITU's lousy meddling into the domain name realm, just review the ENUM fiasco. Instead, we have to continue to press ICANN and its contractor (the USG) for true pluralist internationalization -- a major challenge clearly recognized by the new CEO, Fadi Chéadé.<br>
</blockquote><div><br><i>Google, Facebook and Twitter also have names and numbers for identifying their resources. Logically the only essential telecom resources are IP addresses and phone numbers (E.164, E.212, E.214, etc.). DNS and all nicknaming schemes are applications that should be optional for users.<br>
<br>As we know DNS was captured and diverted into a required cash cow system for the benefit of some private interests. So be it. But it would be really goofy to make it a model for the future. Other naming schemes will be necessary, e.g. for the so called "internet of things", for which the DNS is wholly inadequate.<br>
<br>Separating clearly infrastructure identifiers (IP addresses and other existing numbers) from application identifiers allows customized applications to develop at their own pace, independent from the infrastructure. Decoupling layers is a fundamental design concept in network architecture.</i><br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
/3. Definitional issues in the ITRs; telecom or Internet/<div><div><br>
<br>
Resolving this issue might take a good amount of out time. The issue is<br>
really tricky. Putting Internet under telecom, and thus under ITRs and<br>
ITU has its problems and a completely new kind of global regulatory<br>
system may then be built over it, which would hurt the way Internet has<br>
developed and needs to develop. However, it is also difficult to just<br>
argue that, when we are in times we are in, Internet traffic will be<br>
excluded from telecom definition, because that would beg the question -<br>
what then remains of telecommunicaiton in the era of increased IP based<br>
convergence. Is then ITU to close down as traditional telephony<br>
disappears. Perhaps more importantly, correspondingly, does this new<br>
definitional approach also mean that national level telecom regulatory<br>
systems like FCC and TRAI wind up sooner or later.<br></div></div></blockquote></blockquote><div><br><i>There is no internet definition in a technical world. What makes sense in ITRs are the services offered to users, and the constraints placed on Operating Agencies. These two facets should result from negotiation (or diktat) between stakeholders (governments, telecom, business users, civil society</i>,<i> maybe others in some countries). Regulation, if any, tends to be messy when it straddles technical layers boundaries because it then depends on specific network implementations.<br>
</i></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<i><br>
</i>We dont think we can afford to be co-opted into the efforts seeking<br>
complete deregulation of the entire communications systems that, for<br>
instance, are at present being made in the US, which employ
definitional logics of a highly dubious kind (like classifying Internet
not as a telecommunication but as an information service and thus not<br>
subject to common carriage or net neutrality provisions, and similarly<br>
rescuing VoIP services from universal service obligations.) At the same<br>
time, it is necessary to resist providing constitutional basis to the<br>
ITU which can be used to for control of content and application layers.<br>
This is the dilemma. What would the implications of putting Internet<br>
under telecommunications in the definitional and other sections? What<br>
does adding 'processing' signals to just sending, transporting and<br>
receiving signals does to what happens in the future vis a vis ITU's<br>
role? (These are all existing optional language in the current draft.)<br></div></div></blockquote></blockquote><div><br><i>As said above, the term "internet" has no technical meaning. Which services do they want to regulate ? Datagram transport ? UDP or TCP or FTP ? Email ? DNS ?</i> <i>routing ?</i><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<br>
This is something we really may have to spend a lot of time on. Our<br>
tentative suggestion is that we find a way whereby the transport /<br>
infrastructural layer is included in the definition of telecommunication<br>
(which also is closest to reality) and thus in ITR's remit. At the same<br>
time content and application layers are explicitly excluded.<br>
Contributing the right language in this respect may be one of the most<br>
important things that we can do. But as I said, this requires a lot of<br>
thinking and discussion among us.<br>
<br>
In trying any such definitional separations, the issue of 'security'<br>
would become a sticking point. In fact, 'security' may be an issue we<br>
may have to separately treat in our submission, becuase there is also a<br>
lot of tricky language in the current draft around this issue.<br></div></div></blockquote></blockquote><div><br><i>Yeah. What security ? Passwords ? Encryption ? Authentication ? Anonymity ? DDOS ? Mass surveillance system ? etc.</i><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
</div></div></blockquote>
<br>
The Internet is *composed* of layers, not *divided into* layers. This is crucial. If the telcos take over transport and routing, its consequences propagate to the upper layers, negatively affecting content providers, local Internet service providers, and above all the final users -- it will certainly be another kind of Internet.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
/4. Net neutrality or an open Internet<br>
<br>
/We should certainly speak against the ETNO proposal of a 'sender pays'<div><br>
arrangement. However, we should seek to go beyond it. Everywhere it is<br>
recognised that net neutrality is a regulatory issue. Net neutrality<br>
cannot survive with regulatory intervention, or at least some kind of<br>
normative soft pressure from regulatory quarters. So if there is an<br>
issue called 'global net neutrality' (CoE's experts report) then there<br>
is perhaps some role for a global regulatory system - if not of<br>
enforceable rules, at least for providing normative frameworks and<br>
general principles. And net neutrality concerns the transport layer, net<br>
neutrality concerns can be accommodated even while we do the above<br>
mentioned 'definitional separations' about what part of the Internet is<br>
telecom and which not.<br>
<br>
While even US telecoms are opposed to the ETNO proposal (for reasons<br>
one can appreciate) what they themselves propose in the US is the sender<br>
pays principle. Is it possible to use the ITR text in some way to<br>
promote a normative framework for net neutrality or an open Internet -<br>
or even more specific things like open peering and the such.<br>
<br>
I read in the CDT's document about problems with use of QoS term which<br>
can become the normative indication for violation of net neutrality and<br>
it should be opposed.<br>
</div></blockquote>
<br>
In Brazil the Ministry of Communications works in partnership with the telcos to remove the net neutrality concept from the Civil Framework for the Internet currently submitted to Congress. This is seen as part of the "freedom package" telcos are trying to push along the lines of "sender party pays" and the freedom to meddle with (and arbitrarily charge for) packet traffic.<br>
</blockquote><div><br><i>Is there a definition of neutrality that can be measured ? </i><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
/5. Some sundry issues<br>
<br>
/Apart the issue of 'security' mentioned above, which may require<div><br>
separate treatment, I can see two other important issues. One, whether<br>
ITRs should stay as general principles or they should become mandatory.<br>
These is alternative language in the current draft on these option. I<br>
think we should seek that ITRs stay as general principles. Second, if<br>
the principal parties that are subject to ITRs should remain<br>
'administrations' or be changed to 'member states and operating<br>
agencies'. I think the telecom environment has become complex and<br>
diverse enough to require the more flexible term 'operating agencies' to<br>
be included.<br>
<br>
(ends)<br>
<br>
<br>
</div></blockquote>
<br>
frt rgds<span><font color="#888888"><br>
<br>
--c.a.</font></span><br>
</blockquote></div>