Subject: [weirds] Call for Adoption (was Re: New Unified DNR/RIR Internet-Drafts)

From: Andy Newton <[email-masked]>
Date: Tue, 4 Sep 2012 21:21:30 +0000

As unsurprizing as this may be, I support these documents for adoption as
working group items.

-andy

On 8/31/12 4:18 PM, "Murray S. Kucherawy" <[email-masked]> wrote:

>On Fri, Aug 31, 2012 at 5:35 AM, Hollenbeck, Scott
><[email-masked]> wrote:
>> So, a question for the chairs and group: combined with the "using http"
>>and redirection drafts, do we now have a set that's ready to become
>>working group documents?
>
>Having not yet spoken to Olaf (who is on vacation), my view is that
>this is in line with the vision the chairs presented in Vancouver for
>a path forward.  Kudos to you and Andy for taking this initiative.
>
>To the WG: I propose that we adopt these as initial working group
>documents toward our milestones.  Note, as usual, that they are merely
>starting points and foci for discussion; we need to develop them and
>reach working group consensus before they will be advanced for
>publication.
>
>I'll place them in Call For Adoption state now.  Please review them
>and comment as to whether you believe they are reasonable starting
>points for development.
>
>-MSK
>_______________________________________________
>weirds mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/weirds

---

From: Mark Kosters <[email-masked]>
Date: Tue, 4 Sep 2012 21:32:21 +0000

I support adoption of these docs as well.

Mark

On 9/4/12 5:21 PM, "Andy Newton" <[email-masked]> wrote:

>>o/weirds <https://www.ietf.org/mailman/listinfo/weirds>

---

From: Don Blumenthal <[email-masked]>
Date: Tue, 4 Sep 2012 18:43:29 -0400

I'll add my support.

Don

---

From: Steve Sheng <[email-masked]>
Date: Tue, 4 Sep 2012 15:53:15 -0700

+1, support for adoption.

-----Original Message-----
From: Mark Kosters <[email-masked]>
To: Andy Newton <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [weirds] Call for Adoption (was Re: New Unified DNR/RIR
Internet-Drafts)

---

From: Byron Ellacott <[email-masked]>
Date: Wed, 5 Sep 2012 12:53:34 +1000

+1, support adoption

  Byron

-- 
Byron Ellacott                  email:           [email-masked]
Technical Director, APNIC       sip:        [email-masked]
http://www.apnic.net            phone:         +61 7 3858 3100
________________________________________________________________________
 * Sent by email to save paper. Print only if necessary.

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 5 Sep 2012 11:00:18 +0800

The charter says "...producing a grand unified specification for both
numbers and names...". The working approach of unifying the names and
numbers makes sense. It can help the names improve the response draft.

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.

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.

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.

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.

We are willing to do more further work on object inventory. Hopefully more
domain registries will participate in this work to refine our domain common
elements. Based on the inventory result and unified approach, we would like
to update our domain response draft.

Linlin
CNNIC
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Murray S. Kucherawy
> Sent: Saturday, September 01, 2012 4:19 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts
> 
<[email-masked]>
> wrote:
and
> redirection drafts, do we now have a set that's ready to become working
group
> documents?
> 
> Having not yet spoken to Olaf (who is on vacation), my view is that this
is in line
> with the vision the chairs presented in Vancouver for a path forward.
Kudos
> to you and Andy for taking this initiative.
> 
documents
> toward our milestones.  Note, as usual, that they are merely starting
points
> and foci for discussion; we need to develop them and reach working group
> consensus before they will be advanced for publication.
> 
> I'll place them in Call For Adoption state now.  Please review them and
> comment as to whether you believe they are reasonable starting points for
> development.
> 
> -MSK

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 4 Sep 2012 20:11:02 -0700

Hi Linlin,

I support your comments,

In fact, I had originally suggested to use an enclosure format with namespace-like attributes to identify registry object regardless whether they were domain or number elements, that way, number registries could work on their own object format at the same time that domain registries, on a common architecture -not a common object format-

In addition, I believe that an extension mechanism for the protocol is necessary to model those unique requirements, specially in the ccTLD world. This hasn't been addressed as far as I know.

Lastly, I also suggested that the response should stand on its own, that is, if someone wanted to change the transport, or even store the documents for later use, they could do so without needing the HTTP headers.

I expect to see these suggestions incorporated into the proposal, in the mean time, I don't believe this is production ready.

Francisco

>> comment as to whether you believe they are reasonable starting points for

Francisco Obispo 
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Kevin Tse <[email-masked]>
Date: Wed, 05 Sep 2012 11:29:33 +0800

Hi Francisco,Linlin,

I support your comments.
The working of unifying NAME and NUMBER makes sense, but except the
'structure' i did not get the 'common' section for both NAME and
NUMBER.I wonder why.

I think the work of object inventory is still needed until we have
consensus on common elements.
 
Kevin.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Sep 2012 00:03:16 -0700

> consensus on common elements.

Just to be clear: I'm not proposing adoption of these documents as
completed working group items, but merely as starting points for
working on our deliverables.  Working group development would follow,
of course.

A fairly complete set would appear to be something like:

draft-designteam-weirds-using-http
draft-hollenbeck-weirds-rdap-sec
draft-hollenbeck-weirds-unified-rdap-query
draft-newton-weirds-unified-json-response
draft-kucherawy-weirds-requirements (but only if we want to keep a
requirements document going)

