JSON Responses for the Registration Data Access Protocol (RDAP)
RFC 7483

Note: This ballot was opened for revision 10 and is now closed.

(Pete Resnick) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) No Objection

Alissa Cooper (was Discuss) No Objection

Comment (2014-12-24 for -13)
No email
send info
Thanks for addressing my discuss and comment points.

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-10-30 for -11)
No email
send info
- I support Alissa's discuss point that jCard is too rich a
syntax and the specific jCard members intended to be used here
ought be specified and the spec should say to not use others.
The example on p18, with gender, dob, and other privacy
sensitive fields should be adjusted to not include such.

- I think it would have been a fine thing had the WG decided to
do a more comprehensive privacy analysis of RDAP but I don't
see that in this document set at least. I do like Kathleen's
suggested text better than that currently in the privacy
considerations section though.

- Figure numbers are used inconsisently, some examples have
them and, for no apparent reason, some don't. That needs
fixing. There's also a lack of clarity about the specification
style here - you need to be clearer as to what is just and
example and what is not.

- p21, the list following the example contains items that were
not in the example - this is unclear writing. Are you saying
that the list is normative or not? If so, you need to say so.
If not, why go beyond the example? The same point applies to
the lots of other examples that follow.

- 10.2.X: there's a lot of stuff here that wasn't described. I
wouldn't be surprised if that causes interop problems.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-10-28 for -11)
No email
send info
In section 9 it might be worth saying a few more words about how responses can be truncated.  Until I saw the example, I was thinking that the JSON itself might be incomplete.  The example made me realise that you're talking about limiting what is returned, not actually truncating what used to be a complete response.  I'm OK with referring to it as "truncated", but I'd like to see just a little explanation of the situations you're talking about, so it's clear you don't just mean snipping it in the middle.

(Ted Lemon) No Objection

Comment (2014-10-29 for -11)
No email
send info
Point 1:

In 4.3:
   It is the job of the clients to determine line breaks, spacing and
   display issues for sentences within the character strings of the
   "description" array.  Each string in the "description" array contains
   a single complete division of human readable text indicating to
   clients where there are semantic breaks.

What do you mean by "semantic breaks"?   Paragraph breaks?   Sentence breaks?   Dependent clause breaks?   This doesn't make sense.   I'm not going to raise a discuss on it because I don't think it affects interoperability, but I have no idea how to implement a client to display this in a way that will make sense to the user.

Point 2:

A general question that occurred to me in reading 5.5, which also applies to 5.4: should you have some text talking about how the link member of a network or autnum object is generated?  Both networks and autnum objects, as I understand it, can be gotten by querying any number in the range they enclose.   But of course the link member isn't going to enumerate all the possible queries that could return the particular object containing that link member.   So how is the value that's returned chosen?  Is it the lowest number in the range?   The number that was used in the query that returned the object?   Some other number?

I don't think you need to change anything, but it might be worth discussing this in sections 5.4 and 5.5.

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2014-11-25 for -12)
No email
send info
Thanks for adding suggested text to expand the privacy considerations section, this is very helpful.

Thanks for addressing the SecDir review and including information on a possible cache poisoning attack.
http://www.ietf.org/mail-archive/web/secdir/current/msg05183.html
Some nits were included as well that might be helpful.

(Martin Stiemerling) No Objection