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

[Dr.Sarmad Hussain]

Dear All,

Unfortunately neither Baher nor I would be able to join tomorrow's call as
both are on vacation (and I will be on the road).  However, Mohamed will
start the call (first 5-10) minutes and I have requested to Manal to
coordinate the call.  This seems like an interesting discussion building up
and I will surely catch up through the session recording.

regards,
sarmad (in Salzburg)

On Mon, Jul 18, 2011 at 8:16 PM, Andrew Sullivan <ajs at anvilwalrusden.com>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/arabic-vip/attachments/20110719/3b6f70d7/attachment.html