Skip to main content

Last Call Review of draft-ietf-eppext-keyrelay-10

Request Review of draft-ietf-eppext-keyrelay
Requested revision 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. (Miek) 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 (Ting ZOU) (diff)
Assignment Reviewer Tina Tsou (Ting ZOU)
State Completed
Review review-ietf-eppext-keyrelay-10-opsdir-lc-tsou-2015-12-12
Reviewed revision 10 (document currently at 12)
Result Ready
Completed 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

**** 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).


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

should you s/a/the/?

Thank you,