Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

[Gould, James]

I believe the classification  should remain at the object-level, 
since the concept of standard or premium is done at the object-level and not at 
the command level.  There may be the use case where a premium domain has a 
higher fee for the create but has the same fee as a standard domain for the 
renew and transfer, but that is based on the fee schedule defined for one or 
more premium domain names.  The key is that the fee is more variable for 
premium domains than for standard domains, so it may be misleading to return 
“standard” for the renew and transfer commands of a premium domain if the 
premium fee and standard fee happens to be the same, since there is implied 
variability with the premium domain.   It’s best to leave the classification as 
an object-level attribute and not attempt to derive it based on a comparison 
between the fee schedules.  

  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

VerisignInc.com  

On 4/26/17, 11:12 AM, "regext on behalf of Andreas Huber" 
 wrote:

Hi Roger,

thanks for version 0.17! This one should solve most of our "registrar" 
issues (Hopefully, some registries plan to implement this version soon).

Some thoughts to open questions:

* Premium Domain Availability without Fee-Ext.

I would also vote to respond with "unavailable".

The status "premium" of a domain could be understood in a similar way to 
the domain status reserved, blocked or registered. Without using the fee 
extension, it's not possible to register such names, therefore they're 
"unavailable" for the registrar just like reserved names.
If we don't want to use the Fee-Ext. for a specific registry (because of 
contractual reasons or something else), we're not interested in the 
availability of premium names which we can't/won't register anyway.

Second thought: From a registry's perspective, I understand a name is 
always "available" if it is not registered, blocked or reserved, independent of 
any fees. But, ;) since EPP is a personalized communication protocol (client 
needs to login and register extensions to use), then responses should be
personalized to the client. For a client not using the fee extension, a 
premium name is technically "unavailable".


*  in check responses

The last weeks a question regarding the  element came up a 
couple of times.

 is a child of  since version 0.13, therefore 
section 3.7. should be clarified.

Is  an attribute of a specific fee or an object? There are some 
misunderstandings, especially before version 0.13, which describes "class" as a 
child of . Several discussions with registries pointed out, that they 
understand  as "attribute" of the object. This results
in conditions where a domain has a premium create but a standard renewal 
fee to be both tagged with "premium", because an object can only have one value 
of the same attribute.

As an example (from section 3.7): "The  element which appears in 
 responses is used to indicate the classification of an object." should 
be changed to something like "... the classification of a command fee".

As a registrar, we need to know if a "command fee" (not an object) is 
premium (e.g. premium) or standard, if one wants to 
respond standard fees at all. Responding standard fees are in fact unnecessary, 
btw.


Thanks,
Andreas




Am 25.04.2017 um 23:40 schrieb Roger D Carney:
> Good Afternoon,
> 
>  
> 
> Here is the update draft document. This should include all of the agreed 
upon changes from the Chicago meeting (biggest change was the simplification of 
the  call).
> 
>  
> 
> One topic that was discussed in Chicago (and not resolved) was on the 
concept of “premium names” and what is returned from the server if no fee 
extension was passed into the . Many thought to be more “backwards 
compatible”/”user friendly”, especially for those registrars that do not and may
> not be participating in the allocation of “premium names”, that the 
server should respond as unavailable. Others expressed that if it is available 
then the server should respond available. Please share your thoughts on the 
list on this topic and if this draft should even try to account for this 
concept.
> 
>  
> 
> Please let me know if you have any questions.
> 
>  
> 
>  
> 
> Thanks
> 
> Roger
> 
>  
> 
>  
> 
> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
> Sent: Tuesday, April 25, 2017 4:31 PM
> To: i-d-annou...@ietf.org
> Cc: regext@ietf.org
> Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt
> 
>  
> 
>  
> 
> A New Internet-Draft is available from the on-

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

[Hollenbeck, Scott]

> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin
> Sent: Wednesday, April 26, 2017 3:25 PM
> To: Registration Protocols Extensions 
> Subject: [EXTERNAL] [regext] WG Last Call:
> https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/
>
> 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.

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  command" instead.

"If the  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

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gould, James]

Scott,

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

  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

VerisignInc.com  

On 4/27/17, 9:29 AM, "regext on behalf of Hollenbeck, Scott" 
 wrote:

> -Original Message-
> From: regext [mailto:regext-boun...@ietf.org] On Behalf Of James Galvin
> Sent: Wednesday, April 26, 2017 3:25 PM
> To: Registration Protocols Extensions 
> Subject: [EXTERNAL] [regext] WG Last Call:
> https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/
>
> 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.

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  command" instead.

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

"If the  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.

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:

"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?  


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.

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:

"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 minOccur

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

[Hollenbeck, Scott]

> -Original Message-
> From: Gould, James
> Sent: Thursday, April 27, 2017 10:17 AM
> To: Hollenbeck, Scott ; 'gal...@elistx.com'
> ; '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

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

[Gould, James]

Scott,



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



1.   Use in the  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  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  from the Trademark Validator with the 
Claims Create Form.  This use case is directly related to #2, where the 
 “validatorID” value must be mirrored in the  
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  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