The issues of redirection and service discovery don't appear to be
covered in this set.  I seem to recall consensus ion Vancouver
swinging in the direction of deciding that we don't want to tackle
discovery on a first pass, but I can't recall where we landed on
redirection.  (I also admit I haven't yet reviewed the JSON response
document to know if it covers redirection.)  Please correct me if I'm
wrong there.

So far response to the middle three has been entirely positive.  Can I
get some comments on the first and last, and also on the issue of
redirection, and a few more comments from people representing the name
registries?

If there's consensus supporting these as starting point documents,
we'll invite the authors to submit them as WG items in another week or
so, and then we can get to work.

-MSK, WEIRDS co-chair

---

From: Byron Ellacott <[email-masked]>
Date: Wed, 5 Sep 2012 17:26:53 +1000

Hi Murray,

> document to know if it covers redirection.)  Please correct me if I'm

Redirects can be found here:

http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-5.2

> redirection, and a few more comments from people representing the name

I think I missed a call or two here, so to be clear, I support WG adoption of all five drafts.

Regarding redirection, the text in using-http suggests 301 for permanent relocations, and 307 for all other situations.  I am in favour of specifying only this much about redirection, leaving matters like authentication to be dealt with by each server-client interaction separately.

  Byron

---

From: Byron Ellacott <[email-masked]>
Date: Wed, 5 Sep 2012 17:32:17 +1000

Hi Francisco,

> In addition, I believe that an extension mechanism for the protocol is necessary to model those unique requirements, specially in the ccTLD world. This hasn't been addressed as far as I know.

The using-http draft hasn't yet been updated to refer to the unified query and response drafts, but in section 9 there is some text to this end.

http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-9

> Lastly, I also suggested that the response should stand on its own, that is, if someone wanted to change the transport, or even store the documents for later use, they could do so without needing t…

I think that the rdapConformance data structure should achieve this.  The only meta-data in headers is the response code, and the level attribute of the mime-type; the level information should be replicated in the rdapConformance information.  I agree with your reasoning here, so if I've missed something that is only stored in the HTTP headers, please let me know!

I will respond to some of Linlin's comments separately.

  Byron

---

From: Arturo Servin <[email-masked]>
Date: Wed, 5 Sep 2012 08:48:40 +0100

Support.

Regards,
as

---

From: Byron Ellacott <[email-masked]>
Date: Wed, 5 Sep 2012 17:49:43 +1000

Hi Linlin,

> section 5.2 DNR domain object.

All elements of the response are optional, at the server's discretion.

> I wonder why we need keys and location information in domain Whois

If you do not need or have or want to publish that information, then omit it.  You might need DNSSEC keys if you support DNSSEC for your domains, though.  APNIC does not currently have HELD location information, and would not include a "held" type link in a response.

> is far more complex than RIR. We need time to do this.

I would be very interested to see what common elements are not represented in the unified response draft.  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.

> 3. We suggest a high level structure for the unified response.

How does this relate to the query issued?  The proposed unified query syntax asks that the user explicitly fetch a specific resource, such as http://rdap.example.com/domain/example.com/ - would you envisage the returned response being a collection of objects related to that domain?

What's the advantage you see in returning a set of objects in the top level of the structure, instead of returning a domain object containing other objects as necessary?  What's the advantage, moreover, in having different structures for domains and numbers?

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

> to update our domain response draft.

I would like to see your object inventory work progressed, and if possible, submitted as an informational draft.  Helping people who come later understand how we arrive at our eventual conclusion will be useful.  Having clarity on whether there's any object data that's not represented in the unified response draft, and how common that object data is, would be very useful.

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 5 Sep 2012 17:44:35 +0800

Hello Byron,

My comments are embedded.

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

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

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

> How does this relate to the query issued?  The proposed unified query
syntax
> asks that the user explicitly fetch a specific resource, such as
> http://rdap.example.com/domain/example.com/ - would you envisage the
> returned response being a collection of objects related to that domain?
> 
> What's the advantage you see in returning a set of objects in the top
level of
> the structure, instead of returning a domain object containing other
objects as
> necessary?  What's the advantage, moreover, in having different structures
> for domains and numbers?
> 
I think you misunderstood my point. 

The registrationObject is based on nested structure. The common and unique
parts are logical concept. Both of these two parts can include nested
objects or elements.

The unified response draft should only focus on the common part, while the
unique part should "stand on its own" by names or numbers.

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

> I would like to see your object inventory work progressed, and if
possible,
> submitted as an informational draft.  Helping people who come later
> understand how we arrive at our eventual conclusion will be useful.
Having
> clarity on whether there's any object data that's not represented in the
unified
> response draft, and how common that object data is, would be very useful.
> 
Agreed. Thanks for your comments.
Linlin

---

From: Arturo Servin <[email-masked]>
Date: Wed, 5 Sep 2012 11:12:47 +0100

Linlin,

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

> clear. It's hard for us to get answers before finishing the object inventory

	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.

>>> 3. We suggest a high level structure for the unified response.

	I think that this is more complex for users.

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

---

From: Andy Newton <[email-masked]>
Date: Wed, 5 Sep 2012 15:08:29 +0000

>I wonder why we need keys and location information in domain Whois

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.

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

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

---

From: "Carlos M. martinez" <[email-masked]>
Date: Wed, 05 Sep 2012 12:52:18 -0300

I support adoption.

I'd like to point out that the drafts need not be perfect at this time,
what we need to agree in this call for adoption is whether they are
_good enough_ as _starting points_ for the task at hand.

IMO, they are.

regards

Carlos