Last Call Review of draft-ietf-weirds-rdap-sec-09
review-ietf-weirds-rdap-sec-09-opsdir-lc-morton-2014-10-16-00

Request Review of draft-ietf-weirds-rdap-sec
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-10-24
Requested 2014-10-12
Draft last updated 2014-10-16
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 Al Morton
State Completed
Review review-ietf-weirds-rdap-sec-09-opsdir-lc-morton-2014-10-16
Reviewed rev. 09 (document currently at 12)
Review result Ready
Review completed: 2014-10-16

Review
review-ietf-weirds-rdap-sec-09-opsdir-lc-morton-2014-10-16

resending to the correct address for ops-dir, sorry.
________________________________________
From: MORTON, ALFRED C (AL)
Sent: Monday, October 13, 2014 8:26 AM
To: draft-ietf-weirds-rdap-sec.all at tools.ietf.org
Cc: ops-dir at tools.ietf.org; ops-ads at tools.ietf.org
Subject: draft-ietf-weirds-rdap-sec-09

OPS-DIR review of draft-ietf-weirds-rdap-sec-09

OPS-DIR reviews are primarily for the ops-area directors.
Authors should treat this review as they would any
LAST CALL comments.

Summary: Ready, one suggestion below, also see SEC-DIR review
when available.

regards,
Al

One goal of RDAP is to provide security services that
do not exist in the WHOIS protocol.  RDAP itself
is described in multiple documents.
This document describes information security services for RDAP,
including authentication, authorization,
availability, data confidentiality, and data integrity.
It provides the requirements for selected security protocols
from among many choices.  Where multiple choices are allowed,
interoperability has been considered and addressed (sec 3.1).

However, the sentence at the end of 3.1:
   Work on HTTP authentication methods continues.  RDAP ought to be
   agile enough to support additional methods as they are defined.

cannot be a requirement, and it might be phrased more positively
as:
   Work on HTTP authentication methods continues. RDAP is designed to be
   agile enough to support additional methods as they are defined.
(assuming others agree this is true)

Although scalability is an operations issue, section 3.1.1
provides options to address this with the tools currently available,
and says:
   ...At the time of this document's publication,
   negotiation or advertisement of federated authentication services is
   still an undefined mechanism by the noted federated authentication
   protocols.  Developing this mechanism is beyond the scope of this
   document.

Sections 3.3 (Availability) and 3.4 (Data Confidentiality) and
3.5 (Data Integrity) have no requirements, referring to common
use of HTTP over TLS where appropriate.

As with any memo whose scope is security services,
the SEC-DIR review may also raise issues of interest
to the operations community.