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 [cid:image001.png@01D2BF4B.EB49F230] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://verisigninc.com/> From: "Hollenbeck, Scott" <shollenb...@verisign.com> Date: Thursday, April 27, 2017 at 11:24 AM To: James Gould <jgo...@verisign.com>, "'gal...@elistx.com'" <gal...@elistx.com>, "'regext@ietf.org'" <regext@ietf.org> Subject: RE: [EXTERNAL] Re: [regext] WG Last Call: https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ > 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 <shollenb...@verisign.com>; 'gal...@elistx.com' <gal...@elistx.com>; 'regext@ietf.org' <regext@ietf.org> Subject: Re: [EXTERNAL] Re: [regext] WG Last Call: https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ 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 jgo...@verisign.com<mailto:jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com <http://verisigninc.com/> On 4/27/17, 10:24 AM, "Hollenbeck, Scott" <shollenb...@verisign.com<mailto:shollenb...@verisign.com>> wrote: > -----Original Message----- > From: Gould, James > Sent: Thursday, April 27, 2017 10:17 AM > To: Hollenbeck, Scott <shollenb...@verisign.com<mailto:shollenb...@verisign.com>>; 'gal...@elistx.com' > <gal...@elistx.com<mailto:gal...@elistx.com>>; 'regext@ietf.org' <regext@ietf.org<mailto:regext@ietf.org>> > Subject: Re: [EXTERNAL] Re: [regext] WG Last Call: > https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/ > > Scott, > > Thanks for review the draft. My responses to your feedback are embedded > below with a “JG-“ prefix. [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
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
