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

[Francisco Obispo <[e-mail]>]

Hi James,

Now that I've spent a few hours on our implementation, let me add my two cents as well:



On Nov 14, 2012, at 3:06 PM, "Gould, James" <[e-mail]> wrote:

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



This seems reasonable and it would remove the need to have the NNDN Object.



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

Agreed, we should remove it!


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


+1



>  
> 	• Host Object
> 		• Should an optional <uName> be supported similar to a <uName> element for the domain object?

Yes

> 		• Should a <parentDomain> element be added?
> 			• An OPTIONAL parent domain name for the subordinate host object.


No, this can be calculated by looking at the labels.


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


We could trigger that with the presence of the uName field above. 


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

I agree with this approach, we in fact have two separate databases, so it makes a lot of sense to me.


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

Works for me.


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

+1


> 		• I don't believe there is any need for an <authInfo> element for the registrar object.


Excellent point, in fact, we don't currently store the registrar's password in the clear (it is handled by the database), and since there is already the need to get new certificate requests signed for TLS validation, that is something that can be configured at that time, no need to risk storing passwords in the clear because I'm envisioning that there will be humans involved in getting the registrars on board.


> 		• 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)


Yes, lets get rid of it.

Finally, I've been trying to setup the XML Schema Validation, but have found the Schemas to be poorly defined, specially when using complexTypes from EPP objects. Unless I'm missing something, we'll have to re-define the complexTypes in the rde* Schemas, to avoid using the EPP namespaces in the rde* instances.

t/tmp/test_01.xml:1: element name: Schemas validity error : Element '{urn:ietf:params:xml:ns:rdeContact-1.0}name': This element is not expected. Expected is ( {urn:ietf:params:xml:ns:contact-1.0}name ).





Francisco Obispo 
Director of Applications and Services - ISC
email: [e-mail]
Phone: [phone] || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE