Skip to main content

Last Call Review of draft-ietf-regext-launchphase-06
review-ietf-regext-launchphase-06-opsdir-lc-bradner-2017-11-21-00

Request Review of draft-ietf-regext-launchphase
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-11-03
Requested 2017-10-20
Authors James Gould , Wil Tan , Gavin Brown
I-D last updated 2017-11-21
Completed reviews Opsdir Last Call review of -06 by Scott O. Bradner (diff)
Secdir Last Call review of -06 by Chris M. Lonvick (diff)
Genart Last Call review of -06 by Stewart Bryant (diff)
Artart Telechat review of -06 by Harald T. Alvestrand (diff)
Assignment Reviewer Scott O. Bradner
State Completed
Request Last Call review on draft-ietf-regext-launchphase by Ops Directorate Assigned
Reviewed revision 06 (document currently at 07)
Result Ready
Completed 2017-11-21
review-ietf-regext-launchphase-06-opsdir-lc-bradner-2017-11-21-00
This is an OPS-DIR review of Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)
(draft-ietf-regext-launchphase-06).

I reviewed this document as part of the OPS-DIR review process.

The document describes an extension to the Extensible Provisioning Protocol to support additional 
domain name registry operations.  I made the assumption that the proposal accurately describes
these operations since the operations themselves are rather specific to registry operations and 
I am not versed in the details of registry operations.This assumption is further supported by the
fact that actual registries have implemented the protocol.  That said, the protocol is impressively 
arcane.

Since the protocol is only used between consenting adults it should not present any issues relating
to the operations of the network, and I found no such issues.

Also, since it is an extension of an existing protocol and simply (so to speak) defines additional
message exchanges it should not present any issues of operating the systems themselves beyond 
those presented by the existing protocol.

so, I see no operations issues related to the protocol extensions described by this document.

two minor notes - 
section 1.1 says:
   In examples, "C:" represents lines sent by a protocol client and "S:"
   represents lines returned by a protocol server.  Indentation and
   white space in examples are provided only to illustrate element
   relationships and are not a REQUIRED feature of this protocol.

this, to me, seems not to be a good use of the 2119 upper case key words, I’d
suggest using lower case instead (not a big deal either way but the use struck
me as “wrong”)

section 2.5.2 says that digital signatures MAY be used - in general, without knowing
the details of the operations, it would seem to me to be a good idea to ensure integrity 
thus I wonder why the use of digital signatures is not a stronger mandate since
such digital signatures is supported.

Scott