Re: [ire] Support for Launch Applications and Claims in draft-arias-noguchi-dnrd-objects-mapping

[James Mitchell <[e-mail]>]

SMD and Claims information should not be included in the deposit as in most cases this is akin to the escrow of partial historical information not required to rebuild a working registry. However those registry operators that offer services that depend on, or require this information for the operation of the registry, should be escrowing this data already as prescribed in the Registry Agreement, Specification 2, Section 3.2, copied below for everyones reference.

3.2.            Extensions.  If a Registry Operator offers additional Registry Services that require submission of additional data, not included above, additional “extension schemas” shall be defined in a case by case basis to represent that data.  These “extension schemas” will be specified as described in Part A, Section 9, reference 2 of this Specification.  Data related to the “extensions schemas” will be included in the deposit file described in Part A, Section 3.1 of this Specification.  ICANN and the respective Registry Operator shall work together to agree on such new objects’ data escrow specifications.

I believe this is an ideal candidate to continue as a separate extension independent of the already unreadable escrow specification. Further, I don’t foresee any need to restore a failed registry into pending launch phase and would rather not see it in the specification. Again, I would consider it as an extension and treated as above.

Regards,
James Mitchell
Product Manager / ARI Registry Services

From: <Gould>, James <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 13 May 2014 10:34 pm
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [ire] Support for Launch Applications and Claims in draft-arias-noguchi-dnrd-objects-mapping

It was brought to my attention a little while back that a registry was having difficulty depositing launch applications using the CSV model of draft-arias-noguchi-dnrd-objects-mapping, since the primary key of the CSV files is the domain name (<csvDomain:fName>) and not the domain id (<csvDomain:fRoid>).  Additionally, the launch sunrise and claims attributes are not supported (phase, SMD identifier, mark, application status, claims notice identifier, claims validator identifier, claims accepted date, etc.).  I created a version of the draft that switched the domain CSV primary key to <csvDomain:fRoid> and added the CSV launch fields for sunrise and claims.   It is checked in at the GitHub project https://github.com/james-f-gould/draft-ryde.  I would like to hear whether such a change is needed.  Any feedback is welcome.

Thanks,

--

JG

[cid:C77634C8-94B3-4A86-B8A3-2EF18FC3E5BB]

James Gould
Principal Software Engineer
[e-mail]<mailto:[e-mail]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com
“This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”