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

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

Ning,

I provide some feedback below to your feedback.


—


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 10, 2015, at 9:19 PM, Ning Kong <[e-mail]<mailto:[e-mail]>> wrote:


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.

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.


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


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.

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


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 <[e-mail]<mailto:[e-mail]>> 写道：

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, <[e-mail]>

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

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


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