Re: [ire] Escrow, DNRD rdeDomain:trDate vs. rdeDomain:trnData

"Gould, James" <> Mon, 13 April 2015 17:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 47C1B1AD0A3 for <>; Mon, 13 Apr 2015 10:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vhWCA35pK8Wf for <>; Mon, 13 Apr 2015 10:40:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF9891AD0A0 for <>; Mon, 13 Apr 2015 10:40:48 -0700 (PDT)
Received: by qgaj5 with SMTP id j5so3366932qga.1 for <>; Mon, 13 Apr 2015 10:40:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=jIYXqbuwOiM70pe2VHU1eFCZPliw/rbqR14TAFfCmYE=; b=DrTM5XL4/8tjobsyOjx/yDPgT5OfEIjdNfINEPKuhaTwUJc8VFyiCUTkW2Cs4ZMm9F pu2PbC7U1qI6CHacAVq7kj6NSKms3IrBuDUbLJ6EIH/Z040Li8wFOSn4+3zOCE7FM9Vk 1YtXZksBthOYUj4O7UcyF+x/chXitV76gyCi94si74DPKm56xELwNLIZEqdHUEaF+wWH v9KN3iuEYso4XP0v4V8V66NjKPKxkf76PM0DwOBwvzLpIHmW4+dMaNPE/pKzAghCazDu +VlKx+EXgYKYQAP4e+7vWPAedF9mkL/mkbMzsbxkMiT/mzoHlpyOy1L7D46tnMuQuVNZ aL0A==
X-Gm-Message-State: ALoCoQmNsFFOk4laaEGaRZsXmzsH8seUH6o8PqIpt7O0e77YDwcQLopsTMPJcaTBmqmFeN+TD2aUsELvI4v14sQpgFYtpEzu+w==
X-Received: by with SMTP id e10mr32445870qkh.36.1428946847871; Mon, 13 Apr 2015 10:40:47 -0700 (PDT)
Received: from ( []) by with ESMTPS id q8sm3451050qcg.2.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Apr 2015 10:40:47 -0700 (PDT)
Received: from (brn1wnexcas01 []) by (8.13.8/8.13.8) with ESMTP id t3DHejVP016561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 13:40:45 -0400
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Mon, 13 Apr 2015 13:40:46 -0400
From: "Gould, James" <>
To: Bernhard Reutner-Fischer <>
Thread-Topic: Escrow, DNRD rdeDomain:trDate vs. rdeDomain:trnData
Thread-Index: AQHQdKt7mJRusszepU2ciAF6AY0yvp1Le6YA
Date: Mon, 13 Apr 2015 17:40:45 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_8CA76639AA2E4E0593F010E5CCD86AB4verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [ire] Escrow, DNRD rdeDomain:trDate vs. rdeDomain:trnData
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Apr 2015 17:40:51 -0000


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 (<>) mailing list.





James Gould
Distinguished Engineer

12061 Bluemont Way
Reston, VA 20190<>

On Apr 11, 2015, at 7:01 PM, Bernhard Reutner-Fischer <<>> wrote:


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.

Long version below.

Now i (still) cannot find the official RFCs that describe either
Registry Data Escrow
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:

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