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

[Thomas Corte]

Hello,

On 27/04/2017 21:55, Gould, James wrote:

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

Overall, I'm a bit puzzled regarding the usefulness of the "avail"
attribute at this level, especially since the  element still requires
at least one command to be specified. The change log says

"Moved fee avail to objectCDType to allow fast failing on error situations."

However, if e.g. the domain name is invalid for the TLD, the XSD still
demands to include at least one command, meaning that all commands from
the check request would have to echoed here for no good reason. "command"
in objectCDType should IMO have minOccurs="0". Even better, there should
be a  between a sequence of  or  in the XSD
(either there are available commands, or there's a reason why they're not
available).

I'm also wondering how to report a wrong currency with this new version.
I think the only way to deal with it is to let the entire 
fail with an error, since there's no way to (briefly) report a wrong
currency due to the way objectCDType is currently defined.

I don't think the "fast fail" objective was reached in this regard.

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] I-D Action: draft-ietf-regext-epp-fees-03.txt

[Gould, James]

Thomas,

I don’t agree that failing the entire check command if someone passes invalid 
input in the fee extension, unless it is syntactically incorrect.  The point is 
to communicate whether the fee information is available for the given object 
and commands, and if it is return the fee information.  I agree that there 
should be a choice between inclusion of the commands or the reason in 
“objectCDType” to support returning either a successful list of commands or 
optionally providing a reason that the fee information is not available.  My 
recommendation for “objectCDType” is below:


  


  
  


The objectCDType can include the fee:objID, the fee:objID along with the 
commands, or the fee:objID along with the reason.  The “avail” flag is changed 
to required without a default to be explicit, which is consistent with how the 
“avail” flag works in the check response.  The reason leverages the 
“eppcom:reasonType” to support use of the optional “lang” attribute to be 
consistent with the check response.  
  
—
 
JG



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

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

VerisignInc.com  

On 4/28/17, 8:09 AM, "Thomas Corte"  wrote:

Hello,

On 27/04/2017 21:55, Gould, James wrote:

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

Overall, I'm a bit puzzled regarding the usefulness of the "avail"
attribute at this level, especially since the  element still requires
at least one command to be specified. The change log says

"Moved fee avail to objectCDType to allow fast failing on error situations."

However, if e.g. the domain name is invalid for the TLD, the XSD still
demands to include at least one command, meaning that all commands from
the check request would have to echoed here for no good reason. "command"
in objectCDType should IMO have minOccurs="0". Even better, there should
be a  between a sequence of  or  in the XSD
(either there are available commands, or there's a reason why they're not
available).

I'm also wondering how to report a wrong currency with this new version.
I think the only way to deal with it is to let the entire 
fail with an error, since there's no way to (briefly) report a wrong
currency due to the way objectCDType is currently defined.

I don't think the "fast fail" objective was reached in this regard.

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] I-D Action: draft-ietf-regext-epp-fees-03.txt

[Thomas Corte]

Hello James,

On 28/04/2017 14:32, Gould, James wrote:

> Thomas,
> 
> I don’t agree that failing the entire check command if someone passes invalid 
> input in the fee extension, unless it is syntactically incorrect.  The point 
> is to communicate whether the fee information is available for the given 
> object and commands, and if it is return the fee information.

Sure, but the current draft would require the following response for a
 with a wrong currency "BLA", assuming that two domains with 3
commands each were specified:

  
BLA

  example1.tld
  
2
the selected currency is not supported (supported
currency is "USD")
  
  
1
the selected currency is not supported (supported
currency is "USD")
  
  
1
the selected currency is not supported (supported
currency is "USD")
  


  example1.tld
  
2
the selected currency is not supported (supported
currency is "USD")
  
  
1
the selected currency is not supported (supported
currency is "USD")
  
  
1
the selected currency is not supported (supported
currency is "USD")
  

  

I.e. there is no shorter way to report the wrong currency (which should
have prevented any further checks by the server whatsoever) than this.
Note that the periods are there since the draft says "The 
element MUST be present in  responses."

It gets a bit better by introducing the  we discussed (see
below), but even then the response would have to list each domain from
the check, even though the error is independent from the domain name.
Yet I'm aware that the only option to prevent this would be to introduce
a framing element for the  elements, which could then contain (yet
another) reason for failure as an alternative for the  children.

