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

Klaus Malorny <Klaus.Malorny@knipp.de> Mon, 12 May 2014 16:13 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 E10101A034E for <ire@ietfa.amsl.com>; Mon, 12 May 2014 09:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level:
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DMsqCnKlcgO1 for <ire@ietfa.amsl.com>; Mon, 12 May 2014 09:13:32 -0700 (PDT)
Received: from kmx10a.knipp.de (clust3a.bbone.knipp.de [195.253.6.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB421A033E for <ire@ietf.org>; Mon, 12 May 2014 09:13:32 -0700 (PDT)
Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 268F74D; Mon, 12 May 2014 18:13:25 +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 D+SdzP4XxnVT; Mon, 12 May 2014 18:13:18 +0200 (MESZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id B4B704C; Mon, 12 May 2014 18:13:18 +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 s4CGDHe2029630; Mon, 12 May 2014 18:13:17 +0200 (MESZ)
Message-ID: <53710F30.3010500@knipp.de>
Date: Mon, 12 May 2014 20:13:04 +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: <CF9634CD.5E8B8%jgould@verisign.com>
In-Reply-To: <CF9634CD.5E8B8%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/rr4KL-UMf7jilkAuf-tjl1F-pFA
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: Mon, 12 May 2014 16:13:35 -0000

On 12.05.2014 15:12, Gould, James wrote:
> Klaus,
>
> My feedback is embedded below.
>

Hi James,

> The data escrow needs to reflect the possible set of data models, where
> the only known model for related variants is a one-to-many relationship of
> OIDN to VIDN¹s as reflected in draft-kong-epp-idn-variants-mapping (
> http://tools.ietf.org/html/draft-kong-epp-idn-variants-mapping ) with
> different levels of sharing (share all in your model #1 and NNDN, or share
> none or some in your model #2 and separate objects).

Well, to my knowledge, registries are not bound to data models that are 
published as RFCs or expired drafts ;-). Also, the Kong mapping is clearly an 
implementation of model #1, and this assumes that the OIDN remains constant -- 
otherwise, a domain "rename" would have to be implemented, like this can be done 
for the hosts. While this is not impossible, I haven't seen this in the wild...

> What you are
> referring to is a different model that reflects a many-to-many
> relationship with no concept of an OIDN, since all of the variants are
> sibling objects (A, B, and C are related to each other with no hierarchy).

Yes -- more or less -- as this is a matter of definition.

>  I¹m assuming that in your data model that you have some form of a link
> table to reflect the relationship.

This is still in the planning phase, however, there is no dedicated object or 
attribute whatever planned that is publicly visible.

>  Are all related variants authorized to
> a single registrant?  Does your system need to ensure that any of the
> attributes remain the same, like the registrar and registrant, across the
> related variants?

Yes, contacts need to be the same, and this constraint is enforced after the 
creation of the variants. You can take the Canadian registry (CIRA) as a prototype.

>  From an EPP perspective, do you have a custom EPP
> extension to reflect the related variants, and if so can you reference it
> to help clarify things?

Yes, there will be an extension, but it will only occur in responses, not in 
commands.

> The data escrow is a representation of a data model, and it only makes
> sense to ensure that all object references exist.  Your proposed language
> change defines a new variant group entity or tag that does not match the
> existing supported data model.  To support your data model of a
> many-to-many relationship, a new entity (or tag) "variant group" would
> need to be defined.  Instead of using the <originalName> element to refer
> to a domain object (OIDN), something like <variantGroup> would be needed
> to reference a variant group entity or be used to tag the variant group
> string.  If <variantGroup> is a reference to an actual entity with
> attributes, I¹m assuming that the variant group entity would be removed
> once all variant references are removed. Are there other registries out
> there that support a many-to-many relationship for variants?

The proposal to concretize the <originalName> attribute in a manner that is 
compatible with our intended/the French model was simply meant to keep the 
effort low. I don't mind adding a new attribute of whatever name to the escrow 
format if this is considered the better way. However, I would like to avoid a 
separate new object type to which the "variantGroup" attribute is referring. 
Simply take it as the "city names on the map of domain names", figuratively 
spoken ;-) -- you won't link contact objects of persons living the same city to 
a "city" object in the escrow, just because they share that property...


Regards,

Klaus