Skip to main content

Last Call Review of draft-ietf-weirds-rdap-sec-09

Request Review of draft-ietf-weirds-rdap-sec
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-10-24
Requested 2014-10-16
Authors Scott Hollenbeck , Ning Kong
I-D last updated 2014-10-20
Completed reviews Genart Last Call review of -04 by Kathleen Moriarty (diff)
Genart Last Call review of -09 by Christer Holmberg (diff)
Genart Last Call review of -10 by Christer Holmberg (diff)
Opsdir Last Call review of -09 by Al Morton (diff)
Assignment Reviewer Christer Holmberg
State Completed
Review review-ietf-weirds-rdap-sec-09-genart-lc-holmberg-2014-10-20
Reviewed revision 09 (document currently at 12)
Result Ready w/nits
Completed 2014-10-20

(Re-send with correct subject)

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at <>



Reviewer:                           Christer Holmberg

Review Date:

19 October



IETF LC End Date:             2




IETF Telechat Date:

30 October 2014


  I have found a number of issues. They are of editorial nature, but makes it
  difficult to understand the mechanism. I ask the authors to look at those,
  and consider if/how they can be addressed.

Major Issues: None

Minor Issues: None


In the Introduction, you say that one of the goal of RDAP is to provide
security services, that do not exist in WHOIS.

However, in section 3 you then say that RDAP doesn’t provide any of these
security services, but relies on other protocols.

First, I think you need to re-formulate the text in the Introduction, and talk
about how other protocols can be used to provide security services for RDAP.

Second, there is no text on why “other protocols” couldn’t be used to provide
security services for WHOIS. I think you need to

say that, if you want to claim that RDAP provides better security than WHOIS.


              In some places you say that additional/alternative mechanisms may
              be defined in the future. I think it would be good to in

the Introduction indicate that additional/alternative mechanisms can be added
in the future.


              You start some subsections by describing what WHOIS does/doesn’t
              do. I think you should first describe of

the specific security service is provided for RDAP, and then later describe
e.g. why the same cannot be provided



              Section 3.1.1. says: “Federated authentication mechanisms used by
              RDAP are OPTIONAL.”

              That statement is confusing. Does it mean that everything else in
              the document is mandatory to support?


              The name of section 3.3 is “Availability”. I don’t see how that
              is a security service, and the text mostly talks about

throttling. Would it be more appropriate to say “Request throttling” instead?


              Section 3.4 says:

              “Web services such as RDAP commonly use HTTP Over TLS [RFC2818]
              to provide that protection by encrypting all

              traffic sent on the connection between client and server.”

              To me that sounds like something from a BCP document. I think you
              should say that the document defines

the usage of HTTP over TLS for providing the security service.

Editorial nits: None