> I agree that there should be a choice between inclusion of the commands or 
> the reason in “objectCDType” to support returning either a successful list of 
> commands or optionally providing a reason that the fee information is not 
> available.  My recommendation for “objectCDType” is below:
> 
> 
>   
> 
> 
>maxOccurs="unbounded" />
>   
> 
> 
> The objectCDType can include the fee:objID, the fee:objID along with the 
> commands, or the fee:objID along with the reason.  The “avail” flag is 
> changed to required without a default to be explicit, which is consistent 
> with how the “avail” flag works in the check response.  The reason leverages 
> the “eppcom:reasonType” to support use of the optional “lang” attribute to be 
> consistent with the check response.  

Agreed, this is what I had in mind.

However, the question from the e-mail I sent yesterday remains - how to
report "mixed" results (i.e., what value should "avail" have if fees are
available for some nested commands, but not for others (see the example
from my e-mail).

Best regards,

Thomas

-- 

 |   |
 | knipp |Knipp  Medien und Kommunikation GmbH
  ---Technologiepark
 Martin-Schmeißer-Weg 9
 44227 Dortmund
 Deutschland

 Dipl.-Informatiker  Tel:+49 231 9703-0
 Thomas CorteFax:+49 231 9703-200
 Stellvertretender LeiterSIP:thomas.co...@knipp.de
 Software-EntwicklungE-Mail: thomas.co...@knipp.de

 Registereintrag:
 Amtsgericht Dortmund, HRB 13728

 Geschäftsführer:
 Dietmar Knipp, Elmar Knipp

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

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

[Gould, James]

Thomas,



There are three classifications of errors that can occur with the fee extension 
to the check command:



1.   Syntax error – This should result in an error for the entire check 
command.

2.   Object (domain) name error (incorrect domain name, reserved domain 
name, blocked domain name, etc.) – This should result in returning avail=”0” 
for the associated fee:cd element for the object in the response.

3.   Crosscutting input element error (invalid currency, invalid command, 
invalid command period, invalid class, invalid command phase or invalid 
subphase – Since each of these input elements apply to all objects in the check 
command, an error with any of them will impact the ability to return a complete 
set of fee information.  My recommendation is to fast fail the processing of 
the fee information and return back avail=”0” for each of the objects in the 
response with an appropriate reason like “Invalid currency XXX”, “Invalid 
command XXX”, or “Invalid command XXX period YYY”.  I don’t believe that it 
will help to attempt to put a higher level avail attribute and reason for the 
entire fee check response extension, since the client would be expecting a fee 
result for each object in the check command on a successful response.  The 
check command should not fail based on a data issue, so I would apply that same 
approach with the fee extension to the check command.

a.   Since we’re extending the check command and response, I don’t believe 
that the processing should flag errors below the object level.  This means that 
if one command is valid and another command is invalid, the fee information is 
not available for the object.  The server will fast fail the processing of the 
fee extension in the event of a failure to one command, class, period, phase, 
subphase, or currency.  If there is an expectation that the server should not 
fast fail, then we should consider adding or moving the fee extension to the 
info command and response.



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



VerisignInc.com 



On 4/28/17, 8:48 AM, "Thomas Corte"  wrote:



Hello James,



On 28/04/2017 14:32, Gould, James wrote:



> Thomas,

>

> I don’t agree that failing the entire check command if someone passes 
invalid input in the fee extension, unless it is syntactically incorrect.  The 
point is to communicate whether the fee information is available for the given 
object and commands, and if it is return the fee information.



Sure, but the current draft would require the following response for a

 with a wrong currency "BLA", assuming that two domains with 3

commands each were specified:



  

BLA



  example1.tld

  

2

the selected currency is not supported (supported

currency is "USD")

  

  

1

the selected currency is not supported (supported

currency is "USD")

  

  

1

the selected currency is not supported (supported

currency is "USD")

  





  example1.tld

  

2

the selected currency is not supported (supported

currency is "USD")

  

  

1

the selected currency is not supported (supported

currency is "USD")

  

  

1

the selected currency is not supported (supported

currency is "USD")

  



  



I.e. there is no shorter way to report the wrong currency (which should

have prevented any further checks by the server whatsoever) than this.

Note that the periods are there since the draft says "The 

element MUST be present in  responses."



It gets a bit better by introducing the  we discussed (see

below), but even then the response would have to list each domain from

the check, even though the error is independent from the domain name.

Yet I'm aware that the only option to prevent this would be to introduce

a framing element for the  elements, which could then contain (yet

another) reason for failure as an alternative for the  children.



> I agree that there should be a choice between inclusion of the commands 
or the reason in “objectCDType” to support returning either a successful list 
of commands or optionally providing a reason that the fee information is not 
available.  My recommendation for “objectCDType” is below:

>

> 

>   

> 

> 

>maxOccurs="unbounded" />

>   

> 

>

> The objectCDType can include the f

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

[Thomas Corte]

James,

On 28/04/2017 15:27, Gould, James wrote:

> Thomas,
> 
> There are three classifications of errors that can occur with the fee
> extension to the check command:
> 
> 1.   Syntax error – This should result in an error for the entire
> check command. 
> 
> 2.   Object (domain) name error (incorrect domain name, reserved
> domain name, blocked domain name, etc.) – This should result in returning
> avail=”0” for the associated fee:cd element for the object in the response.

Agreed.

>  My recommendation
> is to fast fail the processing of the fee information and return back
> avail=”0” for each of the objects in the response with an appropriate
> reason like “Invalid currency XXX”, “Invalid command XXX”, or “Invalid
> command XXX period YYY”.  I don’t believe that it will help to attempt to
> put a higher level avail attribute and reason for the entire fee check
> response extension, since the client would be expecting a fee result for
> each object in the check command on a successful response.  The check
> command should not fail based on a data issue, so I would apply that same
> approach with the fee extension to the check command. 
> 
> a.   Since we’re extending the check command and response, I don’t
> believe that the processing should flag errors below the object level. 
> This means that if one command is valid and another command is invalid,
> the fee information is not available for the object.  The server will
> fast fail the processing of the fee extension in the event of a failure
> to one command, class, period, phase, subphase, or currency.  If there is
> an expectation that the server should not fast fail, then we should
> consider adding or moving the fee extension to the info command and
> response.   

Agreed, even if the response would in this case not really reflect the
server's internal fast failure, since it would still return the same
error message for each checked object. But I can live with that.

The question remains how to respond in situations where, for the same
name, some  report assessed fees (since the name is e.g. OK for
a certain phase or period), but some others have a  indicating an
error.
Which value should the  element's "attribute" have? Here's the
example from yesterday's e-mail again:

 
EUR

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

  

My suggestion would be to always include all  results in the
 element (whether they have fees or reason), and to have  as long as at least one  does not have a 
indicating an error. I.e., only if all the  elements in the
response contain a reason indicating an error, the  element should
indicate the non-availability of fees.

Thoughts?

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] I-D Action: draft-ietf-regext-epp-fees-03.txt

[Jody Kolker]

Thanks James.

Comments in line below.


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Thursday, April 27, 2017 2:56 PM
To: Roger D Carney ; regext@ietf.org
Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

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.

This section appears to be enumerated already but does need to have the 
“custom” command added.  Can you be provide an example of the enumeration?


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.

The  is defined in 3.3 – should that text also be added to 5.1.1?
From the document:
The  element is OPTIONAL in  commands: if omitted,the server 
MUST determine the fee(s) using a validity period of 1 year.  The  
element MUST be present in  responses.



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.

I believe the  should be removed from the check command request as 
it does not seem to have a purpose.  It should only be included in the response.


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]”.

