Re: [regext] Eric Rescorla's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Mon, Dec 11, 2017 at 3:17 PM, Gould, James <[e-mail]> wrote:

> Eric,
>
>
>
> In reviewing the threads, I noticed that I missed your open question “How
> do you say in the protocol that no validation is wanted.”
>
>
>
> I’ll lead with restating that the requirement for validation depends on
> the launch phases used by the server and the models chosen by the server
> for those launch phases, which is referred to as server policy.  The launch
> phases and models chosen by the server is currently not defined by the
> protocol and currently needs to be communicated out-of-band.  The WG is
> going to discuss a framework (Registry Mapping and Registry Policy
> Extensions) to communicate the server policies in-band to EPP that should
> include a policy extension for draft-ietf-regext-launchphase (e.g.,
> draft-ietf-regext-launchphase-policy).  The short answer is that the
> protocol may say that no validation is wanted in the future but outside of
> draft-ietf-regext-launchphase.
>
>
OK. Do you think you could add some text saying that validation is
currently required. It confused me.

-Ekr


>
>
Thanks,
>
>
>
> —
>
>
>
> JG
>
>
> [image: id:[e-mail]933A30]
>
>
> *James Gould *Distinguished Engineer
> [e-mail]
>
> 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 <[e-mail]>
> *Date: *Tuesday, December 5, 2017 at 4:40 PM
> *To: *James Gould <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, Ulrich Wisser <[e-mail]>,
> "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *[EXTERNAL] Re: Eric Rescorla's No Objection on
> draft-ietf-regext-launchphase-06: (with COMMENT)
>
>
>
>
>
>
>
> On Tue, Dec 5, 2017 at 1:34 PM, Gould, James <[e-mail]> wrote:
>
> Eric,
>
>
>
> My replies are included below.
>
>
>
> —
>
>
>
> JG
>
>
>
>
>
> *James Gould *Distinguished Engineer
> [e-mail]
>
> 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 <[e-mail]>
> *Date: *Tuesday, December 5, 2017 at 4:02 PM
> *To: *James Gould <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, Ulrich Wisser <[e-mail]>,
> "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *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 <[e-mail]> wrote:
>
> Eric,
>
>
>
> Thanks again, I provide answers embedded below.
>
>
>
> —
>
>
>
> JG
>
>
>
>
>
> *James Gould *Distinguished Engineer
> [e-mail]
>
> 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 <[e-mail]>
> *Date: *Monday, December 4, 2017 at 6:39 PM
> *To: *James Gould <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, Ulrich Wisser <[e-mail]>,
> "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *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 <[e-mail]> wrote:
>
> Eric,
>
> Thank you for the review.  Below are my answers to your feedback.
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> [e-mail]
>
> 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" <[e-mail]> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>