Dear Adam and WG,
Sorry, please ignore last unfinished letter.
We've received some comments on the appropriate error codes.
Since draft-ietf-regext-org-ext is a command / response extension of another object that is related to a link attribute,
2305 seems like a more proper error code for all of them, which means
"Object association prohibits operation". The association dould refer
to an existing association (e.g., attempt to add alink that already
exists) or a requested association (e.g. attempt to remove a link that
does not exist).
We found that in RFC5730 , the document already defined the response
format with error value elements using <value> or <extValue> for an
object. So we suggest not defining the specific response format in
this command/response extension.
The co-authors have discussed this issue and suggested the following
changes.
An EPP error response MUST be returned if an <update> command cannot
be processed for any reason.
An attempt to add one organization ID or multiple organization IDs
with a particular role value when at least one of them already exists
does not change the object at all. A server SHOULD notify clients that
object relationsips exit by sending a 2305 error response code.
An attempt to remove an organization ID or multiple organization IDs
with a particular role value when
at least one of them does not exist does not change the object at all.
A server SHOULD notify clients that object relationships does not
exist by sending a 2305 error response code.
An attempt to change an organiztion ID or multiple organization IDs
with a particular role value when at least one of them does not exist
does not change the object at all. A server SHOULD notify clients that
object relationships does not eixt by sending a 2305 error response code.
Response format with error value elements is defined in section 2.6 of
RFC5730.
Regards,
Linlin
------------------------------------------------------------------------
zhoulin...@cnnic.cn
*From:* Linlin Zhou <mailto:zhoulin...@cnnic.cn>
*Date:* 2018-08-08 13:06
*To:* Adam Roach <mailto:a...@nostrum.com>;
draft-ietf-regext-org-ext
<mailto:draft-ietf-regext-org-...@tools.ietf.org>; regext
<mailto:regext@ietf.org>
*Subject:* Re: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Dear Adam,
I have included my feedbacks for the remaining issues. Please see
below.
Regards,
Linlin
------------------------------------------------------------------------
zhoulin...@cnnic.cn
*From:* Adam Roach <mailto:a...@nostrum.com>
*Date:* 2018-08-07 07:51
*To:* Linlin Zhou <mailto:zhoulin...@cnnic.cn>;
draft-ietf-regext-org-ext
<mailto:draft-ietf-regext-org-...@tools.ietf.org>; regext
<mailto:regext@ietf.org>
*Subject:* Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Responses inline.
On 7/30/18 1:21 AM, Linlin Zhou wrote:
Dear Adam,
Thanks for your review. I have my feedbacks started with
[Linlin]. I'll update the draft based on your comments.
Regards,
Linlin
------------------------------------------------------------------------
zhoulin...@cnnic.cn
*From:* Adam Roach <mailto:a...@nostrum.com>
*Date:* 2018-07-28 07:04
*To:* draft-ietf-regext-org-ext
<mailto:draft-ietf-regext-org-...@tools.ietf.org>;
regext@ietf.org <mailto:regext@ietf.org>
*Subject:* [regext] AD Review: draft-ietf-regext-org-ext-07
This is my AD review for draft-ietf-regext-org-ext-07. I
have a handful of
comments below that I'd like to see addressed prior to
asking the IESG to
consider the document. Please treat them as you would any
other last-call
comments.
There are also two blocking comments that need to be
resolved prior to
IETF last
call.
Thanks to everyone who worked on this document.
---------------------------------------------------------------------------
This is a blocking comment.
This document raises the same question as
draft-ietf-regext-org-08 does
regarding the allowable placement of XML namespace
declarations within the
document; see, e.g., the following text:
> In addition to the EPP command elements
> described in the EPP object extensions, the command
MUST contain an
> <extension> element, and the <extension> element MUST
contain a child
> <orgext:create> element that identifies the extension
namespace if
> the client wants to associate data defined in this
extension to the
> object.
I presume the same answer will apply to this document as
does to
draft-ietf-regext-org-08.
Affected elements appear to also include <orgext:update> and
<orgext:infData>.
[Linlin] Please see my feedback in the reply of org
draft. Thanks.
I assume we'll resolve this the same way in both documents.
[Linlin] I've updated some words. Please see the feedback of
org draft.
---------------------------------------------------------------------------
This is a blocking comment, as it impacts interoperability.
§4.2.5:
This section defines remove and change elements that use
"role" as a key. It
is unclear whether an attempt to remove or change an
identifier
corresponding to
a role that is not present in the object results in an
error, or is
treated as
success.
For example, if an "example.com" is currently in the
system as a
reseller, but
is *not* in the system as a privacyproxy, would an update
containing the
following elements return a success response or an error
response?
C: <orgext:update
C: xmlns:orgext="urn:ietf:params:xml:ns:orgext-1.0">
C: <orgext:rem>
C: <orgext:id role="privacyproxy"/>
C: </orgext:rem>
C: </orgext:update>
If the answer is that an error is returned, then that
error needs to be
clearly
specified in this document.
[Linlin]I think an error should be returned.
Okay -- we need to say which error code to use, then.
The same question needs to be answered for <orgext:chg>.
Is the answer the same for <orgext:chg> as for <orgext:rem>?
Similarly, if <orgext:add> is issued for a role that
already exists in the
object, does this result in an error, or is the existing
role identifier
silently overridden?
This question also needs an answer.
If the answer to "is this an error" is "yes" for any or
all of the
preceding questions: this document needs to clearly spell
out what
happens when
an <orgext:...> element contains multiple <orgext:id>
elements, and
*some* of
them cause an error while *some* of them do not.
This also still needs to be addressed. For example:
If "example.com" is currently in the system as a reseller, but
is *not* in the system as a privacyproxy, what would the
following command do?
C: <orgext:update
C: xmlns:orgext="urn:ietf:params:xml:ns:orgext-1.0">
C: <orgext:rem>
C: <orgext:id role="reseller"/>
C: <orgext:id role="privacyproxy"/>
C: </orgext:rem>
C: </orgext:update>
This could do any of the following, and the document needs to
be clear which one actually happens:
1. The command succeeds, and the "reseller" ID is removed
from "example.com"
2. The command fails because "privacyproxy" doesn't exist as
an ID on "example.com." No changes are made.
3. The command partially succeeds: the "reseller" ID is
removed from "example.com," but the response is an error
message because "privacyproxy" could not be returned.
The semantics around #3 are very complicated, since you'll
ultimately need to indicate which part of the command
succeeded and which part failed, so you probably want to pick
#1 or #2. Given your answer above that removing a non-existent
orgext-ID from an object is a failure, I think #2 is the most
consistent. But this needs to be clearly specified.
Finally, if the <orgext:add> and <orgext:chg> elements do
not result in
errors
in the cases described above, then this document should
clearly specify how
processing is different between those two elements, or
clearly specify that
handling of both elements is identical.
[Linlin] So is it ok to add some words like "An EPP error
response MUST be returned if an <update> command cannot
be processed for any reason." ?
That's really not enough. You need to be very clear about what
"cannot be processed" means. And, since you have commands that
perform more than one operation at the same time, you need to
be very clear about handling when one of those operations
would be okay, but the other one is not.
I don't want to tell you how to resolve each of these issues;
but, based on the one answer you gave above (about removing a
non-existent ID), the following clarifications would be
consistent:
1. An attempt to remove an ID that does not exist results in
an error with a result code of UUUU
2. An attempt to change an ID that does not exist results in
an error with a result code of VVVV
3. An attempt to add an ID that *does* already exist results
in an error with a result code of WWWW
4. An attempt to remove more than one ID where at least one
of them does not exist does not change the object at all,
and results in an error with a result code of XXXX
5. An attempt to change multiple IDs where at least one of
them does not exist does not change the object at all, and
results in an error with a result code of YYYY
6. An attempt to add multiple IDs when at least one of them
already exists does not change the object at all, and
results in an error with a result code of YYYY
You will need to say all six things. Also, for #4, #5, and #6,
you'll need to think about whether there is any way for the
client to know which ID caused the operation to fail
Note that the result codes above might be the same as each
other or different from each other. I have no opinion on which
is better, as I'm not familiar with the philosophy of how
result codes are used in EPP.
[Linlin] Thanks for your suggestions. Adding some words at the
end of this section. I think error codes 2302 and 2303 defined
in RFC5730 could be used.
An EPP error response MUST be returned if an <update>
command cannot be processed for any reason.
An attempt to add an organization ID that does already
exist results in an error with a result code of 2302. An
attempt to add multiple organization IDs when at least
one of them already exists does not change the object at
all, and results in an error with a result code of 2302.
An attempt to remove an organization ID that does not
exist results in an error with a result code of 2303. An
attempt to remove more than one ID where at least one of
them does not exist does not change the object at all,
and results in an error with a result code of 2303.
An attempt to change an ID that does not exist results in
an error with a result code of 2303. An attempt to add
multiple IDs when at least one of them already exists
does not change the object at all, and results in an
error with a result code of 2303.
If we want to identify which ID is the failing one, I
think maybe we need to extend the <update> response.
Something like this,
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="2302">
S: <msg>Object exists</msg>
S: </result>
S: <resData>
S: <org:updData xmlns:org="urn:ietf:params:xml:ns:orgext-1.0">
S: <org:id>res1523</org:id>
S: </org:updData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
<element name="updData" type="orgext:updDataType"/>
<complexType name="updDataType">
<sequence>
<element name="id" type="eppcom:clIDType" minOccurs="0"/>
</sequence>
</complexType>
---------------------------------------------------------------------------
The resolution to the remaining issues all seem fine to me.
Thanks.
/a
