Subject: [ire] DNRD CSV 01 Draft

From: "Gould, James" <[email-masked]>
Date: Tue, 13 Nov 2012 13:25:29 +0000

All,

The Domain Name Registration Data (DNRD) Comma-Separated Values (CSV) Objects Mapping 01 draft has been created that addresses the issue raised by Christopher Browne and Chris Wright related to the use of list fields in the 00 draft.  The 01 draft is available below for feedback:

http://tools.ietf.org/id/draft-gould-thippeswamy-dnrd-csv-mapping-01.txt
http://tools.ietf.org/html/draft-gould-thippeswamy-dnrd-csv-mapping-01

Thanks,

--

JG

James Gould
Principal Software Engineer
[email-masked]

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

---

From: Christopher Browne <[email-masked]>
Date: Wed, 14 Nov 2012 13:40:01 -0500

> http://tools.ietf.org/html/draft-gould-thippeswamy-dnrd-csv-mapping-01

That looks to address the "list fields" issues, thanks.

I notice that you included a fair bit of optional information, such as
"whodunnit" (rdeCsv:fCrID) and "whendunnit" (rdeCsv:fCrDate), and
agree that it is preferable for them to be optional.

When I put my "loading it in" hat on, optional elements are often
troublesome, as someone trying to interpret it may find it difficult
to decide between:
a) Saying, "it was optional; we'll not bother loading it!" versus
b) Expecting optional pieces, and agonizing over what to do when that
data isn't there.

If it's not included, there's nothing to agonize over.

I still remain uncomfortable about there being two drafts indicating
two very different data representations.  I'd be happiest if one were
determined preferable, by the community, and the other one dropped.  I
don't have a strong preference; there are good reasons to like either
of them.  Having two standards would complicate the lives of EBERO
providers that would need to read the data.

---

From: James Mitchell <[email-masked]>
Date: Thu, 15 Nov 2012 12:57:06 +1100

On 15/11/12 5:40 AM, "Christopher Browne" <[email-masked]> wrote:

>> The Domain Name Registration Data (DNRD) Comma-Separated Values (CSV)
>>Objects Mapping 01 draft has been created that addresses the issue
>>raised by Christopher Browne and Chris Wright related to the use of list
>>fields in the 00 draft.  The 01 draft is available below for feedback:
>>

I would be hesitant to call this information optional for concern of
having to restore a registry that chose not to escrow "optional"
information. The exclusion of crDate in an escrow deposit would leave the
EBERO without complete registration (WHOIS) data. While the elements you
mentioned are "optional" in response to a domain/host/contact info query,
I find it hard to believe that a registry would not know the date that a
particular domain/host/contact was created and who it was created by.

I am only nitpicking on the use of the term optional and am not wanting to
get into a discussion about whether individual fields are mandatory or
not. This effort should stop once the data elements required to rebuild a
registry (EPP/WHOIS/DNS etc) can be escrowed and restored; it is outside
our control whether incumbent registry operators escrow complete and
accurate information.

>providers that would need to read the data.

I am also uncomfortable being two drafts. I do not see any value in trying
to create a "generic" registry data escrow specification when current
contributors are trying to solve one specific problem. I feel the current
separation makes it difficult to describe the process of restoring a
registry within the context of domain name registries; a high-level
description should provide some consistency in the process used by
implementors to test the completeness of their deposits. I will have
further comments on the two drafts in the coming days.

James

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