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

From: Klaus Malorny <[email-masked]>
Date: Fri, 09 May 2014 16:07:37 +0200

Hi all,

my colleagues and I came across a specific problem regarding of the handling of 
IDN variants in escrows, and we did not find a clear answer in the 
specifications[1].

As you might know, there are basically two models of how to treat IDN variants:

  1) as an attribute to a domain, i.e. variants are part of a single domain,
     the names are typically supplied via an EPP extension to the create
     and update commands. (example: .cat gTLD registry)

  2) as separate domain objects, i.e. for each variant, separate create and
     delete commands have to be issued to add or remove them. The registry
     may restrict operations so that two variants can not be associated with two
     different registrants and so on. (example: .ca ccTLD registry)

The specification provides an <originalName> element (in the XML form, a 
respective field in the CSV form) to link these variants to each other, both for 
the domain objects and for the NNDNs. While the latter is quite suitable to 
represent the model described in 1), the first is likely intended for the model 
described in 2).

The question now is, what does that field actually contain in the model 2)? Of 
course, a domain name, as the specification demands, but which one?

If it would need to be one of the existing variants, this would become a problem 
on an incremental update. For example, if we have the variants A and B, and B 
would point to A in the <originalName>: If A gets deleted, B remains factually 
unchanged, and would not be reported in an incremental escrow. When the data 
gets reconstructed (for example by an EBERO provider), the importer might find 
the reference to A, but not A itself, because its deletion was reported. Also, 
if a new domain C is registered that is a variant of A and B, it would likely 
point to B instead of the deleted domain A. This would also puzzle a potential 
importer.

On the other hand, the specification does not clearly define that the name which 
is specified by <originalName> needs to exist at all. One could declare one of 
the potential variants as a "generic", "canonical" variant, which is used for 
this field even if this variant itself is not registered. For example, if D 
would be this generic variant, and the variants A and B have been registered, 
they both would refer to D in the <originalName> field. Thus, if either A or B 
gets deleted, nothing would break. An importer would simply group domain names 
that refer to the very same name, whatever this is.

Any ideas, any opinions, any interpretations of the specs? This would be greatly 
helpful for us.

Regards,

Klaus

[1] https://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05

---

From: "Gould, James" <[email-masked]>
Date: Fri, 9 May 2014 18:40:52 +0000

Klaus,

As you point out the draft supports both models.

For model #1 the NNDN Variant IDN (VIDN) would reference the Original IDN (OIDN) using the <originalName> element in XML or the <csvDomain:fOrginalName> field in CSV.  I would assume that for model #1, since the variant is an attribute of the OIDN, that all of the domain attributes are shared and that it’s a containment relationship.  Deleting the OIDN should result in the deletion of the related variants (VIDN’s).

For model #2 the VIDN is treated as a domain entity with the <rdeDomain:domain> XML element or the CSV “domain” file, with the relationship between the VIDN and the ODIN using the the <originalName> element in XML or the <csvDomain:fOrginalName> field in CSV.  I still view this as containment relationship, where the VIDN's have independent attributes but are contained under  the OIDN.  Deleting the OIDN should result in the deletion of the related VIDN's.

I cover your use cases below:

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.

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.

Thanks,

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 5/9/14, 10:07 AM, "Klaus Malorny" <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Regards,

Klaus

_______________________________________________
ire mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ire

---

From: Klaus Malorny <[email-masked]>
Date: Sat, 10 May 2014 13:06:37 +0200

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

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

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.

Regards,

Klaus

---

From: "Gould, James" <[email-masked]>
Date: Mon, 12 May 2014 13:12:26 +0000

Klaus,

My feedback is embedded below.

-- 
 
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 5/10/14, 7:06 AM, "Klaus Malorny" <[email-masked]> wrote:

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

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?

>> I view the OIDN¹s to have a containment relationship with the VIDN¹s in
>>both

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?

---

From: Klaus Malorny <[email-masked]>
Date: Mon, 12 May 2014 20:13:04 +0200

Hi James,

> 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

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

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

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

> 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

---

From: "Gould, James" <[email-masked]>
Date: Mon, 12 May 2014 17:52:06 +0000

Klaus,

My feedback is below.

-- 
 
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

>for the hosts. While this is not impossible, I haven't seen this in the

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.

>creation of the variants. You can take the Canadian registry (CIRA) as a

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

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