Subject: [regext] WG Last Call: https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/

From: "James Galvin" <[email-masked]>
Date: Wed, 26 Apr 2017 15:25:06 -0400

At the last IETF meeting, it was agreed in the REGEXT meeting that the 
following document is ready for submission to the IESG to be considered 
for publication as a Proposed Standard:

Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)
https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/

Ulrich Wisser is the document shepherd and in that role he agrees the 
document is ready for publication.

If any working group member objects to the publication of this document 
please respond on the list by close of business everywhere, Wednesday, 3 
May 2017.  If there are no objections the document will be submitted to 
the IESG.

Thanks,

Antoin and Jim
WG Co-Chairs

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 27 Apr 2017 13:29:41 +0000

> -----Original Message-----
> From: regext [mailto:[email-masked]] On Behalf Of James Galvin
> Sent: Wednesday, April 26, 2017 3:25 PM
> To: Registration Protocols Extensions <[email-masked]>
> Subject: [EXTERNAL] [regext] WG Last Call:

I have re-read and re-reviewed draft-ietf-regext-launchphase. I have not attempted to validate the schema or examples. I support publication, but I do have some comments to share:

Section 1:
s/In addition, the [RFC7848] defines/In addition, RFC 7848 [RFC7848] defines/

Section 2.1:

"Upon receiving a valid request to create a Launch Application, the server MUST"

There's no mention of what a "valid request to create a Launch Application" looks like, so I'm reading this paragraph and not understanding what the trigger for this MUST clause is. I think it would be helpful to say something like "Upon receiving a valid <domain:create> command" instead.

"If the <domain:create> command processes a request synchronously without the use of an intermediate Launch Application, then an application identifier MAY not be needed."

Does "MAY not be needed" mean that an application identifier will not be returned in this case? Is it more accurate to say "then an application identifier is not needed and will not be returned"? "MAY" implies "optional", and I don't quite get if it's OK to return an application identifier or not.

Section 2.2:

"The Internet Corporation for Assigned Names and Numbers (ICANN) Trademark Clearinghouse (TMCH) is the default Trademark Validator and is reserved the Validator Identifier of "tmch"."

And

"The list of validator identifiers and the relationship to issuer identifiers is out of scope for this document."

This sounds like we might need an IANA registry of trademark validator identifiers. If we don't have a registry, how do processors know which values are valid? Does it matter? The text should be clear about this. I don't the text can say "out of scope" while reserving a specific value for one validator.

Section 2.5:

"A Launch Application MUST and a Launch Registration MAY be handled as a domain name of [RFC5731] in "pendingCreate" status"

What does "a domain name of [RFC5731]" mean? I *think* this is trying to say "an EPP domain name object as specified in RFC 5731 [RFC5731]". If that's the case, please consider changing the text.

Section 2.6:

"A server MUST support at least one of the following models"

I'm looking at the schema where the createType is defined. It says that the mark type is choice with minOccurs="0". Does this mean that the mark can be omitted? If so, that appears to be inconsistent with "MUST support at least one" above.

Section 4.1: please update the copyright date.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Thu, 27 Apr 2017 14:16:43 +0000

Scott,

Thanks for review the draft.  My responses to your feedback are embedded below with a “JG-“ prefix.

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

    
    
    Section 1:
    
    Section 2.1:

JG- The trigger in creating a Launch Application or Launch Registration is done via the <domain:create>, so the draft can be updated based on your proposed text.  

JG- I believe the second paragraph of 2.1 can be removed, since I don’t believe there is a valid use case of an application identifier for a Launch Registration.  

    Section 2.2:

    And

JG-There is no intention on setting up an IANA registry for trademark validator identifiers.  The processor in this case is the server who will define the set of accepted trademark validator identifiers based on registry policy (e.g., what validators they decide to support).  The only generic trademark validator identifier that is known is “tmch”.  The intent of the extension is not to manage the set of validator identifiers but to allow for the passing of the validator identifiers from client to server.   It is the responsibility of the server to ensure that the set of acceptable validator identifiers are unique, which could be added to the draft.  Do you agree?  

    Section 2.5:

JG-Yes, “a domain name of [RFC5731]” does mean “an EPP domain name object as specified in RFC 5731 [RFC5731]”.  The draft can be updated based on your recommended text.  
    
    Section 2.6:

