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

[Andy Newton <[e-mail]>]

On 9/4/12 11:00 PM, "Linlin Zhou" <[e-mail]> wrote:

>We have a few comments for the unified response draft.
>
>1. The unified response draft just enumerates and combines the data
>elements
>of names and numbers. We think the coders of IP Whois and domain Whois may
>different. This draft easily makes them confused and asks the readers
>especially coders to identify which sections belong to names and which
>sections belong to numbers.
>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.
>
>"delegationKeys" : [
>       {
>         "algorithm": 7,
>         "digest" : "E68C017BD813B9AE2F4DD28E61AD014F859ED44C",
>         "digestType" : 1,
>         "keyTag" : 53814
>       }
>     ]
>
>"uris" : [
>	...
>	  {
>         "type" : "held",
>         "uri" : "http://example.net/location/xxxx"
>      }
>]
>I wonder why we need keys and location information in domain Whois
>information.

Some domain registries do have DNSSEC key information in Whois, so this is
completely appropriate for both DNRs and RIRs to the best of my knowledge.
I would invite DNSSEC people to look over what we have done here.

As for location, that notion gets conflated with the postal address
information. That is one reason to call it out (other than the fact that
some Whois services point to location services). This is an appendix from
the latest edit of our draft (which unfortunately was not published):

   The postal address data listed in the entity object class (Section 4)
   does not necessarily represent location.  The intent of this
   information is to provide a means to send postal mail to an entity.
   While in some cases it may also be the location of the entity, there
   is no gaurantee that the two are the same.  Accurate representation
   of location is topic unto itself, and registries wishing to show
   location of object instances should use the 'geo' or 'held' URI types
   as meantioned in Appendix A.3.



>2. Names don't have consensus on common elements.
>In the Vancouver meeting, object inventory work just begun and design team
>for names object selection was asked to be formed by the chair. The
>element
>listed in the draft such as "resoldBy", unfortunately I did not find any
>registry support it in 104 ccTLDs and 18 gTLDs Whois data we collected.
>There are more than 200 name registries. The common elements selection
>work
>is far more complex than RIR. We need time to do this.


resoldBy is from an ICANN SSAC document on Whois data models. When I
looked at what ICANN had recommended, this was the only missing element.

>3. We suggest a high level structure for the unified response.
>{
>	registrationObject:
>	{
>		/*common*/
>		/*unique*/
>	}
>	registrationObject:
>	{
>		/*common*/
>		/*unique*/
>	}
>}
>
>registrationObject may refer to registration , nameserver or contact
>information. "Common" refers to the common part of names and numbers.
>"Unique" is the respective unique elements of each other.

This is addressed by the prefix notion in Section 6.2 of
draft-designteam-weirds-using-http-01
(http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-6
.2). The unified-response draft references it.

-andy