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 > 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 " (and want the > to be ") or you mean <.
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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
