<html>
<head>
</head>
<body>
Chun, you and I may be asking the same question, but with somewhat different
emphasis.<br>
<br>
Harold<br>
<br>
Chun Eung Hwi wrote:<br>
<blockquote type="cite" cite="mid:Pine.LNX.4.44.0311111628500.24184-100000@hjlee.ohmymokdong.or.kr">
<pre wrap="">Dear Harold Feld and Milton Mueller,<br><br><br>Harold, you are right. There were real effects.<br>And it came from the violation of backward compatibility.<br>DNS is one of low layer services in networking. So, if it violates some <br>assumptions, all other upper-level applications which were developed on <br>those assumptions would be affected. That's why John Klensin is <br>emphasizing this backward compatibility in terms of network stability. <br><br>Then, my concern is a little bit different from Harold. For me, the<br>question is not "what is stability" but "To what extent, stability should<br>be taken into account?" Even if it is not a good case, suppose Microsoft<br>operating systems. DOS and different Windows versions are not so fitted<br>with this backward compatibility in terms of hardware as well as software.<br>Although I don't want to defend Microsoft, in this case, instability has<br>become a general stream. And in a sense, in all technological
development,<br>backward compatibility could be sometimes taken off. Of course, when this<br>leap would occur, many users, vendors, service providers will be affected<br>or victimized. Then, to what extent, those technological change or leap<br>could be allowed? That is my question. I think even IDN case and<br>alternative root server issue ultimately have this quesiton.<br><br>One extreme position is John Klensin's. Maybe, he will say that <br>particularly in the world of network, more conservative approach should be <br>applied because network will affect many diverse cases. Responding to this <br>technologist elites' fixed idea, Milton Mueller said as follows;<br><br>"If these guys really know what registry operations do and do not hurt<br>Internet stability, let them put it into the terms of a contract. If a<br>registry does something that breaks stability, it violates that<br>contract, and subjects itself to liability." <br><br>Basically, this thinking sounds reasonable
, but if the criteria to be <br>applied for stability is to be not so clear like my question - to what <br>extent - in that case, I think it is not easy to coin some clear words in <br>contract. Then, what to do?<br><br><br>regards,<br><br>Chun<br><br><br>On Mon, 10 Nov 2003, Harold Feld wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">Chun:<br><br>This gets us squarely to the topic of "what is stability."<br><br>I was at the Washington meeting of the ICANN security and stability<br>committee (whatever the proper name is) and saw the presentations.<br> Vixie and someone from XO communications discussed the instability<br>issues around Sitefinder.<br><br>It was indesputable that sitefinder had a significant effect on many<br>internet users. Some spam filters and security filters were effected<br>(estimates of how much differed from various experts and VRSN's<br>presentations). Some applications that rely on dependable error<br>messages were confused because sometimes they interpreted a misspelling<br>as an error and sometimes they did not. There was a definite cost<br>imposed on a wide variety of end users as a class. This was<br>quantifiable and real.<br><br>Many ISPs and others began to respond. Some even responded by<br>pre-empting VRSN's sitefinder with their own version. Vixie an
d many<br>other technologists saw this kind of response as increasing instability,<br>because a user's experience will now vary based on what ISP he or she is<br>using even though they are typing in the same DNS information.<br><br>But it was also equally clear that anyone who entered a domain name that<br>had been delegated and had a corresponding IP number got where they<br>wanted to go. It was also clear that VRSN itself was responsive to<br>complaints from third parties regarding impacts on other systems and<br>worked to minimize problems (while still maintaining the service).<br><br>So we come back to the exciting question, what constitutes instability<br>of a kind that triggers an ICANN response? I am genuinely uncertain<br>what the answer should be. Unlike previous fights over new TLDs or<br>privacy, where it was clear that "stability" was simply a code word for<br>priveleging some political and economic interests over others, that was<br>unclear here. There _were_
real world effects. There _were_ costs<br>imposed on third parties that were powerless todefend themselves, but<br>the DNS did not crash and was in no danger of crashing as far as I can tell.<br><br>Harold<br><br>Chun Eung Hwi wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">Dear Harold Feld,<br><br><br>On Thu, 6 Nov 2003, Harold Feld wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">1) Registries, registrars, and users are best positioned to know what<br>services best serve their needs. Furthermore, there is great concern<br>that pre-approval may be used by competitive rivals to delay roll out of<br>new services -- to the disadvantage of users. Nor is it the role of<br>ICANN to preserve a particular status quo, but to focus on technical<br>stability.<br><br></pre>
</blockquote>
<pre wrap="">One problem is that given the importance of technical stability,<br>pre-approval could be preferred. In Carthage meeting, John Klensin noted<br>the importance backward stability by taking the example of IDN standard<br>when he presented in Sitefinder workshop. They will argue that such kind<br>of technical consideration should be done before the introduction of<br>new service for the purpose of stability.<br><br><br></pre>
<blockquote type="cite">
<pre wrap="">2) In particular, registries serving smaller, well identified<br>communities, such as .org, .museum, or others, should be encouraged to<br>consult within their communities before rolling out new services and<br>ICANN should respect the choices of these communities. This is<br>particularly true where innovations will address clearly stated user<br>needs, such as privacy concerns. Generic registries should also be<br>encouraged to establish informal consultation processes to ensure<br>technical stability. Use of these processes should be relevant in<br>assessing whether any after-the-fact remedy or emergency relief is<br>warranted.<br><br></pre>
</blockquote>
<pre wrap="">The example of privacy concerns must be very appropriate. And if such<br>criteria are to be taken, even gTLDs should be encouraged to consult with<br>user community.<br><br><br></pre>
<blockquote type="cite">
<pre wrap="">2a) At the same time, registries as businesses may have genuine business<br>reasons for wanting to maintain confidentiality of information. ICANN<br>should establish means by which such confidentiality can be protected,<br>while providing adequate opportunity for potentially effected parties to<br>comment and invoke remedies.<br><br></pre>
</blockquote>
<pre wrap="">Striking a balance could be taken into account as a compromise at the last<br>stage. But as a user constituency, the prior consultation with user<br>community should be a must.<br><br><br></pre>
<blockquote type="cite">
<pre wrap="">3) To the extent .com and .net pose a special case due to their existing<br>market share, any policy process must clearly delineate the boundaries<br>of such special consideration, why it is necessary, and what conditions<br>must be met by the .com and .net registries to alleviate the need for<br>such special treatment.<br><br></pre>
</blockquote>
</blockquote>
<pre wrap=""><br></pre>
</blockquote>
<pre wrap=""><!----><br></pre>
</blockquote>
<br>
</body>
</html>