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

[Sarmad Hussain]

Dear all,

Thank you Manal and Mohammed for coordinating the call and for the summary,
and thank you all for the interesting discussion.  Should we continue to
discuss the UDRP issues in our call next week.  

Regards,
Sarmad

> -----Original Message-----
> From: Manal Ismail [mailto:manal at tra.gov.eg]
> Sent: Thursday, July 21, 2011 7:08 PM
> To: Dr.Sarmad Hussain; arabic-vip at icann.org
> Cc: baher.esmat; Mohammed El-Bashir
> Subject: RE: [arabic-vip] Variants implications on registry operations
> and DNSSEC
> 
> Dear Sarmad ..
> Apologies for the delayed message ..
> We had an interesting discussion on the Registry Operations Issues
> based on the email sent by Raed who answered other members' questions
> and provided necessary clarification .. Unfortunately we did not have
> the time to discuss UDRP issues .. I tried to reflect points raised
> during the call in the attached document, marked in track changes .. I
> also tried to insert the name of the commentor in square brackets .. I
> do apologize in advance for any issues I may have overlooked or
> misunderstood .. Please feel free to correct any ..
> 
> Finally, allow me to highlight the following issues that were also
> raised during the call:
> - Iftikhar: Should government approval be sought in delegation of
> variants?
> - Alireza: Does all this, UDRP ....etc, fall within the scope of the
> WG?
> - Nicolas: Should we compile a list of all languages supported by the
> script? should each registry post the languages he/she support despite
> the fact that we don't have technical means to differentiate between
> languages using the same script?
> 
> I hope you find this quick summary useful till you catch up through the
> recording and that colleagues find it somehow accurate ..
> 
> Kind Regards
> 
> --Manal
> 
> ________________________________
> 
> From: sarmad.hussain at kics.edu.pk on behalf of Dr.Sarmad Hussain
> Sent: Mon 18/07/2011 09:28 PM
> To: arabic-vip at icann.org
> Cc: baher.esmat; Manal Ismail; Mohammed El-Bashir
> Subject: Re: [arabic-vip] Variants implications on registry operations
> and DNSSEC
> 
> 
> 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
> 
>