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

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 1 Apr 2015 15:02:50 +0000

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?

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

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

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

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

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., [email-masked]
> 
> TLDs: Any
> 
> IPR Disclosure: None
> 
> Status: Active
> 
> Notes: None
> -----END FORM-----
> 
> —
> 
> 
> JG
> 
> 
> 
> 
> 
> James Gould
> Distinguished Engineer
> [email-masked]
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eppext

---

From: "Gould, James" <[email-masked]>
Date: Wed, 1 Apr 2015 15:40:24 +0000

Alex,

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

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On Apr 1, 2015, at 11:02 AM, Alexander Mayrhofer <[email-masked]<mailto:[email-masked]>> wrote:

All,

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

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.

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.

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.

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:

Document Status:
Informational

Reference:

TLDs: Any

IPR Disclosure: None

Status: Active

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

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

VerisignInc.com

image/png 4KiB

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 3 Apr 2015 11:18:44 +0000

I've completed my review of this extension. Only one comment: it would be nice to see a real example of a key:value pair to better understand possible uses of this extension.

I'm not aware of any conflicts with IETF work or other extensions.

Scott

> -----Original Message-----
> From: EppExt [mailto:[email-masked]] On Behalf Of Hollenbeck,
> Scott
> Sent: Monday, March 23, 2015 1:36 PM
> To: [email-masked]
> Subject: [eppext] FW: [IANA #814703] INSERT “Common Object Attribute
> (COA) Extension for the Extensible Provisioning Protocol (EPP) "
> 
> FYI. DEs, we have two weeks to review this and several other
> registration requests that I will forward momentarily. Please review
> section 2.1.1 of RFC 7451 for the DE evaluation criteria.
> 
> Each DE needs to explicitly note that they have completed their review
> of each request. When all reviews have been completed (or two weeks of
> time have passed for evaluations not received) I will send a
> confirmation note to IANA.
> 
> Scott
> 
> -----Original Message-----
> From: Amanda Baber via RT [mailto:[email-masked]]
> Sent: Monday, March 23, 2015 12:24 PM
> Cc: Hollenbeck, Scott
> Subject: [IANA #814703] INSERT “Common Object Attribute (COA) Extension
> for the Extensible Provisioning Protocol (EPP) "
> 
> Hi Scott,
> 
> This is #1 of 18 from James Gould.
> 
> thanks,
> Amanda
> 
> 
> -----BEGIN FORM-----
> Name of Extension:
> “Common Object Attribute (COA) Extension for the Extensible
> Provisioning Protocol (EPP)"
> 
> Document Status:
> Informational
> 
> Reference:
> “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.”
>

---

From: Roger D Carney <[email-masked]>
Date: Mon, 6 Apr 2015 13:55:02 +0000

I have completed my review of this extension and I have no significant comments. 

Minor comments:  
- I agree that a clarification on uniqueness of keys would be a benefit.
- I assume just a typo in Section 3.2.5, I assume child elements should be <coa:rem> and <coa:put> not <caa:rem> and <caa:put>

Thanks
Roger

-----Original Message-----
From: EppExt [mailto:[email-masked]] On Behalf Of Alexander Mayrhofer
Sent: Wednesday, April 01, 2015 10:03 AM
To: Hollenbeck, Scott; [email-masked]
Subject: Re: [eppext] [IANA #814703] INSERT “Common Object Attribute (COA) Extension for the Extensible Provisioning Protocol (EPP) "

All,

tia & thanks,
Alex

> received this message in error, notify sender immediately and delete this message immediately.”
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 6 Apr 2015 21:25:56 +0000

I have sent a note to IANA indicating DE approval for this request.

Scott

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 7 Apr 2015 17:46:45 +0200

Hollenbeck, Scott <[email-masked]> 2015-04-03 13:19
> I'm not aware of any conflicts with IETF work or other extensions.

Not a conflict but there is another similar extension, that could be a
subset of this generic key:value extension

Under the namespace of urn:ietf:params:xml:ns:neulevel-1.0
(possibly used for .TRAVEL, updates welcome)
you can have for commands
<neulevel:unspec>UIN=something</neulevel:unspec>
or
<neulevel:unspec>RestoreReasonCode=something RestoreComment=something TrueData=Y ValidUse=Y UIN=something</neulevel:unspec>

HTH,

-- 
Patrick Mevzek
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.  -- George Bernard Shaw