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

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

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:

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.

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.

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.

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
[e-mail]

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



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



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

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