[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ICANN-EU] Re: questions for candidates



On Mon, Aug 14, 2000 at 08:32:34AM +0200, Marc Schneiders <marc@venster.nl> wrote:
> > Could you explain how this would be possible? If the family is not using
> > the domain for e-mail, what's the point in holding it for them?
> 
> It seems I misunderstood you.

Being a technician, I do have the problem of giving too terse expelanations
all the time, and, hey, I should have clarified this nicer ;->

> to compare traffic, while you were only asking for *any* traffic for a
> domain holder to retain rights in a domain.

It's at least a *model* to think about. In practise, a margin would
have to be used, which in turn would be a nice research project (think,
think...)

> > Why? DNS service is relatively low-volume, and accounting is done at
> > relatively few centralised machines.
> 
> expensive. It may be difficult though. I'm not sure it can be done at

Very difficult.

> "relatively few centralised machines". Unless you are talking about
> checking whether the nameservers for a domain do actually work (as they
> should!).

No. As a starter, just counting the number of requests for a specific
domain on the root nameservers (i.e. every server that serves
icann-controlled domains). I guess one could come up with a nice analysis
of domain usage <=> dns request count/pattern, and maybe this would allow
enough of an error margin to be useful. Just as FCFS is a useful strategy,
*often*.

> why not persue this matter a little further? Can you explain how you would
> do this "accounting"?

I'd love to ;-> Ok, let's try:

What I am after is to augment the FCFS strategy in a similar way many
existing registries do it (current systems in use are: has to have working
nameservers or a working mx, has to have a working a* record etc..
non-usage leads to cancelation of the domain). The decision would be
binary: "domain in use / not in use".

The first problem is finding a measure for domain usage: traffic would be an
obvious measure. web hits would be another (obviously a very bad one ;). If
you can think of others, please tell me!

Now, as you said, measuring traffic is out of the question (at least for
the near future, and most probably forever), so how could one approximate
traffic? The obvious one is counting the number of requests for a domain
at the nameservers.

I am not aware of any statistics about this, but I think it would be
useful to do some research into that matter. Chances are good that our
notion of "domain is used" and actual request numbers compare well. (It
might be different).

Important however is, that the above model is *not* something I would
advocate to do. I mentioned it *just* because I am after alternatives
to the FCFS strategy which is so bad, and the current UDRP which is
also obviously "unfair" in many cases. So what I want is to think about
alternatives. And yes, the current way of resolving conflicts is highly
sub-optimal, and I don't expect too many people to think otherwise ;)

Another way to get around conflicts would be domain sharing. Now, this is
obviously quite fair, but protocol-dependent. http for example is quite
easily "shareable", smtp less so and ftp about not at all (there is also
the qesution of additional workload). Pure DNS as we know it, of course,
will not help, however, enhancing DNS should also be thought about,
as the problem of domains will IMHO become much worse and (political
statement:) I don't think additional TLD's (which *are* to come) will
solve it in any way.

So, in short, I am in favour of assessing the situation and trying to
THINK BIG about problems in the future, since the current (technical)
model is not very useful in a trademarked world.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |