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

"Gould, James" <JGould@verisign.com> Mon, 12 May 2014 17:52 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 651AD1A077C for <ire@ietfa.amsl.com>; Mon, 12 May 2014 10:52:21 -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, 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 BeN8duxGuJOY for <ire@ietfa.amsl.com>; Mon, 12 May 2014 10:52:18 -0700 (PDT)
Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id DAF401A0745 for <ire@ietf.org>; Mon, 12 May 2014 10:52:14 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKU3EKSNkGXQN18By0j1XPaT54BmCVPgYI@postini.com; Mon, 12 May 2014 10:52:10 PDT
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s4CHq8a1019744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 13:52:08 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 12 May 2014 13:52:07 -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: AQHPa5AYJxQav2kLAEuW42npt1gQaZs4lTGAgAFWj4CAAwUEgIAAlswA//+3ToA=
Date: Mon, 12 May 2014 17:52:06 +0000
Message-ID: <CF967DF6.5EB0A%jgould@verisign.com>
In-Reply-To: <53710F30.3010500@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="euc-kr"
Content-ID: <A16C4D0865617E4D97A7AEBD8CDF8D17@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ire/0Dzdhf7aP3XQl5fkykGbLrpAbIk
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 17:52:21 -0000

Klaus,

My feedback is below.

-- 
 
JG
 

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




On 5/12/14, 2:13 PM, "Klaus Malorny" <Klaus.Malorny@knipp.de>; wrote:

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

I didn’t imply that the registries are bound to the OIDN and VIDN's data
model of draft-kong-idn-variants-mapping, but that a one-to-many
relationship was the only known relationship for variants.  Having a
primary OIDN that variants are enabled / disabled from is not as complex,
but it is certainly less flexible.

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

When changing the registrant (update) or registrar (transfer), does the
entire group of variants get updated at once?

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

If the many-to-many relationship does not have any additional attributes
that need to be deposited, then <variantGroup> could be a simple data type
(token) that is a tag for the variant group without any linkage to an
entity / object.  It’s best to leave the intent and meaning of
<originalName> as is and simply add a new element to handle this case.
The CSV model would add the corresponding optional
<csvDomain:fVariantGroup> and <csvNNDN:fVariantGroup> elements.  Does this
work for you?  

>
>
>Regards,
>
>Klaus
>
>
>
>
>
>