Will review with Roger.


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.

Will review with Roger.


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

Will review with Roger.


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.

Agree.


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

Could this be left to server preference?


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.

Agree – If the fee exte

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

[Gould, James]

Jody,

My feedback is included inline below prefixed with “JG-“.

—

JG

[cid:image001.png@01D2C03D.ADF24700]

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

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

VerisignInc.com

From: regext  on behalf of Jody Kolker 

Date: Friday, April 28, 2017 at 3:41 PM
To: "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

Thanks James.

Comments in line below.


From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Gould, James
Sent: Thursday, April 27, 2017 2:56 PM
To: Roger D Carney ; regext@ietf.org
Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

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.

This section appears to be enumerated already but does need to have the 
“custom” command added.  Can you be provide an example of the enumeration?

JG – I mean defined as an enumerated list in the XSD, as in the following:

   
 
   
   
   
   
   
   
 
   

   
   …
  
  
  …



In this case, the “Example  command” would be the same except a new 
custom command example could be added:

   C: 
   C:   2
   C: 
   C: 
   C: 
   C: 
   C: 



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.

The  is defined in 3.3 – should that text also be added to 5.1.1?
From the document:
The  element is OPTIONAL in  commands: if omitted,the server 
MUST determine the fee(s) using a validity period of 1 year.  The  
element MUST be present in  responses.

 JG – You could provide a short description in 5.1.1 and then link to the full 
