Finding the Authoritative Registration Data (RDAP) Service
draft-ietf-weirds-bootstrap-11
Yes
(Pete Resnick)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Alissa Cooper)
(Brian Haberman)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
Note: This ballot was opened for revision 10 and is now closed.
Jari Arkko Former IESG member
(was Discuss)
Yes
Yes
(2014-10-30 for -10)
Unknown
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.
Pete Resnick Former IESG member
Yes
Yes
(for -10)
Unknown
Ted Lemon Former IESG member
Yes
Yes
(2014-10-29 for -10)
Unknown
I support Barry's DISCUSS, but I think this is a good idea in principle.
Adrian Farrel Former IESG member
No Objection
No Objection
(for -10)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -10)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -10)
Unknown
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2014-12-18)
Unknown
Version -11 addresses all my comments; many thanks for working that stuff out with me.
Brian Haberman Former IESG member
No Objection
No Objection
(for -10)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -10)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-10-29 for -10)
Unknown
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 Former IESG member
No Objection
No Objection
(for -10)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(2014-10-29 for -10)
Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -10)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-10-30 for -10)
Unknown
- 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