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

Re: initial thoughts




At 19:15 03/04/02 -0800, Paul Hoffman / IMC wrote:


At 1:48 AM +0000 4/3/03, Adam M. Costello wrote:
Couldn't you simply say that when more than one key matches, use the
longest match?  It would be trickier to implement, but that's exactly
how routing tables work.  It seems pretty easy to describe.  Whether it
would be worth the additional complexity, I don't know.

How do others feel about this?

I think first we need clarification from you about whether you intended, in your approach, that (variants in) bundles can overlap. There is no indication in your draft that they can't, but on the other hand, there is no indication that you were aware of the fact that they could.

If you intended them to overlap, then your and Adam's approach
are technically different, and we probably would have to discuss
these actual differences first. If you didn't intend them to
overlap, then you have to add the necessary restrictions to
your draft. I think I agree with Adam that his approach then
is easier to describe, because it can describe how to map
one label to one other label, which should make the description
a lot simpler. But of course I would like to first see an actual
wording from Adam. Your description of how to generate a bundle
could probably also be cleaned up (see my comments in a provious
mail), but may still be more complicated.


 > > Will it scale?
 >
 > Absolutely.

Suppose JPNIC decides that hiragana and katakana should block each
other.

Er, in order to say that something doesn't scale, you need to use real-world examples. JPNIC has already stated that they have no intention to do this.


It is easy to come up with extreme examples for *any* protocol, then say "if you do this a zillion times it doesn't scale". Please show the scaling properties for typical use and, if they show that the current proposal cannot be deployed over the long term, what changes would be needed.

Stephane already has shown a quite reasonable example, and applied it to an actual zone, with clear results.

And in general, for scalability, the burden of proof in on the
people who claim that things scale. Just saying that things
will scale because nobody has proved that they don't is not
a good idea.


I would still call that "registrant chooses", even though the registry
is offering a default choice, because the registry still needs to be
able to store lists of visible names for registrants who ask to deviate
from the default.  When I said "registry chooses", I meant that the
registrant has zero input, so that the registry could define the choice
algorithmically and omit any capability of storing lists.

Right, but you're missing the problem of time-scaling. Any automated process that has a dependent step that includes novice end-users deciding something that they have no expertise in will scale more poorly than one that doesn't have the step in the control steps.

If the end users have to make a choice, then timewise, this scales because they can do that in parallel. If somebody at the registry has to intervene, it definitely doesn't scale. Also, we should assume that the end users at least know the language they are registering in.

Regards, Martin.