On Tue, Dec 5, 2017 at 1:34 PM, Gould, James <[email protected]> wrote:
> Eric, > > > > My replies are included below. > > > > — > > > > JG > > > [image: id:[email protected]] > > > *James Gould *Distinguished Engineer > [email protected] > > 703-948-3271 <(703)%20948-3271> > 12061 Bluemont Way > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *Eric Rescorla <[email protected]> > *Date: *Tuesday, December 5, 2017 at 4:02 PM > *To: *James Gould <[email protected]> > *Cc: *The IESG <[email protected]>, "[email protected]" < > [email protected]>, Ulrich Wisser <[email protected]>, > "[email protected]" <[email protected]>, "[email protected]" < > [email protected]> > *Subject: *[EXTERNAL] Re: Eric Rescorla's No Objection on > draft-ietf-regext-launchphase-06: (with COMMENT) > > > > > > > > On Tue, Dec 5, 2017 at 12:02 PM, Gould, James <[email protected]> wrote: > > Eric, > > > > Thanks again, I provide answers embedded below. > > > > — > > > > JG > > > > > > *James Gould *Distinguished Engineer > [email protected] > > 703-948-3271 <(703)%20948-3271> > 12061 Bluemont Way > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *Eric Rescorla <[email protected]> > *Date: *Monday, December 4, 2017 at 6:39 PM > *To: *James Gould <[email protected]> > *Cc: *The IESG <[email protected]>, "[email protected]" < > [email protected]>, Ulrich Wisser <[email protected]>, > "[email protected]" <[email protected]>, "[email protected]" < > [email protected]> > *Subject: *[EXTERNAL] Re: Eric Rescorla's No Objection on > draft-ietf-regext-launchphase-06: (with COMMENT) > > > > > > > > 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 > <https://maps.google.com/?q=12061+Bluemont+Way+%0D+Reston,+VA+20190&entry=gmail&source=g> > 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 elements associated with the “validatorID” attribute are related to > performing validation. The elements that support the “validatorID” > attribute include: > > > > 1. <launch:code> - The “validatorID” is used to identify the > Trademark Validator that code originated from. > > 2. <launch:claimKey> - The “validatorID” indicates the Trademark > Validator to query for the Claims Notice information. > > 3. <launch:noticeID> - The “validatorID” indicates which Trademark > Validator is the source of the claims notice. > > > > I'm not sure that this addresses the question I was asking. Namely, is it > necessary to provide some validation? > > > > The requirement for validation depends on the launch phases used by the > server and the models chosen by the server for those launch phases. The > protocol supports multiple launch phases and models that may include > validation. > How do you say in the protocol that no validation is wanted. > > > > > > > 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. > > " > > > > Yes, technically the “open” phase may not be considered as a launch phase, > but it is best to be included since it’s a common final state in launching > a TLD. > > > > Maybe modify the prefatory text? > > > > How about simply changing “A post-launch phase…” to be “A phase…”? There > is really no reason to define it as a post-launch phase, since it is a > launch phase that may be the final launch phase. > This LGTM. -Ekr > > > > > > > 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". > > > > You mean in section 2.6.3 “Digital Signature” to add the sentence “When > using digital signatures the server SHOULD validate the digital signature.” > to the end of the paragraph? The digital signatures apply to both the > <smd:signedMark>, <smd:encodedSignedMark>, and substitutes of both. > > > > Surely this is a MUST. > > > > Ok, I believe whether it’s a SHOULD or a MUST, it would need to go through > the working group. The proposal would then be to add the sentence “When > using digital signatures the server MUST validate the digital signature.” > to the end of the 2.6.3 “Digital Signature” paragraph. > > > > > > 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. > > > > How about adding the following sentence ‘The use of “…” is used as > shorthand for elements defined outside this document.’ to the “In > examples, …” paragraph of section 1.1 “Conventions Used in This Document”? > > > > LGTM. > > > > -Ekr > > > > > > > > > > > > > > >
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
