Harald, Thank you for your review and feedback, below are my answers to your feedback. — JG James Gould Distinguished Engineer jgould@xxxxxxxxxxxx 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 12/6/17, 9:07 AM, "Harald Alvestrand" <harald@xxxxxxxxxxxxx> wrote: Reviewer: Harald Alvestrand Review result: Ready with Issues Review of draft-ietf-regext-launchphase-06 Summary: I suppose this is ready for the editing pass. Apologies for not completing it before the telechat. The document does not do a very good job of describing the overall flow of the context in which it is going to be used; for example, it is relatively late in the document that I discovered that claim notices have expiration dates (launch:notAfter in section 3.3.2). The document needs a thorough language check, in particular I reacted negatively to its rather sparse use of commas, which in several cases left sentences looking ambiguous to me. However, the implementation section indicates that this is work that is really waiting for formal approval, and I see no strong reason to delay the document further. Nits and grammar points ======================= Section 1.1 The definitions "launch-1.0", "signedMark-1.0" and "mark-1.0" are not in fact used. The paragraphs should be rephrased as "The XML namespace prefix "smd" is used for the "urn:ietf:params:xml:ns:signedMark-1.0" namespace. Implementations MUST NOT ....." Yes, you are correct the “launch-1.0”, “signedMark-1.0”, and the “signedMark-1.0” abbreviations are not used. I agree with your proposal to modify each of those paragraphs to read: “The XML namespace prefix <prefix> is used for the <namespace> namespace, but implementations…” for the three <prefix> values (“launch”, “smd”, and “mark”) and three <namespace> values (“urn:ietf:params:xml:ns:launch-1.0”, “urn:ietf:params:xml:ns:signedMark-1.0”, and “urn:ietf:params:xml:ns:mark-1.0”), respectively. 2.2 Grammatical: ", that is unique to the server," is ungrammatical. Just ", unique to the server," would be correct and clearer. Agreed, that is better. 2.3.1 Format: "Claims Check Form" and "Claims Create Form" repeats their hang text in the paragraph. This is confusing to read in ASCII. Yes, that is consistent feedback to Eric Rescoria’s feedback. This can be taken care of. 2.4 This sentence: "if a launch status is supported and the launch status is not one of the final statuses, including the "allocated" and "rejected" statuses." makes equal grammatical sense if "allocated" and "rejected" are final statuses or non-final statuses. Could be clearer. Would the use of parenthesis work better as in the sentence below? “if a launch status is supported and the launch status is not one of the final statuses ("allocated" and "rejected").” The two sentences starting "Is a possible end state" would be more grammatical if they were "This is a possible end state". Yes, that is better. It is not clear what causes the transition from "validated" to "pendingAllocation". It is also not clear if a transition possibility exists straight from "validated" to "allocated" for the case where no external process is needed. The transitions between the statuses is up to the server policy. There is no pre-defined timeframe that a domain must remain in a status. In general, the processing is done asynchronously and based on a batch schedule, where a batch may validate thus putting the domains in the “validated” status. A separate batch may prepare the domains for the allocation process thus putting the domains in the “pendingAllocation” status. Finally, a batch will allocate the domains thus putting the domains in either the “allocated” or the “rejected” status. Yes, there can be a server policy that supports moving domains to the “validated” or “invalid” status in one step and then deciding on the allocation in a separate step synchronously. In this case, there is no need for the “pendingAllocation” status. One scenario is that a pendingValidation domain may skip the validated status and transition immediately to the pendingAllocation status, or 2.5 "A Launch Application MUST and a Launch Registration MAY" would be clearer if there were commas around "and a Launch Registration MAY". How about trying to fix the sentence overall, with the following two sentences? “A Launch Application MUST be handled as an EPP domain name object, as specified in RFC 5731 [RFC5731], with the "pendingCreate" status and with the launch status values defined in Section 2.4. A Launch Registration MAY be handled as an EPP domain name object, as specified in RFC 5731 [RFC5731], with the "pendingCreate" status and with the launch status values defined in Section 2.4.” 2.6.3 This section's sentence structure is unclear due to a missing comma before "or the <smd:encodedSignedMark>". I believe the fix here is to remove “either” and the comma from the sentence as in: “Digital signatures MAY be used by the server to validate the mark information when using the "signed mark" validation model with the <smd:signedMark> (Section 2.6.3.1) element or the <smd:encodedSignedMark> (Section 2.6.3.2) element.” Do you agree that this is better? 3.1 It is completely unclear what functional difference there is between the "Claims Check Form" (3.1.1) and the "Trademark Check Form" (3.1.3). I suspect the idea behind "whether or not there are any matching trademarks, in the specified launch phase, for each domain name passed in the command, that requires the use of the "Claims Create Form" on a Domain Create Command." (3.1.1) versus "whether or not there are any matching trademarks for each domain name passed in the command, independent of the active launch phase of the server and whether the "Claims Create Form" is required on a Domain Create Command." (3.1.3) is that the latter will return claims info in cases where the former would not, but it's not clear when this makes a difference to the caller - the same reply info seems to be returned in both cases. Another interpretation is that there exist trademarks that match in a given phase and do not match outside that phase, so that the "claims check form" may return matches that "trademark check form" would not - this seems a bit bizarre. The Trademark Check Form was explicitly requested on the list to support checking for the existence of trademarks independent of the active or specified phase and without requiring an indication that a claims notice is required on a domain create. The primary purpose of a check is to indicate to the client whether a create will work, which is the goal of the Claims Check Form. Depending on the phase, the Claims Check Form may not return the claims information because the create does not require it. However, the Trademark Check Form will always return the claims information if there is at least one trademark associated with the domain name. This is a subtle difference, but an important difference since some systems require providing the raw trademark information without including the extra phase-specific logic of the Claims Check Form.