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

"Gould, James" <JGould@verisign.com> Mon, 12 May 2014 13:12 UTC

Return-Path: <JGould@verisign.com>
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 C623A1A0699 for <ire@ietfa.amsl.com>; Mon, 12 May 2014 06:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.201
X-Spam-Level:
X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 d4Rxo6jAZa1O for <ire@ietfa.amsl.com>; Mon, 12 May 2014 06:12:35 -0700 (PDT)
Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 945D51A031E for <ire@ietf.org>; Mon, 12 May 2014 06:12:33 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKU3DIuwBkhyDLEjNE02CpPPwjoWkUpxA/@postini.com; Mon, 12 May 2014 06:12:29 PDT
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s4CDCRFv016732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 09:12:27 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 12 May 2014 09:12:27 -0400
From: "Gould, James" <JGould@verisign.com>
To: Klaus Malorny <Klaus.Malorny@knipp.de>, "ire@ietf.org" <ire@ietf.org>
Thread-Topic: [ire] question regarding IDN variant mapping, <orignialName> value
Thread-Index: AQHPa5AYJxQav2kLAEuW42npt1gQaZs4lTGAgAFWj4CAAwUEgA==
Date: Mon, 12 May 2014 13:12:26 +0000
Message-ID: <CF9634CD.5E8B8%jgould@verisign.com>
In-Reply-To: <536E083D.90409@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <77773DE5DBDB5A4BA99FE2C5D5B9D70D@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ire/1Am_rVhGYyeZpDHjRGQQuG8SGJ8
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 13:12:47 -0000

Klaus,

My feedback is embedded below.

-- 
 
JG
 

 
James Gould
Principal Software Engineer
jgould@verisign.com
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com




On 5/10/14, 7:06 AM, "Klaus Malorny" <Klaus.Malorny@knipp.de>; wrote:

>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.

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).  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).
 I¹m assuming that in your data model that you have some form of a link
table to reflect the relationship.  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?  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?


>
>> 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.

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?


>
>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
>
>