[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: initial thoughts
At 9:04 PM +0000 3/31/03, Adam M. Costello wrote:
Paul's draft assumes that the policies can focus on single characters,
and disregard sequences of characters. I wonder if that might not be
powerful enough for some registries.
It might not be, but I believe that it would be really, really hard
to describe how one would use strings (sequences of characters) as
input to the table. With the table as I have described it (and as the
JET folks have in their document), the order of the records doesn't
matter. If you have strings as the index, it does.
We both propose partitioning the set of admissible labels into groups
(bundles). Paul imagines a function that constructs the entire group
given any member of the group, while I imagine a function that computes
a group identifier given any member of the group, where the group
identifier could be a single member of the group arbitrarily chosen to
stand for the whole group. Either kind of function implies the same
partition of the space, and both functions would use the same tables,
but I think the group-id function might be easier to describe and
understand. The group-construction function might be useful internally
by the registry, if the registry needed to enumerate the group, but that
doesn't really scale.
This seems like a somewhat academic difference, but I am probably
missing something. Can you say where it might be important?
That brings us to an issue I neglected to address: If the registry (or
the registrant) decides that all members of the group should be visible,
how will that work?
That is shown in the document.
Will it scale?
Absolutely. As long as the zone's name servers can serve the records,
there is no problem. Even if the database is kept on disk instead of
in RAM, the response time on modern computers for even a gigantic
zone is low relative to typical network delays. There are also other
mitigating methods for huge zones, such as partitioning the responses
on different servers at the same address. The VeriSign folks have
already done a lot of research on this for the .com zone.
The combinatorics are exponential.
I think the only way it would work well is if the authoritative DNS
servers (both the registry's servers that delegate the name, and the
registrant's servers that provide the data for the name) include support
for the grouping. I guess you would supply the tables to the DNS
server, and it would perform the group-id computation whenever a request
comes in, then look for the group-id in the zone database. This would
require a standard machine-readable format for describing the grouping
policy for a zone.
We disagree here. I don't see that requirement at all. As the
managers of the current large zones have shown, you can have gigantic
Without that support in the DNS server, I think the sensible approach
is for the registrant to choose individual member(s) of the group to be
visible, and let the others be invisible (blocked). Registries could
come up with a pricing plan, maybe the normal registration fee for a
group with one visible member, and a small additional fee for each
additional visible member.
Even though we disagree about the motivation for this, we agree that
this is a good option for registries. I'm adding it to the next
version of the document.
You could also imagine that the registry, rather than the registrant,
chooses which member(s) will be visible, but I think it would be
difficult for registries to come up with rules that would please
everyone; it would probably be easier to let the registrant choose, and
simply store the list.
Speaking of "scaling", your suggestion makes scaling harder. That is,
the registration process would have to include a step where the
registrant chooses some things from a list. This is much more
difficult than the registry saying "here's what you get, you can
contact us if you don't like it". Well, of course they won't like it,
but at least the process isn't blocked.
It is up to the registry to decide what makes more sense to their customers.
--Paul Hoffman, Director
--Internet Mail Consortium