Note: This ballot was opened for revision 06 and is now closed.
Substantive Comments: -2.2, 2nd to last paragraph: "Both the Validator Identifier and the Issuer ot Identifier used MUST be unique." At what scope must they be unique? Can you offer guidance on how to ensure uniqueness? -2.2, last paragraph: I don't understand what is meant by this paragraph. Please elaborate. -2.4, paragraph after definitions: "The OPTIONAL "lang" element MAY be present..." Why is this only a MAY? Is it really reasonable to leave out the language tag for non-English languages? -2.4, 3rd to last paragraph: Why does the custom status value exist if the server should not use it? Are there cases where a client uses it? -3.4, 2nd paragraph, first sentence: Is a client expected to know in advance whether the server supports launch applications? If so, how? Editorial Comments: - There are lowercase instances of 2119 keywords. I assume those are not meant as normative keywords. If so, please consider using the boilerplate from RFC 8174 instead of 2119. - General: I urge a pass to check the use of 2119/8174 keywords. I think there may be some instances where the author typed words in upper case from habit where the keywords don't make sense. I point out some of these below, but I suspect I did not get all of them. -1-1, 3rd paragraph: "REQUIRED" seems like a statement of fact. -2.2, first sentence: s/that/which -2.3, definitions: Please consider avoiding 2119 keywords in definitions? As written, they read more like statements of fact than normative requirements. (Please feel free to ignore this, since it is really a style issue.) Also, please try to add white space between hanging indent list entries. They are hard to read when run together. (Same for other definition sections.) -2.3, last paragraph: Please avoid 2119 keywords in examples. -2.3.1: The "MUST" and "MAY" seem like statements-of-fact. -2.4, 2nd to last paragraph: 2119 keywords in examples. -2.6.1, first paragraph: The "that" might should be a "which". But it's not clear to me whether the word is intended to constrain which codemark elements are being discussed ("that") , or to just mention that codemark elements are used in those models. ("which")
I wondered about the use of "launch" in the title and Abstract of this document, as possibly not easily parsable for some readers. I'm looking at It is typical for domain registries to operate in special modes during their initial launch to facilitate allocation of domain names, often according to special rules. This document uses the term "launch phase" and the shorter form "launch" to refer to such a period. and wondering if It is typical for domain registries to operate in special modes during their initial launch to facilitate allocation of domain names, s/during their initial launch/as they begin operation/ often according to special rules. This document uses the term "launch phase" and the shorter form "launch" to refer to such a period. might be correct, and easier for some folks to parse (especially since the first paragraph is basically saying 'This document uses "launch phase" and "launch" to refer to "launch"', which doesn't add as much as I hoped :-) If that makes sense, I'll leave you to decide whether a similar substitution might make sense in the Abstract, but do the right thing.
I agree with Scott Bradner's OpsDir review -- in Section 1.1 the use of the uppercase REQUIRED seems incorrect. In addition (nit), in Section 2.2. Validator Identifier "The Validator Identifier is the identifier, that is unique..." -- this comma seems incorrect. I have not validated the XML, and am relying on the DS / AD to have done so.
One nit (in security consideration section): OLD: "Updates to, and deletion of an application object must be restricted to clients authorized to perform the said operation on the object." MAYBE: "Updates to, and deletion of an application object MUST be restricted to clients authorized to perform the said operation on the object."
This is a well written document. I have several clarifying questions and comments that you should consider. 2.3. Launch Phases The server MAY support multiple launch phases sequentially or simultaneously. The <launch:phase> element MUST be included by the client to define the target launch phase of the command. The server SHOULD validate the phase and MAY validate the sub-phase of the <launch:phase> element against the active phase and OPTIONAL sub- phase of the server, and return an EPP error result code of 2306 if there is a mismatch. Is there a registry for codes like 2306? Either way, I couldn't figure out if this is a new code or already assigned one. 2.4. Status Values Each status value MAY be accompanied by a string of human-readable text that describes the rationale for the status applied to the object. The OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en" (English). You need to have a Normative Reference to Language Tags here (RFC 5646). Nit on page 19: Typo: identifer --> identifier Nit on page 47: <!-- Enumeration of for launch phase values. --> Drop "for"?
qualified by the previously assigned application identifier using the <launch:applicationID> element. Maybe I'm not following, but you say above that launch phase is FCFS, but then how do multiple applications work? not used or multiple Trademark Validators are used, the Validator Identifier MUST be defined using the "validatorID" attribute. Does this mean that you must use some validator? The following launch phase values are defined: Nit: you say that these are launch phase values but then below define things as non-launch phase. Claims Check Form Claims Check Form (Section 3.1.1) is used to determine whether or not there are any matching trademarks for a You seem to have duplication here. retrieving the claims information. Claims Create Form Claims Create Form (Section 3.3.2) is used to pass the Claims Notice acceptance information in a create command. And here. schema for the encoded signed mark that has an element that substitutes for the <smd:encodedSignedMark> element from [RFC7848]. I know that 7848 defines signedMark, but probably a good idea to say you have to validate it. C: xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0"> C: ... C: </smd:encodedSignedMark> I am assuming the base64 goes here. Could you indicate that a bit more clearly than ... somehow?