Sitefinder, instability, new services

[Harold Feld]

Chun, you and I may be asking the same question, but with somewhat
different emphasis.

Harold

Chun Eung Hwi wrote:

>Dear Harold Feld and Milton Mueller,
>
>
>Harold, you are right. There were real effects.
>And it came from the violation of backward compatibility.
>DNS is one of low layer services in networking. So, if it violates some
>assumptions, all other upper-level applications which were developed on
>those assumptions would be affected. That's why John Klensin is
>emphasizing this backward compatibility in terms of network stability.
>
>Then, my concern is a little bit different from Harold.  For me, the
>question is not "what is stability" but "To what extent, stability should
>be taken into account?" Even if it is not a good case, suppose Microsoft
>operating systems. DOS and different Windows versions are not so fitted
>with this backward compatibility in terms of hardware as well as software.
>Although I don't want to defend Microsoft, in this case, instability has
>become a general stream. And in a sense, in all technological development,
>backward compatibility could be sometimes taken off. Of course, when this
>leap would occur, many users, vendors, service providers will be affected
>or victimized. Then, to what extent, those technological change or leap
>could be allowed? That is my question. I think even IDN case and
>alternative root server issue ultimately have this quesiton.
>
>One extreme position is John Klensin's. Maybe, he will say that
>particularly in the world of network, more conservative approach should be
>applied because network will affect many diverse cases. Responding to this
>technologist elites' fixed idea, Milton Mueller said as follows;
>
>"If these guys really know what registry operations do and do not hurt
>Internet stability, let them put it into the terms of a contract. If a
>registry does something that breaks stability, it violates that
>contract, and subjects itself to liability."
>
>Basically, this thinking sounds reasonable, but if the criteria to be
>applied for stability is to be not so clear like my question - to what
>extent - in that case, I think it is not easy to coin some clear words in
>contract. Then, what to do?
>
>
>regards,
>
>Chun
>
>
>On Mon, 10 Nov 2003, Harold Feld wrote:
>
>>Chun:
>>
>>This gets us squarely to the topic of "what is stability."
>>
>>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.
>>
>>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.
>>
>>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.
>>
>>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).
>>
>>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.
>>
>>Harold
>>
>>Chun Eung Hwi wrote:
>>
>>>Dear Harold Feld,
>>>
>>>
>>>On Thu, 6 Nov 2003, Harold Feld wrote:
>>>
>>>>1) Registries, registrars, and users are best positioned to know what
>>>>services best serve their needs.  Furthermore, there is great concern
>>>>that pre-approval may be used by competitive rivals to delay roll out of
>>>>new services -- to the disadvantage of users.  Nor is it the role of
>>>>ICANN to preserve a particular status quo, but to focus on technical
>>>>stability.
>>>>
>>>One problem is that given the importance of technical stability,
>>>pre-approval could be preferred. In Carthage meeting, John Klensin noted
>>>the importance backward stability by taking the example of IDN standard
>>>when he presented in Sitefinder workshop. They will argue that such kind
>>>of technical consideration should be done before the introduction of
>>>new service for the purpose of stability.
>>>
>>>
>>>>2) In particular, registries serving smaller, well identified
>>>>communities, such as .org, .museum, or others, should be encouraged to
>>>>consult within their communities before rolling out new services and
>>>>ICANN should respect the choices of these communities.  This is
>>>>particularly true where innovations will address clearly stated user
>>>>needs, such as privacy concerns.  Generic registries should also be
>>>>encouraged to establish informal consultation processes to ensure
>>>>technical stability.  Use of these processes should be relevant in
>>>>assessing whether any after-the-fact remedy or emergency relief is
>>>>warranted.
>>>>
>>>The example of privacy concerns must be very appropriate. And if such
>>>criteria are to be taken, even gTLDs should be encouraged to consult with
>>>user community.
>>>
>>>
>>>>2a) At the same time, registries as businesses may have genuine business
>>>>reasons for wanting to maintain confidentiality of information.  ICANN
>>>>should establish means by which such confidentiality can be protected,
>>>>while providing adequate opportunity for potentially effected parties to
>>>>comment and invoke remedies.
>>>>
>>>Striking a balance could be taken into account as a compromise at the last
>>>stage. But as a user constituency, the prior consultation with user
>>>community should be a must.
>>>
>>>
>>>>3) To the extent .com and .net pose a special case due to their existing
>>>>market share, any policy process must clearly delineate the boundaries
>>>>of such special consideration, why it is necessary, and what conditions
>>>>must be met by the .com and .net registries to alleviate the need for
>>>>such special treatment.
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncuc.org/pipermail/ncuc-discuss/attachments/20031111/84dc0689/attachment.html>