On Mon, Dec 4, 2017 at 3:03 PM, Gould, James <[email protected]> wrote:
> 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. > OK. Thanks. 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. > So, what if I don't want to validate at all. 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? > " open A post-launch phase that is also referred to as "steady state". Servers MAY require additional trademark protection during this 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. > I mean "validate the signature". 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. > OK. I just don't think that "..." is very clear, so I was hoping for some text or something else to show what goes here.
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
