Re: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.txt

["Gould, James" <[e-mail]>]

Gavin,

Thanks for posting the 04 update to the draft.  In reviewing the changes, I have the following feedback:


  1.  I believe you can remove the sentence “The <fee:period> element MUST be present in <check> and <info> commands and responses”, since it conflicts with the start of the paragraph “The <fee:period> element is OPTIONAL in <check> and <info> commands”.  The <fee:period> is OPTIONAL but has a default value of 1 year if omitted.
  2.  The infDataType type supports an OPTIONAL list of <fee:credit> elements, but section 5.1.2 does not include a description of it.
  3.  The domainCDType type supports an OPTIONAL list of <fee:credit> element, but section 5.1.1. does not include a description of it.
  4.  The transfer response as defined in section 5.1.3 does not define the added OPTIONAL <fee:credit> elements.  The use case for inclusion of a <fee:credit> element covers providing any applicable credits to the losing client of a transfer.  For example, an auto renew happened, then a transfer request is executed that applies a credit to the losing client for the auto renew.  Based on this use case, the <fee:fee> element should OPTIONAL, so minOccurs=0 should be defined.  The same holds true for the transfer response in section 5.2.4.  Does it make sense to include the same <fee:credit> information for the losing client for a transfer op=“approve”?
  5.  Support for the OPTIONAL list of <fee:credit> elements in the create, renew, and update responses is supported in the XML schema, but is not described in section 5.2.1, section 5.2.3, and section 5.2.5, respectively.
  6.  The <fee:currency> is required for the <fee:delData> element in the XML schema, but is defined as OPTIONAL in section 5.2.2.  I’m assuming that the XML schema is correct.
  7.  Since the response to the transform commands (create, renew, update) can include both fees and credits, the text “If no fee or credit has been assessed by the server for this transaction, a <fee:XXXData) element MUST NOT be included in the response” should be updated.

To note, I believe making the <fee:fee> element OPTIONAL in item #4 above is the only item that would require a change to the XML schema.

Thanks,


—


JG


[cid:[e-mail]]

James Gould
Distinguished Engineer
[e-mail]

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

VerisignInc.com<http://VerisignInc.com>

On Feb 17, 2015, at 6:47 AM, Gavin Brown <[e-mail]<mailto:[e-mail]>> wrote:

I've just submitted a new version of the fee extension draft for your
review.

9.4. Changes from 03 to 04

  1.  Changed Intended Status to Standards Track.

  2.  As per suggestion from Michael Bauland, the <fee:period> element
      is no longer included in <check> and <info> responses for
      "restore" commands.  It's still mandatory for all other commands.

  3.  Added summary of the attributes for the <fee:fee> element.

  4.  Clarified that the "refundable" and "grace-period" attributes of
      the <fee> fee elements are dependant on each other and cannot
      appear on their own.

  5.  Removed the option of returning a 1001 response when the fee is
      incorrect.

  6.  Forbidden the inclusion of extension elements in transform
      responses if no fee/credit has been assessed.

  7.  Made the <fee:currency> element optional in transform commands.

  8.  Amended XML Namespace section of IANA Considerations, added EPP
      Extension Registry section.

10. TODO


  (Note to RFC Editor: remove this section before publication as an
  RFC.)

  1.  Make the extension object-agnostic so it can be used with other
      objects, not just vanilla domains.

  2.  Change the <check> command so that availability data is not
      returned.

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-04.txt
Date: Tue, 17 Feb 2015 02:16:09 -0800
From: [e-mail]<mailto:[e-mail]>
To: Gavin Brown <[e-mail]<mailto:[e-mail]>>

A new version of I-D, draft-brown-epp-fees-04.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name: draft-brown-epp-fees
Revision: 04
Title: Registry Fee Extension for the Extensible Provisioning Protocol
(EPP)
Document date: 2015-02-17
Group: Individual Submission
Pages: 36
URL:
http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt
Status:         https://datatracker.ietf.org/doc/draft-brown-epp-fees/
Htmlized:       http://tools.ietf.org/html/draft-brown-epp-fees-04
Diff:           http://www.ietf.org/rfcdiff?url2=draft-brown-epp-fees-04

Abstract:
  This document describes an Extensible Provisioning Protocol (EPP)
  extension mapping for registry fees.





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<http://tools.ietf.org>.

The IETF Secretariat


--
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



_______________________________________________
EppExt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/eppext