703-948-3271

12061 Bluemont Way

Reston, VA 20190



VerisignInc.com 



On 4/27/17, 10:24 AM, "Hollenbeck, Scott"  wrote:



   > -Original Message-

> From: Gould, James

> Sent: Thursday, April 27, 2017 10:17 AM

> To: Hollenbeck, Scott ; 'gal...@elistx.com'

> ; '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

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

[Hollenbeck, Scott]

> 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 ; 'gal...@elistx.com' 
; '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  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  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  from the Trademark Validator with the 
Claims Create Form.  This use case is directly related to #2, where the 
 “validatorID” value must be mirrored in the  
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  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



703-948-3271

12061 Bluemont Way

Reston, VA 20190



VerisignInc.com 



On 4/27/17, 10:24 AM, "Hollenbeck, Scott" 
mailto:shollenb...@verisign.com>> wrote:



   > -Original Message-

> From: Gould, James

> Sent: Thursday, April 27, 2017 10:17 AM

> To: Hollenbeck, Scott 
mailto:shollenb...@verisign.com>>; 'gal...@elistx.com'

> mailto:gal...@elistx.com>>; '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

> ident

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

[Gould, James]

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

From: "Hollenbeck, Scott" 
Date: Thursday, April 27, 2017 at 11:24 AM
To: James Gould , "'gal...@elistx.com'" 
, "'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 ; 'gal...@elistx.com' 
; '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  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  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  from the Trademark Validator with the 
Claims Create Form.  This use case is directly related to #2, where the 
 “validatorID” value must be mirrored in the  
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  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 d

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

[Thomas Corte]

Hello Roger,

On 2017-04-25 23:40, Roger D Carney wrote:

> Good Afternoon,
> 
> Here is the update draft document. This should include all of the agreed
> upon changes from the Chicago meeting (biggest change was the
> simplification of the  call).

Thanks for this new version. Here are a couple of
comments/corrections/suggestions:

* Typo (messed up quotes) in the XSD for this "minOccurs" attribute:

  

* Typos: "elelment", "objectCheckTpye"

* The attribute "name" in commandType should really be mandatory,
  but is currently optional due to the default minOccurs=0 for XML
  attributes. I don't see a use case for a nameless command, and
  the text seems to assume that a name is always present.

* The semantics of the  element's "avail" attribute in conjunction
with the fees and/or reasons of nested  elements seem unclear.
Take the following  for example:



  

  
example.tld
  


  
EUR

  

e1f8b4cd61f84469436bf16585f976b3
  


Since no phase/subphase is specified, the draft calls for returning data
for "all valid server combinations of currently active phase(s) and
active subphase(s)" for the "create" operation.
The period defaults to 1.
A possible response is:



  

  Command completed successfully


  

  example.tld

  


  
EUR

  example.tld
  
1
60.00
  
  
1
30.00
  
  
domain name not available as a promotion name
  

  


  e1f8b4cd61f84469436bf16585f976b3
  1493309414927-16

  


In this example, there are three active phases:

* example.tld is available in phase "open" for 60.00 EUR per year
* example.tld is available in phase "defensive" for 30.00 EUR per year
* example.tld is not available in phase "promotion" since the name is
not part of that promotion phase

For this example, should the  element carry avail="false" or
avail="true"? Turns out that both options are not OK since:

  "If the "avail" attribute of the  element is false, then the
element MUST NOT contain any  or 
   child elements.  If the "avail" attribute is true, then the
element MUST NOT contain a  element."

However, mixed cases like the above (with some phases permitting a name
and other phases not allowing it) are not unlikely in real life. Now,
according to the draft's wording

  "the server MAY eliminate some or all of the  element(s)"

the server's only option here is to either eliminate the commands with
the  element (and set avail="true") or eliminate the commands
with fee information (and set avail="false"), but it doesn't seem
prudent to withhold useful information that has probably already been
computed. This wording also leaves too much room for interpretation,
leading to uncertainty about what to expect on the client side.

I'd therefore suggest to move the "avail" attribute back to the
 level and allowing mixed results like the above. The avail
attribute on the  may be retained, but should probably only be false
if no fees whatsoever could be assessed for any possible combination of
phases/subphase for a name.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund   E-Mail: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[James Galvin]

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

From: "Hollenbeck, Scott" 
Date: Thursday, April 27, 2017 at 11:24 AM
To: James Gould , "'gal...@elistx.com'" 
, "'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 ; 'gal...@elistx.com' 
; '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  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  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  from the Trademark Validator 
with the Claims Create Form.  This use case is directly related to #2, 
where the  “validatorID” value must be mirrored 
in the  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  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 is

[regext] I-D Action: draft-ietf-regext-launchphase-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions of the IETF.

Title   : Launch Phase Mapping for the Extensible Provisioning 
Protocol (EPP)
Authors : James Gould
  Wil Tan
  Gavin Brown
Filename: draft-ietf-regext-launchphase-04.txt
Pages   : 64
Date: 2017-04-27

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for the provisioning and management of domain name
   registrations and applications during the launch of a domain name
   registry.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-launchphase/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-launchphase-04
