Eric, Thank you for the review. Below are my answers to your feedback. — 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, 2:20 PM, "Eric Rescorla" <[email protected]> wrote: Eric Rescorla 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: ---------------------------------------------------------------------- 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? 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. 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 name can exist in the server at a time. The application identifier is used for Launch Applications to different between the multiple applications for the same domain name. 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 lack of the “validatorID” attribute or the reserved “tmch” “validatorID” value can be used to indicate that the ICANN TMCH is being used. A value other than empty or “tmch” is used to specify some custom validator. Any element that supports the “validatorID” is associated with a validator whether explicitly or implicitly. 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. I don’t see where the launch phase values define things as non-launch phase. Can you provide a reference to a 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. Thanks, that can be taken care of. 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. Thanks, that can be taken care of. 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. The information provided by the client for all elements can be validated using a namespace-aware XML parser. I don’t believe there is anything unique with the <smd:encodedSignedMark> to warrant extra validation language. 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? RFC 7848 can support other encodings other than “base64” using the “encoding” attribute, and a new encodedSignedMark type can be included by substituting for the <smd:encodedSignedMark> element. draft-ietf-regext-launchphase references RFC 7848 to support a concrete encodedSignedMark and provides the extensibility to define new encodedSignedMark’s. The “…” is used to allow for the definition of the encodedSignedMark to be defined in RFC 7848 or a new draft that substitutes for the <smd:encodedSignedMark> element. I believe that it’s best to reference RFC 7848 in this case. _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