JG- The choice with minOccurs=”0” means that the create command can be submitted without the trademark information, as defined in section 2.6, to support the Claims Create Form, as defined in section 3.3.2, and the General Create Form, as defined in section 3.3.3.  The Claims Create Form and the General Create Form do not include the trademark information, so section 2.6 is not applicable.  The trademark information, as defined in section 2.6, is associated with the Sunrise Create Form and the Mixed Create Form, which do include trademark information.  

JG-This will be updated.  
    
    Scott
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 27 Apr 2017 14:24:56 +0000

> From: Gould, James
> Sent: Thursday, April 27, 2017 10:17 AM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked]'
> <[email-masked]>; [email-masked]' <[email-masked]>
> Subject: Re: [EXTERNAL] Re: [regext] WG Last Call:

[snip]

>     Section 2.2:
>
>     "The Internet Corporation for Assigned Names and Numbers (ICANN)
> Trademark Clearinghouse (TMCH) is the default Trademark Validator and is
> reserved the Validator Identifier of "tmch"."
>
>     And
>
>     "The list of validator identifiers and the relationship to issuer
> identifiers is out of scope for this document."
>
>     This sounds like we might need an IANA registry of trademark validator
> identifiers. If we don't have a registry, how do processors know which
> values are valid? Does it matter? The text should be clear about this. I
> don't the text can say "out of scope" while reserving a specific value for
> one validator.
>
> JG-There is no intention on setting up an IANA registry for trademark
> validator identifiers.  The processor in this case is the server who will
> define the set of accepted trademark validator identifiers based on
> registry policy (e.g., what validators they decide to support).  The only
> generic trademark validator identifier that is known is “tmch”.  The
> intent of the extension is not to manage the set of validator identifiers
> but to allow for the passing of the validator identifiers from client to
> server.   It is the responsibility of the server to ensure that the set of
> acceptable validator identifiers are unique, which could be added to the
> draft.  Do you agree?

Yes, if text is added to the draft to make it clear that these values are server-assigned I think the intent would be much clearer, but it still begs the question of how a client will be able to learn the set of valid values. How do you see that working?

Scott

---

From: "Gould, James" <[email-masked]>
Date: Thu, 27 Apr 2017 15:12:56 +0000

Scott,

There are three use cases outlined in the draft where the “validatorID” may be used, which include:

1.       Use in the <launch:code> to indicate to the server the Trademark Validator the code originated from that the server can use to verify against the third party (e.g., Trademark Validator).  In this use case, the server would predefine the relationship with the supported set of Trademark Validator(s) that should generate codes that include the unique “validatorID” or reference what “validatorID” value to use that will provide a signal to the server of where to validate the code.  I would envision the registry defining the supported set of Trademark Validators out-of-band, along with the unique “validatorID” values that must be used to support the “code” or “code with mark” Mark Validation Models.

2.       Returning a <launch:claimKey> in a Claims Check Response with a “validatorID” that indicates which Trademark Validator to query for the Claims Notice Information.  In this use case, the server would predefine the relationship with the supported set of Trademark Validator(s) that provide the claims notice information.  I would envision the registry defining the supported set of Trademark Validators out-of-band, along with the unique “validatorID” values that will be returned in a Claims Check Response and the associated Trademark Validator information for retrieving the claims information.

3.       Passing the <launch:noticeID> from the Trademark Validator with the Claims Create Form.  This use case is directly related to #2, where the <launch:claimKey> “validatorID” value must be mirrored in the <launch:noticeID> of the Claims Create Form.  Again, I would envision the registry defining the supported set of Trademark Validators out-of-band, along with the unique “validatorID” values that will be returned in a Claims Check Response and that must be passed in the <launch:noticeID> of the Claims Create Form.

This comes down to a server deciding to setup or support a specific Trademark Validator for the “code” or “code and mark” validation models of the Sunrise Create Form, and/or for the handling of the “claims” phase (Claims Check and Claims Create Form).  I recommend that text be added to section 2.2 that replaces the sentence “The list of validator identifiers and the relationship to issuer identifiers is out of scope for this document” to something directly related to the responsibilities of the server on the management of the Validator Identifiers.  Something like “If the ICANN TMCH is not used or multiple Trademark Validators are used, the server MUST define the list of supported validator identifiers and where the validator identifiers are used to the clients.”  I’m not sure whether out-of-band needs to be included, but the key is that the servers are responsible for managing the set of supported validator identifiers and that they make the information available to the clients.

