Security Services for the Registration Data Access Protocol (RDAP)
RFC 7481

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

(Pete Resnick) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) No Objection

Comment (2014-10-30 for -10)
No email
send info
I support Alissa's comments about privacy.  It would be good to clarify those considerations and provide some good recommendations about what not to send.

(Benoît Claise) No Objection

(Alissa Cooper) (was Discuss) No Objection

Comment (2014-12-22)
No email
send info
Thanks for handling my discuss and comment points.

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-10-30 for -10)
No email
send info

- I strongly support Aliss's discuss on privacy. That would be
even more important should registrars/registries in future
require that personally identifying information be available
for all registrants, which I believe is a policy that at least
some are arguing for.

- Isn't it sad that HTTP basic and digest still have to be the
MTIs here for client auth. (I would suggest HOBA [1] but that's
not quite done, being just finished WGLC, and would be
self-serving, though it would be far better than basic or


- Why not just say "TLS MUST be used" in all cases? Is there a
real need to not use TLS for weirds ever?

- TLS client auth - I think you could easily make this MTI (to
implement, not to use) as its basically there in most

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

Comment (2014-10-28 for -10)
No email
send info
-- Section 3.1 --

   This section describes security authentication mechanisms and their
   need for implementation by authorization policies.

It took me a few readings to get what I think you mean.  I think you mean this:
   This section describes security authentication mechanisms and the
   need for authorization policies to include them.

(Ted Lemon) (was Discuss) No Objection

Comment (2014-10-30 for -10)
No email
send info
Barry has pointed out that there is a way to trigger the clients to send credentials using a login link, so that addresses my concern.   I didn't actually see that explicitly mentioned in the document, but Pete says it's there so I'll take his word for it.

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2014-11-25 for -11)
No email
send info
Thanks for your work on this and the other Weirds drafts and adding in my requested text on privacy options to the response draft (Alissa's in this draft) as well as addressing my other discuss points (TLS BCP, etc.).  The new sections are helpful to explain privacy and access control options (3.1) that have been added in this new protocol.

Section 3.1
As an FYI (not asking for anything to be done here except to participate in HTTPAuth last calls) - HTTP Digest and Basic just went through a revision and are just about done.  There are a few minor updates and the security considerations in the updated documents spell out the remaining issues.  Although these are the solutions for HTTP Auth, most people don't rely on it and use other methods, so we don't have implementations of better options.  There are a few other options in the HTTPAuth WG about to go to IETF last call or are WG drafts.  If you are going to rely on HTTPAuth methods, maybe there should be a push for the improved options from the WEIRDS WG - at least pitching in to review during last calls.

(Martin Stiemerling) No Objection