description in 3.3.  It may be worth updating 3.3 to make the default for the 
, , and  command 1 year, but to leave the default for 
the remainder of the commands up to server policy.  For example, if command 
extensibility is supported, the default period for the custom “sync” command 
would be up to server policy.


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.

I believe the  should be removed from the check command request as 
it does not seem to have a purpose.  It should only be included in the response.

JG – I agree.


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]”.

Will review with Roger.


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

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

[Gould, James]

Thomas,



I’m sorry, I missed the existence of a reason under the command since I thought 
the “avail” attribute and the reason element moved from the command level to 
the object level.  My main concern with providing a highly feature rich fee 
extension to the domain check is ensuring that the domain check continues to 
meet the performance requirements, and that we don’t start down the path of 
creating extension upon extension of the domain check that will transition it 
into a domain “everything” command.  I view the options for providing fee 
information in the fee extension as follows:



1.   Extend the check command, as defined in draft-ietf-regext-epp-fees-03, 
with object level availability and unavailability reasons.

a.   Your use case would be handled by returning  for 
example.tld with no commands and with the reason “domain name not available as 
a promotion name”.  The server would fast fail the fee extension for the domain 
example.tld.  This keeps the check command lighter weight, but it is still much 
heavier weight than a standard check command.

2.   Extend the check command by defining a new command called the “fee 
check command”.

a.   The “fee check command” can include the availability along with the 
fee information, but it is treated differently from a standard check command 
and future extensions of the check command would not automatically apply to the 
“fee check command”.  This change is strictly associated with the wording in 
the draft like defining the “claims check command” in section 3.1.1 of 
draft-ietf-regext-launchphase.  In this case, we can provide for a more robust 
set of features targeted to the fee, which could include extension level 
availability (currency is invalid or some other crosscutting attribute), object 
level availability (domain name is invalid or class is invalid), and command 
level availability (command is invalid or command not applicable to domain).  
This removes the concern over the performance of the check command, since this 
is a fee check command and it does not encourage future heavyweight extensions.

3.   Implement #1 and extend the info command by defining a new command 
called the “fee info command” that supports getting fee information for 
existing and non-existing objects, but it does not return the standard info 
response.

a.   The fee info command could include a more robust set of features 
targeted to the fee, which could include extension level availability (currency 
is invalid or some other crosscutting attribute), object level availability 
(domain name is invalid or class is invalid), and command level availability 
(command is invalid or command not applicable to domain).  This supports 
getting more complex fee information without making the check command too 
complex.  An example of a similar info command extension is defined with the 
Related Domain Info Command in our Related Domain Extension 
(http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_related-domain_v00.html#relatedInfoForm
 ).



Thoughts?



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



VerisignInc.com 



On 4/28/17, 10:09 AM, "Thomas Corte"  wrote:



James,



On 28/04/2017 15:27, Gould, James wrote:



> Thomas,

>

> There are three classifications of errors that can occur with the fee

> extension to the check command:

>

> 1.   Syntax error – This should result in an error for the entire

> check command.

>

> 2.   Object (domain) name error (incorrect domain name, reserved

> domain name, blocked domain name, etc.) – This should result in returning

> avail=”0” for the associated fee:cd element for the object in the 
response.



Agreed.



>  My recommendation

> is to fast fail the processing of the fee information and return back

> avail=”0” for each of the objects in the response with an appropriate

> reason like “Invalid currency XXX”, “Invalid command XXX”, or “Invalid

> command XXX period YYY”.  I don’t believe that it will help to attempt to

> put a higher level avail attribute and reason for the entire fee check

> response extension, since the client would be expecting a fee result for

