Last Call Review of draft-ietf-eppext-keyrelay-10
review-ietf-eppext-keyrelay-10-opsdir-lc-tsou-2015-12-12-00

Request Review of draft-ietf-eppext-keyrelay
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-12-15
Requested 2015-11-29
Authors Rik Ribbers, M. Groeneweg, R. Gieben, Antoin Verschuren
Draft last updated 2015-12-12
Completed reviews Genart Last Call review of -10 by Robert Sparks (diff)
Genart Telechat review of -11 by Robert Sparks (diff)
Opsdir Last Call review of -10 by Tina Tsou (diff)
Assignment Reviewer Tina Tsou
State Completed
Review review-ietf-eppext-keyrelay-10-opsdir-lc-tsou-2015-12-12
Reviewed rev. 10 (document currently at 12)
Review result Ready
Review completed: 2015-12-12

Review
review-ietf-eppext-keyrelay-10-opsdir-lc-tsou-2015-12-12

Dear all,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

I think this I-D is ready for publication. My comments:

**** Technical ****

* Section 8:
> 
> Any EPP client can use this mechanism to put data on the message 
> queue of another EPP client, allowing for the potential of a
> denial of service attack.  However this can, and SHOULD be detected
> by the server.  A server MAY set a server policy which limits or
> rejects a <keyrelay:create> command if it detects the mechanism is
> being abused.

I think you should provide more details regarding e.g. what would be the
conditions under which a server could infer that the mechanism is being
abused.


**** Editorial: ****

* Section 3.2.1, page 8:
Note that in the provided example the second <keyrelay:keyRelayData>
element has a period of zero and thus represents the revocation of a
previouly send key relay object (see Section 2.1.1).

s/send/sent/

* Section 5.1 and Section 5.2:
> conforming to a registry mechanism d

should you s/a/the/?


Thank you,
Tina