https://datatracker.ietf.org/doc/html/draft-ietf-regext-launchphase-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-launchphase-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gould, James]

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

Thanks,

—

JG

[cid:image001.png@01D2BF62.D7A15360]

James Gould
Distinguished Engineer
jgo...@verisign.com

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

VerisignInc.com

From: James Galvin 
Date: Thursday, April 27, 2017 at 1:41 PM
To: James Gould 
Cc: "Hollenbeck, Scott" , "regext@ietf.org" 

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


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



From: "Hollenbeck, Scott" 
Date: Thursday, April 27, 2017 at 11:24 AM
To: James Gould , "'gal...@elistx.com'" 
, "'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 ; 'gal...@elistx.com' 
; '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  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  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  from the Trademark Validator with the 
Claims Create Form.  This use case is directly related to #2, where the 
 “validatorID” value must be mirrored in the  
of the Claims Create Form.  Again, I would envision the registry defining the 
supported set of Trademark Validators out-of-band, along with t

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

[Gould, James]

Roger,

Thanks for posting the updated draft and the draft looks very close to what was 
discussed in Chicago.  Below is my feedback to the latest version:


1.  Section 3.1 “Client Commands”

a.   It may be useful to include an enumerated list of commands that is 
extensible like what was done in draft-ietf-regext-change-poll, which includes 
an enumerated list of operations with one of the values being “custom” and with 
an optional “op” attribute to define the custom operation name.  This way the 
XML parser will validate the command names prior to hitting the business logic, 
except for the “custom” command that would need to be manually validated.

2.  Section 5.1.1 “EPP  Command”

a.   The OPTOINAL  element should be fully defined.  For 
example, what happens if the  is not provided?  I assume that if 
the  is not provided that the default period would be used.  The 
default period may be dependent on the command itself.  For example, a restore 
does not have a period and therefore there is no default.  Should the default 
period be defined by command in the protocol, or should it be up to server 
policy?  My thought is to leave it up to server policy, since that is what was 
done in EPP RFC 5732.

b.  The OPTIONAL  element should be fully defined.  What does 
providing the  mean.  Is the  a filter to indicate 
whether the domain name matches the specified classification?  If the 
 does not match, is the fee returned as unavailable due to something 
like “mismatching class”?  Since classification is handled at the object level 
and not the command level, does it make sense to set it at the object level in 
the XML, like placing it at the level of the  and the 
 elements instead of placing it under the  element?  
The same holds true for the check response extension.

c.   I would not directly refer to the  or the  
except as an example, since the fee extension could be applied to other 
billable EPP objects (e.g., email forwarding, defensive registration).  My 
recommendation is to be generic in stating something like “and a  for 
each element referenced in the check command, like for each  
element in RFC 5731 [RFC5731]”.  Similarly, I would change “A  
element, which MUST match an element name from the client command, like the 
 element in RFC 5731 [RFC5731]”.

d.  I would update the text for the  returned in the check 
response extension.  I would keep the text generic to return the period that 
was requested in the command extension, the default period if there is one for 
the command, or no period if the command is not associated with a period like 
with the “restore” command in RFC 3915 [RFC3915].  Since we can create new 
verbs in EPP like what was done with the “restore” command in RFC 3915, I 
recommend keeping the language in the extension as generic as possible to cover 
the full set of options for any type of command.

e.   I recommend describing the , , , and 
 elements either directly with the element or via a reference to 
somewhere else within the draft.

f.The  response example is missing the “avail” attribute in the 
 elements when avail=”1”.  I realize that the default is “1” in the XML 
schema, so I would specify that there is a default value of “1” in the text and 
I would include examples of explicitly including the avail=”1” for clarity.

g.  You may need to support the “lang” attribute for the  to be 
consistent with the other EPP RFCs.

h.  In the example, I don’t believe any  elements other than 
 and  would be returned when avail=”0”.  I recommend 
removing the  from the example when avail=”0”.

i.I believe it is important to include text describing how a compliant 
server should handle non-standard fee objects in the check command when the fee 
extension is not passed.  It is best to return the non-standard fee object as 
unavailable in the check response.  If the client does not know the fee, then 
the create will fail downstream, so it’s best to address it upfront.

3.  Section 5.1.1.1 “Server Handling of Elements”

a.   I believe the first element on the tiers of classes, it looks like it 
assumes that the avail flag is at the level of the  element, but 
it is now at the level of .  My recommendation is to define the 
 at the object level, and if the  does not match, return 
avail=”0” at the  level with a  “fee class mismatch”.

b.  The second element also assumes that the avail flag is at the 
 level.  This element is not clear to me.  I believe in general if 
the  is passed it must be validated as a supported classification 
and compared with the classification assigned to the object, and if the 
classification is invalid or there is a mismatch the fee should be returned as 
unavailable (avail=”0”) for the fee object with a reason.

c.   I’m not sure that it’s good for the server to ignore an element passed 
by the client.  If the client passes an invalid element, then it should return 
as unavail