Subject: [eppext] Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP)

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 6 Feb 2015 13:40:41 +0000

IANA has received a request to register an EPP extension titled "Registry Fee Extension for the Extensible Provisioning Protocol (EPP)". Per RFC 7451 they have requested designated expert review of the request. The list of designated experts appointed by the IESG can be found IANA's registry web page:

http://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml#epp-extensions-1

This is the form received by IANA:

-----BEGIN FORM-----
Name of Extension:
Registry Fee Extension for the Extensible Provisioning Protocol (EPP)

Document Status: Informational

Reference: http://tools.ietf.org/html/draft-brown-epp-fees

Registrant Name and Email Address:
Gavin Brown, <[email-masked]>

TLDs: any

IPR Disclosure: None

Status: Active

Notes: None

-----END FORM-----

As specified in RFC 7451 the discussion of this request is to take place on this mailing list. So let's discuss it.

I have no issue with the extension itself. Given that this request refers to an existing Internet-Draft document, I believe it would be more appropriate for the document to include an IANA Considerations section that includes a request to register the extension if the document becomes an RFC. My recommendation to IANA would be to hold off on processing the request until the document is either submitted to and approved by the IESG or it is published outside the IETF process.

Would the other designated experts please share the results of your individual evaluations in this thread.

Scott

---

From: Ning Kong <[email-masked]>
Date: Wed, 11 Feb 2015 10:19:08 +0800

Hi Scott and all,

As one of the designated experts, I read this request and draft. I have some comments as follows.

#1 The document status is Informational according to the request, but the intended status of draft is Experimental.

#2 IMO, the extension of <check> is not necessary. It seems that the extended <check> is a little overused. I think the extension of <info> is enough.

#3 I’m afraid this extension may increase the risk of Security and Privacy. The fee information of domain registration is sensitive and maybe trade secrets for most registrars and registries.  Because different registrars would get different price based on their each commercial contract. So usually the fee information can only be known by the business people. But if the EPP is extended with the fee function, the sensitive information about fee may be accessed by the technical guys even through the log file of EPP system.

Regards,
Ning

> 在 2015年2月6日，下午9:40，Hollenbeck, Scott <[email-masked]> 写道：
> 
> _______________________________________________
> EppExt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eppext

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 12 Feb 2015 01:39:24 +0000

All,

> I have no issue with the extension itself. Given that this request refers to an
> existing Internet-Draft document, I believe it would be more appropriate for
> the document to include an IANA Considerations section that includes a
> request to register the extension if the document becomes an RFC. My
> recommendation to IANA would be to hold off on processing the request
> until the document is either submitted to and approved by the IESG or it is
> published outside the IETF process.

I do agree with Scott that the registration details should go into the IANA considerations section of the document, using the template from RFC7451. Basically, i also agree that the registration should be held off until publication, if the intended goal of the document is publication as an RFC. 

I understand the document describes one of the candidate extensions that could be adopted as WG items once EPPEXT recharters. My recommendation above is based on this assumption. However, i'm slightly concerned about the current level of progress of the rechartering / scope work, and hence i do also recommend that the author should consider restarting the registration request once the final direction for the publication path of the document  is clear.

Alex

---

From: Gavin Brown <[email-masked]>
Date: Fri, 13 Feb 2015 13:13:11 +0000

> #2 IMO, the extension of <check> is not necessary. It seems that the extended <check> is a little overused. I think the extension of <info> is enough.

There has been some discussion of this point on this list; there seemed
to be no consensus for using <check> only or <info> only. In the
interests of pleasing the most number of people, I chose to support both.

I would be happy to revisit this question again as my personal
preference would be to only support one query command.

> #3 I’m afraid this extension may increase the risk of Security and Privacy. The fee information of domain registration is sensitive and maybe trade secrets for most registrars and registries.  Beca…

This is an interesting point. I will think about adding a Security
Considerations section to the draft which addresses this concern.

G.

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

---

From: "Gould, James" <[email-masked]>
Date: Fri, 13 Feb 2015 13:37:38 +0000

Ning,

I provide some feedback below to your feedback.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On Feb 10, 2015, at 9:19 PM, Ning Kong <[email-masked]<mailto:[email-masked]>> wrote:

Hi Scott and all,

I believe this draft should be targeted for Standards track based on the amount of interest in it by the community.  I believe it is passed Experimental and it is certainly being looked at by multiple independent parties.  Hopefully the EPPEXT WG will be re-charted to include this draft.

I believe the draft should stay as is.  Since the fee draft is an extension and not an object mapping, how would you represent the price for a non-existing domain name using an extension of the info command?  The extension really could not extend the info response for a non-existing domain name since RFC 5731 requires the name, roid, and clID element to be returned in the response.  As is, the extension to the check command and response enables a client to get pricing information for existing and non-existing domain names, and the extension to the info command and response enables a client to get the pricing information for an existing domain name.

I don’t agree with this feedback.  The client system needs to know the fee to ensure that the expected fee will or is going to be charged by the server.  I don’t believe this can only be known by a client business person.  The extension is optional and the business person can decide to require the client system to support the fee extension or not.  The security practices of the client for disclosure of the fee information is up to the client to define and enforce, and really does not play into the protocol between the client and the server.

Regards,
Ning

在 2015年2月6日，下午9:40，Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> 写道：

-----BEGIN FORM-----
Name of Extension:

TLDs: any

IPR Disclosure: None

Status: Active

Notes: None

-----END FORM-----

Scott

_______________________________________________
EppExt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext