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

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

Klaus,

My feedback is embedded below.

-- 
 
JG
 

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




On 5/10/14, 7:06 AM, "Klaus Malorny" <[e-mail]> 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
>
>