<html>
<head>
</head>
<body>
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 committee
(whatever the proper name is) and saw the presentations. Vixie and someone
from XO communications discussed the instability issues around Sitefinder.<br>
<br>
It was indesputable that sitefinder had a significant effect on many internet
users. Some spam filters and security filters were effected (estimates of
how much differed from various experts and VRSN's presentations). Some applications
that rely on dependable error messages were confused because sometimes they
interpreted a misspelling as an error and sometimes they did not. There
was a definite cost imposed on a wide variety of end users as a class. This
was quantifiable and real.<br>
<br>
Many ISPs and others began to respond. Some even responded by pre-empting
VRSN's sitefinder with their own version. Vixie and many other technologists
saw this kind of response as increasing instability, because a user's experience
will now vary based on what ISP he or she is 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
had been delegated and had a corresponding IP number got where they wanted
to go. It was also clear that VRSN itself was responsive to complaints from
third parties regarding impacts on other systems and worked to minimize problems
(while still maintaining the service).<br>
<br>
So we come back to the exciting question, what constitutes instability of
a kind that triggers an ICANN response? I am genuinely uncertain what the
answer should be. Unlike previous fights over new TLDs or privacy, where
it was clear that "stability" was simply a code word for priveleging some
political and economic interests over others, that was unclear here. There
_were_ real world effects. There _were_ costs imposed on third parties that
were powerless todefend themselves, but 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>
<blockquote type="cite" cite="mid:Pine.LNX.4.44.0311080757140.3812-100000@hjlee.ohmymokdong.or.kr">
<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></pre>
</blockquote>
<pre wrap=""><!----><br>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></pre>
</blockquote>
<pre wrap=""><!----><br>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></pre>
</blockquote>
<pre wrap=""><!----><br>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>
<pre wrap=""><!----><br></pre>
</blockquote>
<br>
</body>
</html>