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:
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
