Re: [eppext] [IANA #814703] INSERT “Common Object Attribute (COA) Extension for the Extensible Provisioning Protocol (EPP) "

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

Alex,

Thank you for the review and thoughtful comments.  I provide feedback to your comments below.


—


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 Apr 1, 2015, at 11:02 AM, Alexander Mayrhofer <[e-mail]<mailto:[e-mail]>> wrote:

All,

As one of the assigned Designated Experts, I've completed my review of the extension and I have the following (minor) comments:

- From reading the " VERISIGN PROPRIETARY INFORMATION" paragraph, i understand that i cannot "copy or communicate" the documentation under the link without "written prior consent of Verisign". I'm not a legal person, but personally i find this an restriction that is inappropriate for a public web page, because i can hardly even "view" the web page without my web browser "copying" it to its cache ... Anyways, i understand that such "boilerplates" are a requirement of many companies, and this probably stems from a paper version of this document?


Yes, this is standard Verisign copyright language that is applied to all of the proprietary extensions.


- I do understand the XML namespace URI currently used in the document is not yet registered in the IANA XML registry, and i suggest that authors register it accordingly once the EPP extension itself is registered.

By convention, all of the custom Verisign extensions used a URI starting with “http://www.verisign-grs.com/epp/” or “http://www.versisign.com/epp/”, since there was no intent on them being used outside of the Verisign registries.  We will consider registering these URI’s independently with the IANA XML registry.


- I didn't see in the document whether or not a certain KEY could be used multiple times for a single object, or not. Clarifying this could improve interopability, and Section 2.1 would probably be an appropriate place. From the description of the "update" command, the KEY seems to be used to identify a certain Key/Value pair, so duplicate KEYs are likely not intended?


You are correct, this is Verisign’s version of a key/value pair extension, where the keys are unique and cannot be duplicated.  We could look to make that clearer in the extension.

- The specification is silent about error conditions, and does not recommend any specific EPP error codes for specific situations (eg. when an "update" tries to remove an attribute that is not set for an object, or when an attribute is not allowed due to server policy).


Good point; although the EPP RFC 5730 provides a good set of error codes that map well to most common use cases (e.g. 2303 “Object does not exist” for an “update” that tries to remove a non-existent key or 2306 “Parameter value policy error” for a non-supported key) in the extension.  We could consider adding more guidance to the error conditions in the extension.

- Security: The specification does not specify whether or not CoA's provisioning by client A are returned to the info response for client B. I hence understand that this is server policy? If there are any restrictions on server policy in this regard, those should be listed - or, alternatively, it should be clarified that this is individual server policy.


In general, keys set by client A will not be available to B in an info response, but there may be some keys that are less restrictive.  The actual keys supported and the policies for the keys would be defined outside of the extension, so we could consider adding clarifying text about the keys being defined external to the extension along with their security requirements.


tia & thanks,
Alex

-----BEGIN FORM-----
Name of Extension:
“Common Object Attribute (COA) Extension for the Extensible Provisioning
Protocol (EPP)"

Document Status:
Informational

Reference:
http://www.verisigninc.com/assets/epp-sdk/verisign_epp-
extension_coa_v00.html

Registrant Name and Email Address:
VeriSign Inc., [e-mail]

TLDs: Any

IPR Disclosure: None

Status: Active

Notes: None
-----END FORM-----

—


JG





James Gould
Distinguished Engineer
[e-mail]

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

VerisignInc.com

“This message (including any attachments) is intended only for the use of the
individual or entity to which it is addressed, and may contain information that
is non-public, proprietary, privileged, confidential and exempt from
disclosure under applicable law or may be constituted as attorney work
product. If you are not the intended recipient, you are hereby notified that
any use, dissemination, distribution, or copying of this communication is
strictly prohibited. If you have received this message in error, notify sender
immediately and delete this message immediately.”

Download BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png

image/png 4KiB

_______________________________________________
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