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

["Gould, James" <[e-mail]>]

Klaus,

My feedback is below.

-- 
 
JG
 

 
James Gould
Principal Software Engineer
[e-mail]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com




On 5/12/14, 2:13 PM, "Klaus Malorny" <[e-mail]> 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
>
>
>
>
>
>