Sitefinder, instability, new services

[Chun Eung Hwi]

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.
> >>
> >
>
>

--
------------------------------------------------------------
Chun Eung Hwi
General Secretary, PeaceNet | phone:     (+82)  2-2166-2205
Seoul Yangchun P.O.Box 81   |   pcs:     (+82) 019-259-2667
Seoul, 158-600, Korea       | eMail:   chun at peacenet.or.kr
------------------------------------------------------------