Adam, Thank you for the review and feedback. I provide a response to your feedback embedded below with a “JG – “ prefix. I can post draft-ietf-regext-launchphase-06 once there is agreement to the set of changes.
Thanks, — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/25/17, 11:18 PM, "Adam Roach" <a...@nostrum.com> wrote: 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. JG – Section 2.3.1 “Trademark Claims Phase” was added in draft-ietf-regext-launchphase-02 to remove the reference to draft-ietf-regext-tmch-func-spec and briefly describe the trademark claims phase. Please indicate any information from draft-ietf-regext-tmch-func-spec that would help provide clarity without having to add the reference back to draft-ietf-regext-tmch-func-spec. 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). JG-An attempt was made to differentiate a Launch Application from a Launch Registration in the Introduction with “…registries often accept multiple application for the same domain name during the “Sunrise” launch phase, referred to as a Launch Application. A Launch Registration refers to a registration made during a launch phase when the server uses a first-come, first-served model”. A more formal definition can be added to section 1.1 for a Launch Application and a Launch Registration to clarify it further. How about the following definitions? “A Launch Registration is a domain name registration during a launch phase when the server uses a "first-come, first-served" model. Only a single registration for a domain name can exist in the server at a time.” “A Launch Application represents the intent to register a domain name during a launch phase when the server accepts multiple applications for a domain name and the server later selects one of the applications to allocate as a registration. Many Launch Applications for a domain can exist in the server at a time.” 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. JG-The uniqueness of the “validatorID” is associated within a specific server (registry), so it is enforced by the servers (registries) that accept them. For example, if a registry supports the default “tmch” Validator Identifier, it could define the requirement for another validator to be used, where the registry would enforce that the validator identifier of the additional validator is unique. The server policy would define the accepted set of validators and their associated validator identifiers. I added some additional language to section 2.2 like “The Validator Identifier is the identifier, that is unique to the server, for …” and “The unique set of Validator Identifier values supported by the server is up to server policy”. Do you agree with this update? 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. JG-With both the “No” and “Yes” branch from the “Does Domain have Claims?” decision node, the Domain Claims Check Response is returned. The Domain Claims Check Response will include a Boolean value of indicating whether claims (trademarks) exist and a claims key if a claims (trademarks) do exist. Maybe to clarify this, the label for the “No” branch can be set to “Claims Don’t Exist” and the “Yes” branch label can be changed from “Claims Key” to “Claims Exist with Claims Keys”. Do you believe that is better? 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. JG-Done 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. JG-The method for providing more than one <launch:codeMark>, <smd:signedMark> or <smd:encodedSignedMark> is better described in section 3.3.1 “Sunrise Create Form”. The last paragraph may just add confusion, so my recommendation is to remove it. The number of code, marks, and signed marks supported is up to server policy and the best mechanism to communicate that policy in a separate server policy object extension. This is similar to the discussion around communicating the schedule of launch phases. You can find an example object extension (Registry Mapping) for the purpose of communicating the zones (TLDs) available to the client and the features and policies supported by the server at https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html. Such a policy object extension can be extended (Launch Phase Policy Extension or Registry Fee Policy Extension) to define the policies of extensions like the Launch Phase extension and the Registry Fee Extension. A command-response extension like the Launch Phase Extension does not provide the framework to support defining server policy. Let me know whether removing the last paragraph of section 2.6 makes sense and whether additional language needs to be added to section 3.3.1 for clarification. 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. JG –I assume that you’re referring to the description of the <launch:phase> element in section 3.1.1. The <launch:phase> element is used across multiple commands, so it may be best to update the expected validation behavior centrally in section 2.3 “Launch Phases”. There is already a description of the validation in the first paragraph of section 2.3, where a 2306 EPP error result code is returned. How about updating the first paragraph of section 2.3 to be more generic by not just applying to a create command and using a MUST for returning the 2306 EPP result code if there is a mismatch? Then update any references to the <launch:phase> element in the commands to state “The server SHOULD validate the value according to section 2.3.“ when comparing against the active launch phases. Some of the commands like Check Command using the Availability Check Form, the Info Command, the Update Command, and the Delete Command refer to future or past phases, so I explicitly added the text “The server SHOULD validate the value and return an EPP error result code of 2306 if it is invalid.”. Do you agree with these updates? 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. JG-The reason why is that the Trademark Check Form defines a new command called the Trademark Check Command. Its purpose is separate and distinct from an available check, where the Trademark Check Command is answering the question of whether there is a trademark associated with the domain name independent on the active launch phase and independent on the availability of the domain name. The language exists for the Claims Check Form in creating a Claims Check Command. As you’ll notice in both cases (Trademark Check Command and Claims Check Command), the response does not include the <domain:chkData> which greatly simplifies the response. The language matches the XML schema definition and the examples. The Availability Check Form in section 3.1.2 does not define a new command and appropriately mixes the domain check command with launch phase logic. I’m not sure whether additional language is needed to describe why mixing commands with different purposes is not allowed, but I’m open to providing it if needed. 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..." JG-Done 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. JG – I updated it to read “Zero or more <mark:mark> (Section 2.6.2.) elements only if the “includeMark” attribute is “true” in the command.” Do you agree with this update? 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. JG-I modified it to “The server SHOULD validate the "type" attribute, when passed, against the type of object that will be created, and return an EPP error result code of 2306 if the type is incorrect.” Do you agree with this update? 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. JG-The approach supported by the server is defined by registry policy. The launch phase extension provides the interface to support the various launch phases and registry policies, and the policies are either defined out-of-band of EPP or in an EPP extension designed for that purpose like the Registry Mapping ( https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html ). 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. JG- In section 2.6 “Mark Validation Models”, it states “The mark information is passed without any other validation element. The server will use some custom form of validation to validate that the mark information is authentic.” The launch phase extension simply enables the passing of the mark without dictating the method that the server validates it (validate directly, validate via API or data feed from an external validator, etc.). Do you want to add something like this in section 7? Section 3.3.2: Same question about type validation as for Section 3.3.1, above. JG-I added “, and return an EPP error result code of 2306 if the type is incorrect” to the end of the sentence like 3.3.1. Do you agree with this update? Section 3.3.3: Same question about phase validation as for section 3.1, above. JG-I added “, and return an EPP error result code of 2306 if the type is incorrect” to the end of the sentence like 3.3.1. Do you agree with this update? 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. JG-The approach supported by the server is defined by registry policy. The launch phase extension provides the interface to support the various launch phases and registry policies, and the policies are either defined out-of-band of EPP or in an EPP extension designed for that purpose like the Registry Mapping ( https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html ). 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>..." JG-Done 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 <. JG-Done, this had to be changed to just use “. Section 5.1: Please set the registrant information to the IESG. JG-Done Section 7: The first paragraph appears to start with an extraneous "As". JG-I believe you meant the last paragraph. I changed “As information” to “Information” to start the last paragraph of section 7. Thanks! /a _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