> each object in the check command on a successful response.  The check

> command should not fail based on a data issue, so I would apply that same

> approach with the fee extension to the check command.

>

> a.   Since we’re extending the check command and response, I don’t

> believe that the processing should flag errors below the object level.

> This means that if one command is valid and another command is invalid,

> the fee information is not available for the object.  The server will

> fast fail the processing of the fee extension in the event of a failure

> t

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

[Rubens Kuhl]

James, 

I understand your concern with option #1, but I think option #3 goes into a 
different set of issues where we mix the domain sales pipeline with domain 
management activities, for which domain:info is commonly used. 
I'm neutral between option #1 and option #2, but while both work me, I would 
really like to know which option has more chance of being implemented by 
registrars; and if they favor either #1 or #2, I would favor that as well. 



Rubens



> Em 28 de abr de 2017, à(s) 17:55:000, Gould, James  
> escreveu:
> 
> Thomas, 
>  
> I’m sorry, I missed the existence of a reason under the command since I 
> thought the “avail” attribute and the reason element moved from the command 
> level to the object level.  My main concern with providing a highly feature 
> rich fee extension to the domain check is ensuring that the domain check 
> continues to meet the performance requirements, and that we don’t start down 
> the path of creating extension upon extension of the domain check that will 
> transition it into a domain “everything” command.  I view the options for 
> providing fee information in the fee extension as follows:
>  
> 1.   Extend the check command, as defined in 
> draft-ietf-regext-epp-fees-03, with object level availability and 
> unavailability reasons. 
> a.   Your use case would be handled by returning  for 
> example.tld with no commands and with the reason “domain name not available 
> as a promotion name”.  The server would fast fail the fee extension for the 
> domain example.tld.  This keeps the check command lighter weight, but it is 
> still much heavier weight than a standard check command. 
> 2.   Extend the check command by defining a new command called the “fee 
> check command”. 
> a.   The “fee check command” can include the availability along with the 
> fee information, but it is treated differently from a standard check command 
> and future extensions of the check command would not automatically apply to 
> the “fee check command”.  This change is strictly associated with the wording 
> in the draft like defining the “claims check command” in section 3.1.1 of 
> draft-ietf-regext-launchphase.  In this case, we can provide for a more 
> robust set of features targeted to the fee, which could include extension 
> level availability (currency is invalid or some other crosscutting 
> attribute), object level availability (domain name is invalid or class is 
> invalid), and command level availability (command is invalid or command not 
> applicable to domain).  This removes the concern over the performance of the 
> check command, since this is a fee check command and it does not encourage 
> future heavyweight extensions.
> 3.   Implement #1 and extend the info command by defining a new command 
> called the “fee info command” that supports getting fee information for 
> existing and non-existing objects, but it does not return the standard info 
> response.
> a.   The fee info command could include a more robust set of features 
> targeted to the fee, which could include extension level availability 
> (currency is invalid or some other crosscutting attribute), object level 
> availability (domain name is invalid or class is invalid), and command level 
> availability (command is invalid or command not applicable to domain).  This 
> supports getting more complex fee information without making the check 
> command too complex.  An example of a similar info command extension is 
> defined with the Related Domain Info Command in our Related Domain Extension 
> (http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_related-domain_v00.html#relatedInfoForm
>  
> 
>  ).  
>  
> Thoughts?
>  
> —
> JG
>  
>  
>  
> James Gould
> Distinguished Engineer
> jgo...@verisign.com 
>  
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>  
> VerisignInc.com   > 
>  
> On 4/28/17, 10:09 AM, "Thomas Corte"  wrote:
>  
> James,
> 
> On 28/04/2017 15:27, Gould, James wrote:
> 
> > Thomas,
> > 
> > There are three classifications of errors that can occur with the fee
> > extension to the check command:
> > 
> > 1.   Syntax error – This should result in an error for the entire
> > check command. 
> > 
> > 2.   Object (domain) name error (incorrect domain name, reserved
> > domain name, blocked domain name, etc.) – This should result in 
> returning
> > avail=”0” for the associated fee:cd element for the object in the 
> response.
> 
> Agreed.
> 
> >  My recommendation
> > is to fast fail the processing of the fee information and return back
> > avail=”0” for each of the objects in the response with an appropriate
> > reason like “Invalid curr