Re: [ire] New version (4) of the spec and new draft on DNRD (1)

["Gould, James" <[e-mail]>]

Gustavo,

I noticed the following additional items with draft-arias-noguchi-dnrd-objects-mapping-01:


  1.  The description of the <crID> and <upID> should match what is in the EPP RFC's.  Specifically, change "identifier of the registrar" to "identifier of the client".  In our registries we have account users (verisign as well as registrar) that are reflected in the <crID> and <upID> fields via the user's user name (e.g. jgould).  This is important to track exactly who took the action, since actions can be taken outside of the EPP channel (Registrar Tool, CSR Tool, batch) that should properly be reflected in the <crID> and <upID> elements.  Now the next logical question is whether there needs to be a deposit for users to link the "client identifiers" to.  I would imagine that an EBERO provider would import the <crID> and <upID> fields as strings and replace them (most likely using different fields) with real user identifiers based on future updates to the objects.
  2.  The question is whether the authInfo should be escrowed at all since these reflect secret passwords.  Our system stores them encrypted and I don't believe it is a good security practice to escrow them in a decrypted form or even provide a tool that can decrypt them.  I believe that the EBERO provider recovering a registry from the data escrow deposit can generate new random authorization info values and make them available in bulk to the registrars or on-demand by the registrars submitting an EPP info command for the objects.  What are your thoughts with this?

--

JG

[cid:B4B186C8-7F18-4E68-8BF2-41748125A70A]

James Gould
Principal Software Engineer
[e-mail]

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



From: <Gould>, James Gould <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, November 14, 2012 6:06 PM
To: Gustavo Lozano <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ire] New version (4) of the spec and new draft on DNRD (1)

Gustavo,

Below is my feedback for draft-arias-noguchi-dnrd-objects-mapping-01:


  *   High level
     *   There was support for an <extension> element for each of the objects (domain, host, and contact) in draft-arias-noguchi-registry-data-escrow-02 that never made it into draft-arias-noguchi-dnrd-objects-mapping.  What is the mechanism to include attribute extensions for the objects?
  *   Domain Object
     *   Based on feedback to the NNDN Object I suggest adding the following domain object elements:
        *   <uName> - An OPTIONAL UTF-8 encoded fully qualified name of the IDN domain name object.
        *   <idn> - An OPTIONAL boolean flag indicating if the domain name object is an IDN domain name object.
        *   <language> - An OPTIONAL language tag value for an IDN domain name object. The language tag value MUST be one of the <language> elements contained in an <idnTableRef> element
        *   <variant> - An OPTIONAL boolean flag indicating if the domain name object is an IDN variant domain name object. If the <variant> value is "true" the <originalName> SHOULD be set with the original IDN domain name object.
        *   <originalName> - An OPTIONAL fully qualified name of the original IDN domain name object related to the variant domain name object. This value SHOULD be set if <variant> is "true".
        *   <reserved> - An OPTIONAL boolean flag indicating if the domain name object is a reserved domain name object. A reserved domain name object is not registered by a client but by the server to ensure that it can't be registered by a client.
     *   <deDate> is not typically a true data element in the SRS since it is calculated by the RGP policies.  There can be other statuses that have additional date policies like other pending statuses (pendingCreate, pendingUpdate, pendingRestore).  It would be better to include a date (created date) that a status was set that matches what is typically included in the data model along with a pending status policy set of elements.  This way it makes it straight forward to create the deposits and consume the deposits.
     *   <variantGenerator> might not be needed.  If variants are blocked or available only to the registrant of the original IDN then that could be captured in a registry policy descriptor instead of on a per domain basis.  Inclusion of the canonical variant won't be of much use for an EBERO provider, since the EBERO provider would generate the canonical variant using their canonical variant generation function.
  *   Host Object
     *   Should an optional <uName> be supported similar to a <uName> element for the domain object?
     *   Should a <parentDomain> element be added?
        *   An OPTIONAL parent domain name for the subordinate host object.
     *   Could add an <idn> element similar to what I propose for the domain object
        *   An OPTIONAL boolean flag indicating if the host object is an IDN host object.
  *   Contact Object
     *   The <roid> element is missing from the list of elements
     *   Registrar contacts çan be different from object contacts since they are typically not provisioned via EPP and they could have types directly assigned to them (admin, tech, billing, legal, icann, abuse, etc.). It would be good to be able to identify which contacts are registrar contacts versus object contacts and support a set of optional registrar contact elements. The registrar contact could be routed to a different data source (e.g. account / registrar database) instead of being included in the registry database directly.  The draft-gould-thippeswamy-dnrd-csv-mapping-01 draft defines some of the registrar contact specific attributes for reference.
  *   Registrar Object
     *   It would be good to support a <status> element that could support a single status value like below with an optional name attribute to define the sub-status or the custom status name:
        *   ok - A normal status value for a registrar object.
        *   Hold - A restricted status value for a registrar object.
        *   Terminated - A status for a registrar object that has no remaining access or privileges.
        *   Custom - A custom status that is defined using the "name" attribute.
     *   Recommend not reusing the <postalInfo> element of the contact object for the registrar.  I recommend including the following registrar specific elements:
        *   <name> - One or two <rdeRegistrar:name> elements that contain the name of the registrar. Two elements are provided so that name information can be provided in both internationlized and localized forms
        *   <addr> from the contact <postalInfo> element.
     *   I don't believe there is any need for an <authInfo> element for the registrar object.
     *   Add <crID> <upID> elements similar to the other objects.
  *   NNDN Object
     *   Wouldn't it be better to merge the domain object with the NNDN object, since the NNDN object attributes are just additional attributes for domains (e.g. IDN domain)
     *   The <uName> element could be an optional domain object element
     *   The domain object could include an <idn> element that indicates whether the domain name is an IDN domain name.
     *   The <nameState> element could be reflected with the following optional domain object boolean elements:
        *   <reserved> element that matches the "blocked" tag
        *   <withheld> element that matches the "withheld" tag
        *   <variant> element that matches the "allocated" tag.  A domain object marked as a <variant> SHOULD include a <originalName> domain object element that includes the name of the original IDN (OIDN).
     *   <crDate> would already be covered by the domain object <crDate>
     *   <originElement> could be handled with an OPTIONAL domain object <originalName> element that references the domain name of the original IDN (OIDN) for a registered variant.  Replicating the registrant I don't believe would serve much of a purpose since the business logic could apply registrant equivalence or precedence rules between related IDN domains (OIDN and VIDN's).

--

JG



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

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






On 10/24/12 9:13 PM, "Gustavo Lozano" <[e-mail]<mailto:[e-mail]>> wrote:

All,

New versions of both data escrow drafts have been published:
http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-01
http://tools.ietf.org/html/draft-arias-noguchi-registry-data-escrow-04

* The main update is regarding IDN variant handling. ICANN have been
working on the IDN variants project for some time and knowledge gathered
from this project has been incorporated into
draft-arias-noguchi-dnrd-objects-mapping-01.
* Some elements were removed because they were redundant and could be
derived from other elements.
* Several elements are now OPTIONAL to accommodate different domain name
registry business models.

We would like to get feedback regarding these new versions of the drafts,
especially regarding the proposed IDN variants handling approach.

Expect a new version of the drafts shortly in which we propose the
extension mechanism.

Thank you.

Regards,
Gustavo

_______________________________________________
ire mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ire