[arabic-vip] Variants implications on registry operations and DNSSEC

[Andrew Sullivan]

Dear colleagues,

Thanks for the comprehensive list.  This is an excellent foundation.
Some follow-up questions and observations are inline below.

On Sun, Jul 17, 2011 at 07:44:11AM +0000, Raed Al-Fayez wrote:
> 

> 1.  Whois: The registry might need to change how the whois
> information are handled and displayed. For example if someone
> searches for a string in the whois tool (web/cmd) and that string
> represents a variant for an already registered domain name then the
> registry might indicates the status of that variant (e.g. active or
> inactive) along with the whois information for the domain name
> (which is the base for that variant).

In this context, it's also important to remember that a command-line
whois may have trouble sending U-labels and high-bit addresses and so
on.  RFC 3912 explicitly notes that whois has not been
internationalized.  (Note that whois is _not_ an ASCII-only protocol,
but there's no way to signal character set.)

> 2.       Registration Processes: The registry should change the
> registration process

> b.  Is it possible for the same set of variants to be
> registered/used by different registrants?

I'm not sure whether I understand this question, because it leads me
to two different possible interpretations.  

The first is this: for a given label ("L") there is a set of possible
alternatives for that label (which we can represent as {PV1, PV2, …,
PVn} -- "PV" means "possible variant")  Is it possible for different
registrants to register L, PV1, PV2, and so on?  (For what it's worth,
the draft definitions document had some terms that were an attempt to
give names to these different labels.)

The second is this: for two given labels, La and Lb, each has a set of
possible alternatives for that label: {PVa1, PVa2, …, PVan} and {PVb1,
PBb2, …, PVbn}.  Now, since La and Lb can be registered by different
registrants, is it possible that the two possible variant sets have a
member in common (that is, could it ever happen that PVa1 == PBb1)?
What to do in this case?

> c.  Should the registry list all possible variants for a domain name
> at the end of the registration process or separate that from the
> registration process?

In a registry-registrar-registrant model, how would this listing work? 

> 3.        Delegation: The registry should decide how to handle the variants and how to activated/bundled them.
> 

Is that a claim if principle, or is it a question?  That is, if the
registrant is supposed to choose from the list in (c) above, shouldn't
the registrant have some say in this too?

> Here are some questions (about this issue) that each registry should consider:
> 
> a.       How to delegate the variants for a given domain name from technical point of view (use NS, DNAME, CNAME ..etc)?
> 

It can't be CNAME, note.  If there is a delegation, CNAME doesn't
handle that: it redirects things _at_ the name but not beneath it.  So
CNAME cannot be used to handle delegations.

> 4.       Reserved List: The registry may need to block reserved names variants.

Is there a definition of the term "reserved names variant"?  What
makes a name reserved?

> 
> b.      Can a variant be composed of code-points within one language table or it can be mixed of code-points across the script?

I'm nervous about this question, because of the terms "language table"
and "script".  Languages can be written in more than one script, and
most languages are written with a subset of the characters with a
given Unicode script property.  What is meant here?

> 7.        DNSSEC: The registry may need to think more about key management specially when they adopt variants.
> 
> Here are some questions (about this issue) that each registry should consider:
> 
> a.       Are the variants going to share the same signing-key or each variant will have its own signing-key?

>From the registry's point of view, the above may make too many
assumptions about how this will work.  There are two models for DNSSEC
operation.  One has the child (the registrant/registry) side transfer
the key to the parent (the registry), thereby allowing the parent to
generate the necessary DS record.  In that case, the parent could of
course enforce a rule about the same or different keys.  But if the
child sends the DS record to the parent, then the parent can't do
anything about this, because the DS is a hash and its value will
depend on the owner name.

> 8.       Defining Language table/variant table: The registry should decide what are the supported languages along with defining language table & variants table for each support language.
> 
> Here are some questions (about this issue) that each registry should consider:
> 
> a.       What are the supported languages in the registry's TLD?

There was an earlier question about whether the registrant needs to
provide the language for the label.  If not, but there are limitations
on the "supported language", then how will this work?

Best regards,

Andrew

-- 
Andrew Sullivan
ajs at anvilwalrusden.com