Finding the Authoritative Registration Data (RDAP) Service
RFC 7484

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

(Jari Arkko) (was Discuss) Yes

Comment (2014-10-30 for -10)
No email
send info
Discuss cleared in favour of Barry's Discuss which covers the same thing.

A few other comments:

Everyone should be aware though that we are creating a live database that would be queried by software, not by implementors. 

Anyway, I think that is fine.

Suresh Krishnan had this comment in his Gen-ART review:

* Sections 5.2 and 5.3

-> The document uses some non-documentation addresses (AFAIK) in some of 
the examples. e.g. 28.2.0.0/16 for an IPv4 prefix and 2600::/16 for an 
IPv6 prefix. Is it possible to rewrite these examples using reserved 
documentation addresses? Strangely enough, idnits does not seem to catch 
them either.

(Ted Lemon) Yes

Comment (2014-10-29 for -10)
No email
send info
I support Barry's DISCUSS, but I think this is a good idea in principle.

(Pete Resnick) Yes

(Alia Atlas) No Objection

(Richard Barnes) No Objection

Comment (2014-10-29 for -10)
No email
send info
I'm a little unclear as to why this document is necessary.  It seems like given the use of 30X redirects in -using-http, you could just start with an IANA root server and redirect your way down the tree.  It may appear that this bootstrap mechanism saves queries to the root, but you could achieve the same effect or better using 301 redirects with appropriate caching.

The use of JSON in this syntax is slightly disappointing.  Generally, using JSON arrays to contain items of different types is not a great idea.  It seems like the "services" entries should actually be objects, with entries indicating the semantics of the inner arrays, e.g.:

OLD: [ ["1.0.0.0/8", "192.0.0.0/8"], ["https://rir1.example.com/myrdap/"] ]
NEW: { "resources": ["1.0.0.0/8", "192.0.0.0/8"], "urls": ["https://rir1.example.com/myrdap/"] }

This should not be hard to describe in the notation of Section 10.2, and it only uses a few more bytes on the wire.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-10-30 for -10)
No email
send info
- p4, where does it say what time is the publication time?  Is
it when the record is created/sent to IANA or when IANA get it
or what? 

- section 9, 1st para: I'm not clear what cache expiry
expectations we're setting here for IANA and dislike that that
is essentially a form of dynamic data intended to be related to
registry content that I don't believe IANA has previously been
asked to serve up. I think that's a bad plan.

- section 11 - this ought call for TLS as a MUST

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2014-12-18)
No email
send info
Version -11 addresses all my comments; many thanks for working that stuff out with me.

(Kathleen Moriarty) No Objection

Comment (2014-10-29 for -10)
No email
send info
This draft looks fine and adds the appropriate set of security considerations for what it does, however, shouldn't there be a reference to the draft-ietf-weirds-rdap-sec draft to say where everything else should be covered?

Thanks

(Martin Stiemerling) No Objection