Subject: [regext] AD Review: draft-ietf-regext-launchphase-05

From: Adam Roach <[email-masked]>
Date: Tue, 25 Jul 2017 22:18:40 -0500

EPP Launchphase Authors --

This is my AD review of draft-ietf-regext-launchphase-05.

I have a number of questions and comments about the draft, although I 
freely admit that many of them may stem from a lack of knowledge on my 
part about the operational models in which EPP is deployed. Please bear 
with me on those points. Comments are in document order, and constitute 
a mix of substantive and minor editorial comments.

As a general comment, I believe the document could benefit from either 
some introductory text about how claims operate or a pointer to a 
document that explains how they operate. I skimmed the documents cited 
in the references section and couldn't easily locate information along 
these lines.

The introduction talks about "registrations" and "applications" without 
defining what these terms mean or citing a definition. As far as I can 
tell, EPP does not define these terms, and I'm having a hard time 
figuring out the difference. It's probably worth adding a few words in 
section 1.1 that talks about these terms (and, in particular, indicates 
that "application" in this context is very different from how that term 
is generally used in computer science).

Section 2.2 indicates that the Validator Identifier and Issuer 
Identifier must be unique; however, it's not clear how this uniqueness 
is enforced. Is there a registry somewhere? Are these derived from some 
previously allocated identifiers? Are UUIDs expected? Or is it expected 
that the community simply self-organizes to achieve this somehow? I 
think this document needs to clearly state how this uniqueness is 
expected to happen.

The sequence diagram in Figure 1 has an unlabeled response (to the left 
of "Does Domain have Claims?") -- this should  indicate what kind of 
information is being conveyed to the client.

The <launch:applicationID> and <launch:status> elements on page 13 are 
indented further than one would normally expect. The same goes for the 
<launch:status> element on page 14.

The final paragraph of section 2.6 indicates that multiple instances of 
certain elements MAY be supported by a server, without indicating how 
such support might be indicated or negotiated. Minimally, I'd expect to 
see a unique status code here that allows the client to determine that 
the server does not support such multiplicity, and that the lack of such 
support is why a message was rejected. Ideally, there would be some 
proactive indication of support before the message is sent, but I don't 
know enough about EPP to determine whether this is reasonable.

Section 3.1 has language indicating that the server "SHOULD validate the 
value against the active server launch phase." Minor comment: shouldn't 
this be "launch phase(s)"? More substantive comment: If such validation 
fails, the server presumably rejects the request? I'd like to see this 
stated explicitly, and to indicate which response code is used for such 
a rejection.

Section 3.1.3 indicates that availability MUST NOT be returned when a 
trademark check is performed. It's not clear why this restriction is in 
place, and it would seem to make scaling more difficult (as clients 
desiring both sets of information need to launch two requests). I'd like 
to see some explanation in the document why this restriction is desirable.

Section 3.2: "The Application Identifier (Section 2.1) returned in the 
<launch:creData> element of the create response (Section 3.3) is used 
for retrieving information for a Launch Application." This makes such 
use sound mandatory, which I don't think it is. Would rephrase as 
"...can be used for retrieving..."

Section 3.2: "<mark:mark>  Zero or more <mark:mark> (Section 2.6.2) 
elements" -- I would qualify this with "only if 'includeMark' is 
indicated in the client response" or something similar.

Section 3.3.1 says the server should validate the "type" attribute in 
the request. If such validation fails, the server presumably rejects the 
request? I'd like to see this stated explicitly, and to indicate which 
response code is used for such a rejection.

Section 3.3.1: How does a client know which of the four different 
approaches are supported by the server? Minimally, I'd expect to see a 
unique status code here that allows the client to determine that the 
model it has selected is not supported by the server, and that the lack 
of such support is why a message was rejected (preferably with some 
indication of which model *is* supported). Ideally, there would be some 
proactive indication of support before the message is sent, but I don't 
know enough about EPP to determine whether this is reasonable.

Page 31 contains an example that uses an unsigned <mark:mark> section 
containing Trademark information without any unique identification. How 
does this work? For example: who is allowed to claim what? This would 
seem to require some explanation and possibly some text in section 7.

Section 3.3.2: Same question about type validation as for Section 3.3.1, 
above.

Section 3.3.3: Same question about phase validation as for section 3.1, 
above.

Section 3.3.4: If the server does not support Mixed Create forms, how 
does the client determine this? Minimally, I'd expect to see a unique 
status code here that allows the client to determine that the server 
does not support this form, and that the lack of such support is why a 
message was rejected. Ideally, there would be some proactive indication 
of support before the message is sent, but I don't know enough about EPP 
to determine whether this is reasonable.

Section 3.3.5: It is easy to read "...MAY reply with..." as saying that 
a reply is optional. I don't get the impression that this is the 
intention, however; I suspect the intention is that the addition of a 
<launch:creData> to the (required) reply is optional. Suggest rephrasing 
along the lines of "...server MAY add a <launch:creData> element to the 
regular EPP <resData>..."

Page 46 contains literal &qt; and &gt; strings. Comment 1: shouldn't 
these just be < and > or quotes? Comment 2: If not, I'll point out that 
&qt; is not an XML escape sequence: you probably either mean &quot; (and 
want the &gt; to be &quot;) or you mean &lt;.

Section 5.1: Please set the registrant information to the IESG.

Section 7: The first paragraph appears to start with an extraneous "As".

Thanks!

/a