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

["Gould, James" <[e-mail]>]

I have no problem with that modification, so the result is:

It is typical for domain registries to operate in special modes as they begin operation to facilitate allocation of domain names, often according to special rules. This document uses the term "launch phase" and the shorter form "launch" to refer to such a period.  Multiple launch phases and multiple models are supported to enable the launch of a domain name registry.  What is supported and what is validated is up to server policy.  Communication of the server policy is typically performed using an out-of-band mechanism that is not specified in this document.

—

JG

[id:[e-mail]933A30]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: "Hollenbeck, Scott" <[e-mail]>
Date: Tuesday, December 12, 2017 at 2:51 PM
To: James Gould <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: [EXTERNAL] Re: [regext] Eric Rescorla's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)

When I read “Communication of the server policy is defined outside this document” I ask myself “Where?”. It may be better to say something like “Communication of the server policy is typically performed using an out-of-band mechanism that is not specified in this document”.

Scott

From: regext [mailto:[e-mail]] On Behalf Of Gould, James
Sent: Tuesday, December 12, 2017 2:48 PM
To: Eric Rescorla <[e-mail]>
Cc: [e-mail]; [e-mail]; Ulrich Wisser <[e-mail]>; The IESG <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [regext] Eric Rescorla's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)

Eric,

Ok, how about adding a few sentences to the second paragraph of the Introduction:

It is typical for domain registries to operate in special modes as they begin operation to facilitate allocation of domain names, often according to special rules. This document uses the term "launch phase" and the shorter form "launch" to refer to such a period.  Multiple launch phases and multiple models are supported to enable the launch of a domain name registry.  What is supported and what is validated is up to server policy.  Communication of the server policy is defined outside this document.

Thoughts?

—

JG

[cid:image002.png@01D3735A.6A110EB0]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 12, 2017 at 2:25 PM
To: James Gould <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Ulrich Wisser <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: Eric Rescorla's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)

Is there a reason you can't say that in the document?

-Ekr


On Tue, Dec 12, 2017 at 11:19 AM, Gould, James <[e-mail]<mailto:[e-mail]>> wrote:
Eric,

The extension supports multiple launch phases and multiple models to enable the servers to support their TLD launches.  What is supported and what is validated is up to server policy, is currently communicated out-of-band, and can be included in a separate in-band policy extension (e.g., draft-ietf-regext-launchphase-policy) created for that purpose.

Thanks,

—

JG

[cid:image003.png@01D3735A.6A110EB0]

James Gould
Distinguished Engineer
[e-mail]<http://[e-mail]>

703-948-3271<tel:(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]<mailto:[e-mail]>>
Date: Tuesday, December 12, 2017 at 2:10 PM
To: James Gould <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Ulrich Wisser <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: Eric Rescorla's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)

OK, but there's no way to identify "no validation data" and that's confusing to the reader.

-Ekr


On Tue, Dec 12, 2017 at 9:14 AM, Gould, James <[e-mail]<mailto:[e-mail]>> wrote:
Eric,

>OK. Do you think you could add some text saying that validation is currently required. It confused me.

I believe attempting to add text saying that validation is required will add more confusion (who validates, what’s validated) and is out-of-scope for an extension that passes information between a client and server that may have been validated by a 3rd party.  The extension provides the capability of passing validated data but it does not require explicit validation to be performed.

Thanks,

—

JG

[cid:image004.png@01D3735A.6A110EB0]


James Gould
Distinguished Engineer
[e-mail]<http://[e-mail]>

703-948-3271<tel:(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]<mailto:[e-mail]>>
Date: Monday, December 11, 2017 at 6:37 PM
To: James Gould <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Ulrich Wisser <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: Eric Rescorla's No Objection on draft-ietf-regext-launchphase-06: (with COMMENT)



On Mon, Dec 11, 2017 at 3:17 PM, Gould, James <[e-mail]<mailto:[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

[cid:image005.png@01D3735A.6A110EB0]


James Gould
Distinguished Engineer
[e-mail]<http://[e-mail]>

703-948-3271<tel:(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]<mailto:[e-mail]>>
Date: Tuesday, December 5, 2017 at 4:40 PM
To: James Gould <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Ulrich Wisser <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
Eric,

My replies are included below.

—

JG

[cid:image006.png@01D3735A.6A110EB0]


James Gould
Distinguished Engineer
[e-mail]<http://[e-mail]>

703-948-3271<tel:(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]<mailto:[e-mail]>>
Date: Tuesday, December 5, 2017 at 4:02 PM
To: James Gould <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Ulrich Wisser <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
Eric,

Thanks again, I provide answers embedded below.

—

JG

[cid:image007.png@01D3735A.6A110EB0]


James Gould
Distinguished Engineer
[e-mail]<http://[e-mail]>

703-948-3271<tel:(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]<mailto:[e-mail]>>
Date: Monday, December 4, 2017 at 6:39 PM
To: James Gould <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Ulrich Wisser <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:
Eric,

Thank you for the review.  Below are my answers to your feedback.

—

JG



James Gould
Distinguished Engineer
[e-mail]<mailto:[e-mail]>

703-948-3271<tel:[phone]>
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]<mailto:[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