Subject: [regext] Review of draft-ietf-regext-epp-fees

From: "Gould, James" <[email-masked]>
Date: Thu, 22 Feb 2018 13:44:33 +0000

I did a detailed review of draft-ietf-regext-epp-fees, and below is my feedback:

  1.  The XML namespace “urn:ietf:params:xml:ns:fee-0.25” should be changed to “urn:ietf:params:xml:ns:fee-1.0”
     *   This could wait until after the WGLC, but I want to raise the issue.
  2.  The XML Namespace section should register both the namespace and the XML schema similar to draft-ietf-regext-launchphase.
     *   The URI should start with “urn:”, where the URI field for both the namespace and the XML schema should be urn:ietf:params:xml:ns:fee-1.0
  3.  Put customName in quotes in section 3.1 “Client Commands” as in ‘…uses the “customName” attribute…’.
  4.  The normative reference to draft-ietf-regext-launchphase needs to be changed to an RFC once draft-ietf-regext-launchphase is published as an RFC.

5.      The first sentence of the third paragraph of section 3.2 “Currency Codes” may need to be revised, where it currently states “…the server MUST determine the currency based on the client's account settings which MUST be agreed by the client and server via an out-of-band channel.”  A server that only supports a single server-defined currency will not have client-specific settings and will not require per-client agreement.  My recommendation is to modify this portion of the sentence to read “the server MUST determine the currency based on the server default currency or based on the client’s account settings which are agreed by the client and server via an out-of-band channel.”  I don’t believe the extension requires the normative MUST for the client and server agreement and the extension should support a server default currency.

  1.  Should the reference to “Registry Grace Period extension” in the second paragraph of section 3.4.2 “Grace Periods” refer to RFC3915 instead like with the start of the first paragraph?
  2.  I recommend replacing “ie “ from “(ie <create>…)” to “(e.g. <create>…)” in the second paragraph of section 3.5 “Account Balance” and 3.6 “Credit Limit”.
  3.  The statement about the use of the absolute value of the <fee:balance> being equal to or exceeds the value of the <fee:creditLimit> could be clearer in section 3.6.  I believe that it should read “…absolute value of a negative <fee:balance> being equal ro or exceeds…”.
  4.  You should change ‘“en” English’ to ‘“en” (English)’ in section 3.9 “Reason” to match RFC 5730.
  5.  Modify “All returned failed <fee:command> elements that MUST …” to be “All returned failed <fee:command> element MUST…” in section 3.9 “Reason”.
  6.  Change “for that same domain name” to “for that same object” in section 4 “Server Handling of Fee Information”.
  7.  In section 5.1.1, the <fee:command> “standard” attribute needs to be defined for the <check> command.
  8.  Change “client which” to “client that” or “client, which” in the 3rd, 4th, and 5th paragraphs of section 4 “Server Handling of Fee Information”.
  9.  I believe section 5.1.1.1 “Server Handling of Elements” can be removed, since the client cannot pass the <fee:class> element any longer.
  10. In section 5.1.2, section 5.2.1, section 5.2.2, section 5.2.3, section 5.2.4, and section 5.2.5 , the sentence “when the extension has been selected during a <login> command” could be modified to read “when the extension is included in the <login> command service extensions.”  Similarly, the sentence “, the client selected the extension when it logged in” could be modified to read “, the client included the extension in the <login> command service extensions”.
  11. You may need to add the copyright text in section 6.1 similar to what is included in section 4.1 of draft-ietf-regext-launchphase.
  12. Section 8.1 XML Namespace should be updated as defined below.

