Subject: [weirds] I-D Action: draft-ietf-weirds-json-response-01.txt

From: [email-masked]
Date: Mon, 03 Dec 2012 07:10:41 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Extensible Internet Registration Data Service Working Group of the IETF.

	Title           : JSON Responses for the Registration Data Access Protocol (RDAP)
	Author(s)       : Andrew Lee Newton
                          Scott Hollenbeck
	Filename        : draft-ietf-weirds-json-response-01.txt
	Pages           : 50
	Date            : 2012-12-03

Abstract:
   This document describes JSON data structures representing
   registration information maintained by Regional Internet Registries
   (RIRs) and Domain Name Registries (DNRs).  These data structures are
   used to form Registration Data Access Protocol (RDAP) query
   responses.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-weirds-json-response

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-weirds-json-response-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-weirds-json-response-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Edward Lewis <[email-masked]>
Date: Mon, 3 Dec 2012 12:34:53 -0500

Comments on:
> 	Filename        : draft-ietf-weirds-json-response-01.txt

Item #1

Middle of second paragraph, Introduction:

Where overlap exists between RIR and DNR response object classes, the
RIR object classes are a proper subset of the DNR object classes.

This reads funny.  "Where overlap exists" implies that there are items that don't overlap, hence one set is not a proper subset of the other when you cosider all of the RIR object classes.

(LIke saying "of the positive integers from -10 to 10, those are a proper subset of the integers from 1 to 20.")

I get that for a domain name registry like .int won't have IP address range objects, it's just that the wording is quite, well, funny.

Item #2

Last paragraph of the Introduction:

Object classes defined in this document do not represent the full
range of data that any registry may wish to publish.  Section 4.2
defines a JSON extension mechanism that maybe used by registries to
insert registry specific data values.

The heuristic in me is that "statements ought to be positive with exceptions being negative."

I think what should be here is this:

Object classes defined in the document represent a minimal set of what a compliant client/server MUST understand to function correctly, however some deployments may want to include additional object classes to suit individual needs.  Anticipating this need for extension, Section 4.2 of this document defines a mechanism for extending the JSON (objects) that are described in this document.

Adjust as necessary.  Or why am I reading this wrong?

Item #3

One of my pet peeves is that there are too many ways (in WhoIs) to call a specific value.  In the definition of 'handle' the situation is exemplified.

   'handle':   D...The data type names 'registryId', 'roid',
      'nic-handle', 'registrationNo', etc... are terms often synonymous
      with this data type.  In this document, the term 'handle' is used.
      The term exposed to users by clients is a presentation issue
      beyond the scope of this document.

I included that because the text handles the problem I have neatly but leaves me one open question.

Will the term "handle" be the one used in-band, consistently, throughout the protocol.  I am fine with the presentation to the view changing to what ever string is desired (registryID, roid, etc.) but "on the wire" between server and client, I hope that the string is fixed to "handle" (or any single value).

Not a comment, a question...will handle be consistently used?

Item #4 

This is just a point, not an action item for the editors.

In section 9.2, variants...this could just as easily be used by RIRs to tie together all the /24's (say) for a address range (like a /20).

Item #5

This is a question, I don't have a specific place to tag this to the document.

For a domain name or IP address domain name, what if I wanted to designate an abuse contact, as opposed to a registrant contact?

The document does have 'entities' like this:

     "entities" :
     [
       ...
     ]

but I don't see how to tag one as the abuse contact.

Along these lines, I'd like to be able to easily (meaning via parser), give an IP address and get back the abuse contact.  Is that a reasonable goal?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: Andy Newton <[email-masked]>
Date: Mon, 3 Dec 2012 18:11:59 +0000

Ed,

Replies inline...

From:  Edward Lewis <[email-masked]>
>This reads funny.  "Where overlap exists" implies that there are items
>that don't overlap, hence one set is not a proper subset of the other
>when you cosider all of the RIR object classes.
>
>I get that for a domain name registry like .int won't have IP address
>range objects, it's just that the wording is quite, well, funny.

What can I say? I'm a funny guy!

I'll work on the wording so it is less confusing.

><http://tools.ietf.org/html/draft-ietf-weirds-json-response-01#section-4.2
>>
>Object classes defined in the document represent a minimal set of what a
>compliant client/server MUST understand to function correctly, however
>some deployments may want to include additional object classes to suit
>individual needs.  Anticipating this
> need for extension, Section 4.2 of this document defines a mechanism for
>extending the JSON (objects) that are described in this document.
>

I like that wording. Thanks!

>
>Item #3
>
>One of my pet peeves is that there are too many ways (in WhoIs) to call a
>specific value.  In the definition of 'handle' the situation is
>exemplified.
>
>Will the term "handle" be the one used in-band, consistently, throughout
>the protocol.  I am fine with the presentation to the view changing to
>what ever string is desired (registryID, roid, etc.) but "on the wire"
>between server and client, I hope that
> the string is fixed to "handle" (or any single value).
>

I've tried to make the protocol be consistent with "handle". If you find a
place where it is not, let me know. So yes, the intent is to be consistent.

>In section 9.2, variants...this could just as easily be used by RIRs to
>tie together all the /24's (say) for a address range (like a /20).

The could be, but that seems like overloading the structure. Variants are
intended for IDNs. Repurposing them for reverse DNS boundary collections
seems wrong. And clients would have to know to treat variants for reverse
DNS differently than for forward DNS based on the TLD. I'm getting a bad
smell from that. I'd prefer a separate structure. Also, I'm not sure of
the use case in general.

>For a domain name or IP address domain name, what if I wanted to
>designate an abuse contact, as opposed to a registrant contact?
>

Each entity object has a "roles" array of strings. That signifies the
relationship for the entity to the containing object. "abuse" is listed in
Appendix A.2, so putting "abuse" in the "roles" array would do what you
are after.

>
>Along these lines, I'd like to be able to easily (meaning via parser),
>give an IP address and get back the abuse contact.  Is that a reasonable
>goal?

Yes, that is a reasonable goal.

Issue a query for http://example.com/ip/192.0.2.0

In the result, look at each entity object in the "entities" array. The
abuse contacts are any entity object that has "abuse" listed in its
"roles" array.

-andy