Re: [weirds] New Unified DNR/RIR Internet-Drafts

[Arturo Servin <[e-mail]>]

Linlin,

On 5 Sep 2012, at 10:44, Linlin Zhou wrote:

> Hello Byron,
> 
> My comments are embedded.
> 
>>> Most parts of DNR objects inherit the naming or structure style from RIR
>>> response draft. Domain elements may not suitable to be expressed in the
>>> numbers way. For example, some elements are not available for names. See
>>> section 5.2 DNR domain object.
>> 
>> All elements of the response are optional, at the server's discretion.
>> 
> We absolutely understand they may be optional. 
> Our key point is some RIR elements, which are not useful for names, should
> not be included in the DNR objects.
> Vice versa, it does not make sense that the DNR elements like "registrar"
> should be included in the RIR objects, even if these elements are optional.

	The trade-off is to have more documents and some of those with only one or two elements. I prefer just one document with optional elements that may be common.


> 
>> I would be very interested to see what common elements are not represented
>> in the unified response draft.  
> 
> Me too. I am also very interested to see what common elements are not
> represented in the name response draft (draft-kong-dnrd-ap-response-json).
> Based on our current whois data collection result, there are 392
> self-designed elements in different name registries. I believe that there
> should be a few common elements among the 392 items which are still not
> clear. It's hard for us to get answers before finishing the object inventory
> work.

	If you find one that it is very common to names, we can include it. This is a WG call for adoption, not for publishing, so there is a lot of room to add more objects if we found and agree on them.

> 
>> Part of it may depend on what you mean by
>> "common," but I think the draft is really quite flexible in what it allows
> - any
>> type of entity may be represented, because the "type" attribute is an
> array of
>> strings, with no explicit enumeration of what is and is not allowed.
>> 
> I think the most difficult work for us is to define the common elements and
> structure. To be flexible is relatively easy. I also think our draft is
> quite flexible to be extended.
> 
>>> 3. We suggest a high level structure for the unified response.
>>> {
>>> 	registrationObject:
>>> 	{
>>> 		/*common*/
>>> 		/*unique*/
>>> 	}
>>> 	registrationObject:
>>> 	{
>>> 		/*common*/
>>> 		/*unique*/
>>> 	}
>>> }

	I think that this is more complex for users.


<snip>
> 
>>> In our opinion, the unified response draft should focus on the true
> common
>>> elements of numbers and names, not just list them all. The unique
> elements
>>> should be defined by RIR and domain registries separately. We support
>>> unified draft + redirection draft + query drafts of RIR/Domain +
> response
>>> drafts of RIR/Domain as working group documents.
>> 
>> I'm sorry, I'm not sure I understand what you're trying to say here.  What
> do
>> you mean by "true common elements" and "unique elements" ?  What do you
>> mean by "unified draft" - is this the using-http draft?  What do you
> expect to
>> see in a redirection draft, beyond just "301/307 Location header" ?  And
> finally,
>> do you expect to see a separate query draft for each of RIRs and DNRs, and
> a
>> separate response draft for each of RIRs and DNRs?
>> 
> My mainly concern is the response drafts. I think
> draft-newton-weirds-unified-json-response and separated response drafts by
> RIR and DNR (draft-newton-et-al-weirds-rir-json-response and
> draft-kong-dnrd-ap-response-json) should be the starting points for the WG.

	That was the original idea but we decided (the WG and chairs) other approach in Vancouver.

	You could use draft-kong-dnrd-ap-response-json/query to extend the common objects or if they are very common in names and the WG agrees we could add it to draft-hollenbeck-weirds-unified-rdap-query.

<snip>

Regards,
as