Thoughts?

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

    > Thanks for review the draft.  My responses to your feedback are embedded

    > below with a “JG-“ prefix.

    [snip]

    Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 27 Apr 2017 15:24:13 +0000

> the server MUST define the list of supported validator identifiers and where the validator identifiers are used to the clients

Just one suggestion for rewording:

“the server MUST define the list of supported validator identifiers and MUST make this information available to clients using a mutually acceptable, out-of-band mechanism”

I think it’s important to note “out-of-band” to clearly indicate that the means of publishing the values isn’t part of the specification.

Scott

From: Gould, James
Sent: Thursday, April 27, 2017 11:13 AM
To: Hollenbeck, Scott <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [EXTERNAL] Re: [regext] WG Last Call: https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/

Scott,

Thoughts?

—

JG

James Gould

Distinguished Engineer

[email-masked]<mailto:[email-masked]>

703-948-3271

12061 Bluemont Way

Reston, VA 20190

    > To: Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>>; [email-masked]'

    > <[email-masked]<mailto:[email-masked]>>; [email-masked]' <[email-masked]<mailto:[email-masked]>>

    [snip]

    Scott

---

From: "Gould, James" <[email-masked]>
Date: Thu, 27 Apr 2017 15:46:33 +0000

Scott,

Thanks, I believe I’ve got it.  I’ve updated the draft with the following changes based on Scott’s feedback:

1.      Nit on reference to RFC 7848 in section 1.

2.      Added reference to <domain:create> for the request to create a Launch Application in section 2.1.

3.      Removed the second paragraph of section 2.1 describing the option of creating an application identifier for a Launch Registration.

4.      Provided clarification in section 2.2 on the responsibility of the server to ensure that the supported validator identifiers are unique.

a.       The final sentence reads “If the ICANN TMCH is not used or multiple Trademark Validators are used, the server MUST define the list of supported validator identifiers and MUST make this information available to clients using a mutually acceptable, out-of-band mechanism.”

5.      Updated the text in section 2.5 referencing the domain name object in RFC 5731.

6.      Updated the copyright to 2017 in section 4.1.

Let me know whether I missed anything.  Also, if others could do a similar review we can incorporate the changes in the next version of the draft.  If I don’t hear anything within the next week, I’ll post draft-ietf-regext-launchphase-04 that includes the above changes.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thursday, April 27, 2017 at 11:24 AM
To: James Gould <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [EXTERNAL] Re: [regext] WG Last Call: https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/

Scott

From: Gould, James

Scott,

Thoughts?

—

JG

James Gould

Distinguished Engineer

703-948-3271

12061 Bluemont Way

Reston, VA 20190

    [snip]

    Scott

---

From: "James Galvin" <[email-masked]>
Date: Thu, 27 Apr 2017 13:41:15 -0400

I suggest you upload a revised version now.  It will make it easier for 
folks to see the changes.  The nice think about the datatracker is we 
can always revert to an older version if necessary.

Thanks!

Jim

On 27 Apr 2017, at 11:46, Gould, James wrote:

