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.
---------------------------------------------------------------------------
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.
---------------------------------------------------------------------------
The resolution to the remaining issues all seem fine to me. Thanks.
/a
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
