Subject: [provreg] Escrow, DNRD rdeDomain:trDate vs. rdeDomain:trnData

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Sun, 12 Apr 2015 01:01:39 +0200

Hi,

I have a FIXME in my code to implement trDate in rdeDomain, i.e. the
Domain Escrow data.

It seems the dnrd-objects-mapping-05 still specifies rdeDomain:trDate
but the changelog of registry-data-escrow-06 seems to mention that
rdeDomain:trDate was replaced by rdeDomain:trnData.
Who's right? I suggest to fix this by removing the redundant
rdeDomain:trDate from the DNRD as per the changelog in the RDE draft.

thanks,
Long version below.

Now i (still) cannot find the official RFCs that describe either
Registry Data Escrow
or
DNRD Objects mapping

So let's assume that the now expired drafts still are the base of the
escrow schema.
AFAICS the latest versions currently are:

https://tools.ietf.org/html/draft-arias-noguchi-registry-data-escrow-06
resp.
http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05

(please correct me if i'm wrong).

The RDE-06 draft 11.2.7 and 11.2.8 suggest that trDate of domains and
contacts were removed.
Yet, the DNRD-05 does mention trDate for domain, host and contact
(didn't look at the CSV parts)

I am not affected by host-transfers, but if the trDate of domains and
contacts is removed (in favour of the trnData) then the same should be
done for hosts, too.

Please fix.
TIA,

---

From: "Gould, James" <[email-masked]>
Date: Mon, 13 Apr 2015 17:40:45 +0000

Hi,

I would go with what is defined in draft-arias-noguchi-dnrd-objects-mapping as authoritative.

The question raised is whether the rdeDomain:trDate, rdeContact:trDate, rdeHost:trDate elements for XML and the rdeCsv:fTrDate element in the “domain”, “host”, and “contact” CVS files should be removed.  These elements match up to what is supported in the EPP RFC’s.  For example in the EPP Domain Name RFC 5731, the domain info response includes the optional domain:trDate element that is separate from the elements returned in a transfer query response.  Although the domain:trDate element could be derived from the transfer query response domain:acDate element, from a data model perspective they may be separate attributes and subsequently the data escrow should support both the rdeDomain:trDate, rdeContact:trDate, rdeHost:trDate elements in the XML model and the rdeCsv:fTrDate element in the CSV model.  Thoughts on this?

On the status of the drafts, Barry Leiba, the IETF Applications Area (app) Area Director (AD),  agreed to sponsor the draft-arias-noguchi-registry-data-escrow and draft-arias-noguchi-dnrd-objects-mapping drafts for standards track.  Barry will review the drafts and his feedback will be incorporated into subsequent versions of the drafts.  We will be asking for Implementation Status information similar to section 6 of draft-ietf-eppext-launchphase, so if you do have Implementation Status information that you would like incorporated into draft-arias-noguchi-registry-data-escrow or draft-arias-noguchi-dnrd-objects-mapping, please forward it on.

If you have any additional feedback, please send it to the IRE ([email-masked]<mailto:[email-masked]>) mailing list.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Apr 11, 2015, at 7:01 PM, Bernhard Reutner-Fischer <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

thanks,
Long version below.

Please fix.
TIA,