> Scott,
>
> Thanks, I believe I’ve got it.  I’ve updated the draft with the 
> following changes based on Scott’s feedback:
>
>
> 3.      Removed the second paragraph of section 2.1 describing the 
> option of creating an application identifier for a Launch 
> Registration.
>
> 4.      Provided clarification in section 2.2 on the responsibility of 
> the server to ensure that the supported validator identifiers are 
> unique.
>
> a.       The final sentence reads “If the ICANN TMCH is not used or 
> multiple Trademark Validators are used, the server MUST define the 
> list of supported validator identifiers and MUST make this information 
> available to clients using a mutually acceptable, out-of-band 
> mechanism.”
>
> Let me know whether I missed anything.  Also, if others could do a 
> similar review we can incorporate the changes in the next version of 
> the draft.  If I don’t hear anything within the next week, I’ll 
> post draft-ietf-regext-launchphase-04 that includes the above changes.
>
> Thanks,
>
> —
>
> JG
>
>
> James Gould
> Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> To: James Gould <[email-masked]>, "[email-masked]'" 
> <[email-masked]>, "[email-masked]'" <[email-masked]>
> Subject: RE: [EXTERNAL] Re: [regext] WG Last Call: 
>> the server MUST define the list of supported validator identifiers 
>> and where the validator identifiers are used to the clients
>
> “the server MUST define the list of supported validator identifiers 
> and MUST make this information available to clients using a mutually 
> acceptable, out-of-band mechanism”
>
> I think it’s important to note “out-of-band” to clearly indicate 
> that the means of publishing the values isn’t part of the 
> specification.
>
> Scott
>
> From: Gould, James
> There are three use cases outlined in the draft where the 
> “validatorID” may be used, which include:
>
>
> 1.       Use in the <launch:code> to indicate to the server the 
> Trademark Validator the code originated from that the server can use 
> to verify against the third party (e.g., Trademark Validator).  In 
> this use case, the server would predefine the relationship with the 
> supported set of Trademark Validator(s) that should generate codes 
> that include the unique “validatorID” or reference what 
> “validatorID” value to use that will provide a signal to the 
> server of where to validate the code.  I would envision the registry 
> defining the supported set of Trademark Validators out-of-band, along 
> with the unique “validatorID” values that must be used to support 
> the “code” or “code with mark” Mark Validation Models.
> 2.       Returning a <launch:claimKey> in a Claims Check Response with 
> a “validatorID” that indicates which Trademark Validator to query 
> for the Claims Notice Information.  In this use case, the server would 
> predefine the relationship with the supported set of Trademark 
> Validator(s) that provide the claims notice information.  I would 
> envision the registry defining the supported set of Trademark 
> Validators out-of-band, along with the unique “validatorID” values 
> that will be returned in a Claims Check Response and the associated 
> Trademark Validator information for retrieving the claims information.
> 3.       Passing the <launch:noticeID> from the Trademark Validator 
> with the Claims Create Form.  This use case is directly related to #2, 
> where the <launch:claimKey> “validatorID” value must be mirrored 
> in the <launch:noticeID> of the Claims Create Form.  Again, I would 
> envision the registry defining the supported set of Trademark 
> Validators out-of-band, along with the unique “validatorID” values 
> that will be returned in a Claims Check Response and that must be 
> passed in the <launch:noticeID> of the Claims Create Form.
>
>
>
> This comes down to a server deciding to setup or support a specific 
> Trademark Validator for the “code” or “code and mark” 
> validation models of the Sunrise Create Form, and/or for the handling 
> of the “claims” phase (Claims Check and Claims Create Form).  I 
> recommend that text be added to section 2.2 that replaces the sentence 
> “The list of validator identifiers and the relationship to issuer 
> identifiers is out of scope for this document” to something directly 
> related to the responsibilities of the server on the management of the 
> Validator Identifiers.  Something like “If the ICANN TMCH is not 
> used or multiple Trademark Validators are used, the server MUST define 
> the list of supported validator identifiers and where the validator 
> identifiers are used to the clients.”  I’m not sure whether 
> out-of-band needs to be included, but the key is that the servers are 
> responsible for managing the set of supported validator identifiers 
> and that they make the information available to the clients.
>
>
>
> Thoughts?
>
>
>
> —
>
>
>
> JG
>
>
>
>
>
>
>
> James Gould
>
> Distinguished Engineer
>
> On 4/27/17, 10:24 AM, "Hollenbeck, Scott" 
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>
>     > To: Hollenbeck, Scott 
> <[email-masked]<mailto:[email-masked]>>; 
> [email-masked]'
>
>     > <[email-masked]<mailto:[email-masked]>>; [email-masked]' 
> <[email-masked]<mailto:[email-masked]>>
>
>     Yes, if text is added to the draft to make it clear that these 
> values are server-assigned I think the intent would be much clearer, 
> but it still begs the question of how a client will be able to learn 
> the set of valid values. How do you see that working?
>
>
>
>     Scott

---

From: "Gould, James" <[email-masked]>
Date: Thu, 27 Apr 2017 18:30:39 +0000

Done.  Let me know if there is any additional feedback to incorporate into the draft.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

From: James Galvin <[email-masked]>
Date: Thursday, April 27, 2017 at 1:41 PM
To: James Gould <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] WG Last Call: https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/

I suggest you upload a revised version now. It will make it easier for folks to see the changes. The nice think about the datatracker is we can always revert to an older version if necessary.

Thanks!

Jim

Scott,

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Scott

From: Gould, James

Scott,

Thoughts?

—

JG

James Gould

Distinguished Engineer

703-948-3271

12061 Bluemont Way

Reston, VA 20190

    [snip]

    Scott