Skip to main content

JSON Responses for the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-json-response-14

Yes

(Pete Resnick)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)

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

Pete Resnick Former IESG member
Yes
Yes (for -10) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2014-12-24 for -13) Unknown
Thanks for addressing my discuss and comment points.
Barry Leiba Former IESG member
No Objection
No Objection (2014-10-28 for -11) Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Kathleen Moriarty Former IESG member
(was Discuss) No Objection
No Objection (2014-11-25 for -12) Unknown
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 Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -11) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2014-10-30 for -11) Unknown
- 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.
Ted Lemon Former IESG member
No Objection
No Objection (2014-10-29 for -11) Unknown
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.