Re: [ire] question regarding IDN variant mapping, <orignialName> value

Klaus Malorny <Klaus.Malorny@knipp.de> Sat, 10 May 2014 11:06 UTC

Return-Path: <Klaus.Malorny@knipp.de>
X-Original-To: ire@ietfa.amsl.com
Delivered-To: ire@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A534C1A0217 for <ire@ietfa.amsl.com>; Sat, 10 May 2014 04:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pasfhlZ0toi for <ire@ietfa.amsl.com>; Sat, 10 May 2014 04:06:44 -0700 (PDT)
Received: from kmx10a.knipp.de (clust3a.bbone.knipp.de [195.253.6.83]) by ietfa.amsl.com (Postfix) with ESMTP id EFA1F1A021B for <ire@ietf.org>; Sat, 10 May 2014 04:06:42 -0700 (PDT)
Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 111F657; Sat, 10 May 2014 13:06:36 +0200 (MESZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id 9KLThT1oBLny; Sat, 10 May 2014 13:06:27 +0200 (MESZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 8149F50; Sat, 10 May 2014 13:06:27 +0200 (MESZ)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id s4AB6Qdl019202; Sat, 10 May 2014 13:06:26 +0200 (MESZ)
Message-ID: <536E083D.90409@knipp.de>
Date: Sat, 10 May 2014 13:06:37 +0200
From: Klaus Malorny <Klaus.Malorny@knipp.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Thunderbird/32.0a1
MIME-Version: 1.0
To: "Gould, James" <JGould@verisign.com>, "ire@ietf.org" <ire@ietf.org>
References: <CF927212.5E7D4%jgould@verisign.com>
In-Reply-To: <CF927212.5E7D4%jgould@verisign.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ire/PwkdcjWAlgYsJU5wTvcheot7Vrs
Subject: Re: [ire] question regarding IDN variant mapping, <orignialName> value
X-BeenThere: ire@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <ire.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ire>, <mailto:ire-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ire/>
List-Post: <mailto:ire@ietf.org>
List-Help: <mailto:ire-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ire>, <mailto:ire-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 May 2014 11:06:46 -0000

On 09.05.2014 20:40, Gould, James wrote:
> Klaus,
>

Hi James,

thanks for answering.

>
> I view A as the OIDN and B as the VIDN, where if A is deleted, B should also be
> deleted.  There could be a pre-condition that VIDN's (B) be disabled or deleted
> prior to allowing the OIDN to get deleted.  That means that no orphan VIDN’s
> should exist when deleting the OIDN.  If deleting the OIDN deletes all VIDN’s
> then they would be deleted together.  I would imagine that domain C would only
> be allowed as a VIDN of A.  If not, I would need to better understand the
> registry logic for variants.

But why this restriction? The advantage of the "object model" over the 
"attribute model" is -- besides the ability to have different name servers 
and/or DNSSEC data -- that you only have a loose bundling. Also, in some 
scripts, you don't have a variant that is "original". If you have two variants 
which have equal value, what makes the one the "original" and the other not? For 
example, we have this situation with the Chinese traditional and simplified 
ideographs and also with Arabic letters. Why should a registrant, who has 
registered A at first and then B, shall not be able to give up variant A at a 
later point in time, while keeping variant B?

Maybe I miss something, but while I think it is at a registry's discretion to 
use a policy as you describe, I do not see neither technical nor procedural or 
legal needs for such constraints.

> Although the draft does not explicitly define that the <originalName> must
> exist, the existence of referenced entities should be expected throughout the
> draft.  The same could be stated for the <domain:hostObj> or <rdeDom:contact>
> references, but I believe it is expected that the referenced hosts or contacts
> must already exist.
>
> I view the OIDN’s to have a containment relationship with the VIDN’s in both
> your models, where the only difference is whether the domain attributes are shared.

I think it is not within the authority of the escrow format to enforce such a 
policy. I therefore propose to define the <originalName> as follows:

   1) The "original name" is a FQDN (as defined in the draft).
   2) The "original name" identifies a group of domain names that are
      considered to be variants of each other.
   3) The "original name" does not need to refer to an existing domain object.
   4) If the "original name" is not given with a domain, it is implicitly the
      name of the domain. This rule does not apply to NNDNs.

Rule 4) assures the compatibility to registry models where a "primus inter 
pares" exists (i.e. the OIDN in your description) and the "original name" is not 
generated in escrows for these objects.

> JG
>

Regards,

Klaus