Adam, My responses to your feedback is embedded below with a “JG-“ prefix. I highlight which items are addressed in the soon to be published draft-ietf-regext-launchphase-06.
Thanks, — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/18/17, 7:22 PM, "Adam Roach" <a...@nostrum.com> wrote: Sorry for taking a while to get back to this. Responses inline. On 8/2/17 1:40 PM, Gould, James wrote: > 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. I see that the reference in -01 was normative, and I assume it was removed to avoid any unnecessary dependencies. Is there any reason you couldn't add a statement in section 2.3.1 along the lines of "See [I-D.ietf-regext-launchphase] for additional details of trademark claims handling"? That would make it an informative reference, and wouldn't create a publication dependency. JG-Addressed in draft-ietf-regext-launchphase-06 with ‘Added an informative reference to draft-ietf-regext-tmch-func-spec in section 2.3.1 "Trademark Claims Phase". ‘. I don’t have an issue adding the reference back if it doesn’t create a dependency issue for publication. We did pull some information from draft-ietf-regext-tmch-func-spec into draft-ietf-regext-launchphase to remove the dependency. I assume that we keep the pulled in information and simply add the reference to draft-ietf-regext-tmch-func-spec back to the draft as an informative reference. > 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.” That would be great. Thanks. JG-Addressed in draft-ietf-regext-launchphase-06 with “Added formal definition of a Launch Registration and Launch Application to section 1.1.”. > 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? Ah, it was the scoping here that I didn't understand. Yes, that makes it clearer. JG-Addressed in draft-ietf-regext-launchphase-06 with “Updated the description of the Validator Identifier to indicate that the uniqueness is based on server policy.”. > > 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? Yes, thanks. JG-Addressed in draft-ietf-regext-launchphase-06 with ‘Updated "Does Domain have Claims?" "No" and "Yes" branch labels in Figure 1.’. > > 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. Your explanation makes sense, and I suspect this is one of the areas that falls into the lack of my knowledge around the operational models EPP is deployed in. If the use of these policy objects is generally well known by anyone who will be using EPP, then I think the existing text is fine. JG-No action for draft-ietf-regext-launchphase-06. > 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? Yes, those sound good. Thanks. JG- Addressed in draft-ietf-regext-launchphase-06 with “Updated the description of the <launch:phase> element in the commands to explicitly specify the return of a 2306 EPP error result when invalid or referring to section 2.3 for validation”. > 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. The simplicity argument makes sense to me. I'm happy if you elect not to add text here. JG-No action for draft-ietf-regext-launchphase-06. > > > 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? Sound good. Thanks. JG- Addressed in draft-ietf-regext-launchphase-06 with “Updated the description of the <mark:mark> element in the info response.”. > > 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? Sounds good. Thanks. JG- Addressed in draft-ietf-regext-launchphase-06 with “Added returning an EPP error result code of 2306 if the "type" attribute is incorrect in section 3.3.1, 3.3.2, and 3.3.3.” > 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 ). Thanks -- seems like the same question regarding allowed ordinality of elements, above. No change is needed. JG-No action for draft-ietf-regext-launchphase-06. > > > 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? No, I had simply missed the "custom form of validation." Given that this is effectively saying it's out of scope of this document, I'm not sure what section 7 could say other than "the custom forms of validation need to be secure," but that's so general as to be useless. JG-No action for draft-ietf-regext-launchphase-06. > 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? Sounds good. JG- Addressed in draft-ietf-regext-launchphase-06 with “Added returning an EPP error result code of 2306 if the "type" attribute is incorrect in section 3.3.1, 3.3.2, and 3.3.3.” > > 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? Sounds good. JG- Addressed in draft-ietf-regext-launchphase-06 with “Added returning an EPP error result code of 2306 if the "type" attribute is incorrect in section 3.3.1, 3.3.2, and 3.3.3.” > > 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 ). Thanks. No change is needed here. JG-No action for draft-ietf-regext-launchphase-06. Go ahead and submit a -06 version with your proposed changes, and I'll get into IETF last call. Thanks! /a _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
