Ben, Thank you for the review. I include the responses to your feedback embedded below.
Thanks, — JG James Gould Distinguished Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/29/17, 12:30 PM, "Ben Campbell" <[email protected]> wrote: Ben Campbell has entered the following ballot position for draft-ietf-regext-launchphase-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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? The scope of uniqueness is at the server-level, where “tmch” is reserved. If a server supports additional validators, the “server MUST define the list of supported validator identifiers and MUST make this information available to clients using a mutually acceptable, out-of-band mechanism.” Hopefully, this answers you question. -2.2, last paragraph: I don't understand what is meant by this paragraph. Please elaborate. I assume that you’re referring to “The Validator Identifier MAY define a non-Trademark Validator that supports a form of claims.”. The concept of claims and a Validator Identifier is based on the use of a Trademark Validator, but it is understood that other forms for validators MAY develop that go beyond trademarks. -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? The use of the “lang” attribute is based on what has been done in RFC 5731 (normative). -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? The custom status value is defined to support corner cases and is not recommended using SHOULD NOT of RFC 2119? -3.4, 2nd paragraph, first sentence: Is a client expected to know in advance whether the server supports launch applications? If so, how? The client is expected to know based on either an out-of-band mechanism, or an in-band mechanism that is being discussed now within the REGEXT working group. 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. Thanks, this can be reviewed and cleaned up. -1-1, 3rd paragraph: "REQUIRED" seems like a statement of fact. This language is based on the EPP RFC 5730 (1.1) and RFC 5731 (1.2) language. -2.2, first sentence: s/that/which Thanks, I agree. -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.) Thanks, this can be looked at. -2.3, last paragraph: Please avoid 2119 keywords in examples. You are referring to the last sentence of 2.3 “For example, the <launch:phase> element SHOULD be <launch:phase name="landrush">claims</launch:phase>.”? I agree that SHOULD can be lowercase should here. -2.3.1: The "MUST" and "MAY" seem like statements-of-fact. You are referring to “The Trademark Claims Phase is when a Claims Notice MUST be displayed to a prospective registrant of a domain name that matches trademarks.”, where MUST can be lowercase must”, and “Claim Notice Information Service (CNIS), which MAY be directly linked to a Trademark Validator.”, where MAY can be lowercase may? I agree these are more descriptive than directional. -2.4, 2nd to last paragraph: 2119 keywords in examples. You are referring to “For example, an application or registration MAY immediately start at the "allocated" status or an application or registration MAY skip the "pendingAllocation" status.”?, where both MAYs can be lowercase mays? -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 believe “that” can be removed from “The <launch:codeMark> element that is used by the "code", "mark", and "code with mark" validation models, has the following child elements:”. _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
