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

"Gould, James" <JGould@verisign.com> Fri, 09 May 2014 18:41 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 EBD711A0076 for <ire@ietfa.amsl.com>; Fri, 9 May 2014 11:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 8xE5Ji93OaiT for <ire@ietfa.amsl.com>; Fri, 9 May 2014 11:41:05 -0700 (PDT)
Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 640161A0053 for <ire@ietf.org>; Fri, 9 May 2014 11:41:00 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKU20hN1MKSPn6a6shWeIzK7FYlj3fNZXQ@postini.com; Fri, 09 May 2014 11:41:00 PDT
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s49IerUq011705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 14:40:54 -0400
Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 9 May 2014 14:40:53 -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: AQHPa5AYJxQav2kLAEuW42npt1gQaZs4lTGA
Date: Fri, 9 May 2014 18:40:52 +0000
Message-ID: <CF927212.5E7D4%jgould@verisign.com>
In-Reply-To: <536CE129.4010004@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: multipart/alternative; boundary="_000_CF9272125E7D4jgouldverisigncom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ire/vvTYcrsZq04Uk5s4LkKshgmiCSc
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: Fri, 09 May 2014 18:41:08 -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:

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
jgould@verisign.com

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



On 5/9/14, 10:07 AM, "Klaus Malorny" <Klaus.Malorny@knipp.de<mailto:Klaus.Malorny@knipp.de>> 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
ire@ietf.org<mailto:ire@ietf.org>
https://www.ietf.org/mailman/listinfo/ire