This document uses URNs to describe XML namespaces and XML schemas

   conforming to a registry mechanism described in [RFC3688<https://tools.ietf.org/html/rfc3688>].

   Registration request for the launch namespace:

      URI: ietf:params:xml:ns:fee-0.25

      Registrant Contact: IESG

      XML: None.  Namespace URIs do not represent an XML specification.

   Registration request for the launch XML schema:

      URI: ietf:params:xml:ns:fee-0.25

      Registrant Contact: IESG

      XML: See the "Formal Syntax" section of this document.

18.  I recommend changing the section 8.2 EPP Extension Registry “Name of Extension” to match the full name of the extension as in “Registry Fee Extension for the Extensible Provisioning Protocol (EPP)”  and the “Registrant Name and Email Address” field should be set to “IESG, [email-masked]<mailto:[email-masked]>”.

  1.  We may want to add at least one more entry in the Implementation Status section.
  2.  The “Implementation Status” section is misspelled.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

---

From: "James Galvin" <[email-masked]>
Date: Fri, 23 Feb 2018 09:25:01 -0500

Thanks James for this careful review.  Speaking as Chair, I presume this 
review is a result of your preparing the Document Shepherd summary.

In that case the next step is for Roger, as document editor, to review 
these changes and accept them if they are primarily editorial.  If they 
are not then we will need to make sure there are no objections from the 
working group.

If they are primarily editorial then Roger should prepare a revised 
version of the document for you to write the Document Shepherd summary 
so the document can be submitted to the IESG for publication.

Roger?

Thanks,

Antoin and Jim

On 22 Feb 2018, at 8:44, Gould, James wrote:

>   1.  The XML namespace “urn:ietf:params:xml:ns:fee-0.25” should 
> be changed to “urn:ietf:params:xml:ns:fee-1.0”
>   2.  The XML Namespace section should register both the namespace and 
> the XML schema similar to draft-ietf-regext-launchphase.
>      *   The URI should start with “urn:”, where the URI field for 
> both the namespace and the XML schema should be 
> urn:ietf:params:xml:ns:fee-1.0
>   4.  The normative reference to draft-ietf-regext-launchphase needs 
> to be changed to an RFC once draft-ietf-regext-launchphase is 
> published as an RFC.
>
> 5.      The first sentence of the third paragraph of section 3.2 
> “Currency Codes” may need to be revised, where it currently states 
> “…the server MUST determine the currency based on the client's 
> account settings which MUST be agreed by the client and server via an 
> out-of-band channel.”  A server that only supports a single 
> server-defined currency will not have client-specific settings and 
> will not require per-client agreement.  My recommendation is to modify 
> this portion of the sentence to read “the server MUST determine the 
> currency based on the server default currency or based on the 
> client’s account settings which are agreed by the client and server 
> via an out-of-band channel.”  I don’t believe the extension 
> requires the normative MUST for the client and server agreement and 
> the extension should support a server default currency.
>
>   1.  Should the reference to “Registry Grace Period extension” in 
> the second paragraph of section 3.4.2 “Grace Periods” refer to 
> RFC3915 instead like with the start of the first paragraph?
>   2.  I recommend replacing “ie “ from “(ie <create>…)” to 
> “(e.g. <create>…)” in the second paragraph of section 3.5 
> “Account Balance” and 3.6 “Credit Limit”.
>   3.  The statement about the use of the absolute value of the 
> <fee:balance> being equal to or exceeds the value of the 
> <fee:creditLimit> could be clearer in section 3.6.  I believe that it 
> should read “…absolute value of a negative <fee:balance> being 
> equal ro or exceeds…”.
>   4.  You should change ‘“en” English’ to ‘“en” 
> (English)’ in section 3.9 “Reason” to match RFC 5730.
>   5.  Modify “All returned failed <fee:command> elements that MUST 
> …” to be “All returned failed <fee:command> element MUST…” 
> in section 3.9 “Reason”.
>   6.  Change “for that same domain name” to “for that same 
> object” in section 4 “Server Handling of Fee Information”.
>   7.  In section 5.1.1, the <fee:command> “standard” attribute 
> needs to be defined for the <check> command.
>   8.  Change “client which” to “client that” or “client, 
> which” in the 3rd, 4th, and 5th paragraphs of section 4 “Server 
> Handling of Fee Information”.
>   9.  I believe section 5.1.1.1 “Server Handling of Elements” can 
> be removed, since the client cannot pass the <fee:class> element any 
> longer.
>   10. In section 5.1.2, section 5.2.1, section 5.2.2, section 5.2.3, 
> section 5.2.4, and section 5.2.5 , the sentence “when the extension 
> has been selected during a <login> command” could be modified to 
> read “when the extension is included in the <login> command service 
> extensions.”  Similarly, the sentence “, the client selected the 
> extension when it logged in” could be modified to read “, the 
> client included the extension in the <login> command service 
> extensions”.
>   11. You may need to add the copyright text in section 6.1 similar to 
> what is included in section 4.1 of draft-ietf-regext-launchphase.
>    conforming to a registry mechanism described in 
> [RFC3688<https://tools.ietf.org/html/rfc3688>].
>
>
>
> 18.  I recommend changing the section 8.2 EPP Extension Registry 
> “Name of Extension” to match the full name of the extension as in 
> “Registry Fee Extension for the Extensible Provisioning Protocol 
> (EPP)”  and the “Registrant Name and Email Address” field should 
> be set to “IESG, [email-masked]<mailto:[email-masked]>”.
>

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Roger D Carney <[email-masked]>
Date: Fri, 23 Feb 2018 14:28:23 +0000

Good Morning,

Thanks Jims!

I will have a new version posted next week.

Thanks
Roger

________________________________
From: regext <[email-masked]> on behalf of James Galvin <[email-masked]>
Sent: Friday, February 23, 2018 8:25 AM
To: Gould, James
Cc: [email-masked]
Subject: Re: [regext] Review of draft-ietf-regext-epp-fees

Thanks James for this careful review. Speaking as Chair, I presume this review is a result of your preparing the Document Shepherd summary.

In that case the next step is for Roger, as document editor, to review these changes and accept them if they are primarily editorial. If they are not then we will need to make sure there are no objections from the working group.

If they are primarily editorial then Roger should prepare a revised version of the document for you to write the Document Shepherd summary so the document can be submitted to the IESG for publication.

Roger?

Thanks,

Antoin and Jim

      Registrant Contact: IESG

      Registrant Contact: IESG

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

---

From: "Gould, James" <[email-masked]>
Date: Fri, 23 Feb 2018 14:41:22 +0000

Jim,

Yes, this review is the result of preparing the Document Shepherd summary.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com<http://verisigninc.com/>
From: James Galvin <[email-masked]>
Date: Friday, February 23, 2018 at 9:25 AM
To: James Gould <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Review of draft-ietf-regext-epp-fees

Roger?

Thanks,

Antoin and Jim

1.   The XML namespace “urn:ietf:params:xml:ns:fee-0.25” should be changed to “urn:ietf:params:xml:ns:fee-1.0”
a.   This could wait until after the WGLC, but I want to raise the issue.
2.   The XML Namespace section should register both the namespace and the XML schema similar to draft-ietf-regext-launchphase.
a.   The URI should start with “urn:”, where the URI field for both the namespace and the XML schema should be urn:ietf:params:xml:ns:fee-1.0
3.   Put customName in quotes in section 3.1 “Client Commands” as in ‘…uses the “customName” attribute…’.
4.   The normative reference to draft-ietf-regext-launchphase needs to be changed to an RFC once draft-ietf-regext-launchphase is published as an RFC.

5.      The first sentence of the third paragraph of section 3.2 “Currency Codes” may need to be revised, where it currently states “…the server MUST determine the currency based on the client's account settings which MUST be agreed by the client and server via an out-of-band channel.”  A server that only supports a single server-defined currency will not have client-specific settings and will not require per-client agreement.  My recommendation is to modify this portion of the sentence to read “the server MUST determine the currency based on the server default currency or based on the client’s account settings which are agreed by the client and server via an out-of-band channel.”  I don’t believe the extension requires the normative MUST for the client and server agreement and the extension should support a server default currency.
6.   Should the reference to “Registry Grace Period extension” in the second paragraph of section 3.4.2 “Grace Periods” refer to RFC3915 instead like with the start of the first paragraph?
7.   I recommend replacing “ie “ from “(ie <create>…)” to “(e.g. <create>…)” in the second paragraph of section 3.5 “Account Balance” and 3.6 “Credit Limit”.
8.   The statement about the use of the absolute value of the <fee:balance> being equal to or exceeds the value of the <fee:creditLimit> could be clearer in section 3.6.  I believe that it should read “…absolute value of a negative <fee:balance> being equal ro or exceeds…”.
9.   You should change ‘“en” English’ to ‘“en” (English)’ in section 3.9 “Reason” to match RFC 5730.
10.   Modify “All returned failed <fee:command> elements that MUST …” to be “All returned failed <fee:command> element MUST…” in section 3.9 “Reason”.
11.   Change “for that same domain name” to “for that same object” in section 4 “Server Handling of Fee Information”.
12.   In section 5.1.1, the <fee:command> “standard” attribute needs to be defined for the <check> command.
13.   Change “client which” to “client that” or “client, which” in the 3rd, 4th, and 5th paragraphs of section 4 “Server Handling of Fee Information”.
14.   I believe section 5.1.1.1 “Server Handling of Elements” can be removed, since the client cannot pass the <fee:class> element any longer.
15.   In section 5.1.2, section 5.2.1, section 5.2.2, section 5.2.3, section 5.2.4, and section 5.2.5 , the sentence “when the extension has been selected during a <login> command” could be modified to read “when the extension is included in the <login> command service extensions.”  Similarly, the sentence “, the client selected the extension when it logged in” could be modified to read “, the client included the extension in the <login> command service extensions”.
16.   You may need to add the copyright text in section 6.1 similar to what is included in section 4.1 of draft-ietf-regext-launchphase.
17.   Section 8.1 XML Namespace should be updated as defined below.

      Registrant Contact: IESG

      Registrant Contact: IESG

18.  I recommend changing the section 8.2 EPP Extension Registry “Name of Extension” to match the full name of the extension as in “Registry Fee Extension for the Extensible Provisioning Protocol (EPP)”  and the “Registrant Name and Email Address” field should be set to “IESG, [email-masked]<mailto:[email-masked]>”.
19.   We may want to add at least one more entry in the Implementation Status section.
20.   The “Implementation Status” section is misspelled.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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