Re: [regext] AD Review: draft-ietf-regext-org-ext-07

[Adam Roach <[e-mail]>]

Thanks. This all sounds good to me.

/a

On 8/8/18 10:11 PM, Linlin Zhou wrote:
> 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
> ------------------------------------------------------------------------
> [e-mail]
>
>     *From:* Linlin Zhou <mailto:[e-mail]>
>     *Date:* 2018-08-08 13:06
>     *To:* Adam Roach <mailto:[e-mail]>;
>     draft-ietf-regext-org-ext
>     <mailto:[e-mail]>; regext
>     <mailto:[e-mail]>
>     *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
>     ------------------------------------------------------------------------
>     [e-mail]
>
>         *From:* Adam Roach <mailto:[e-mail]>
>         *Date:* 2018-08-07 07:51
>         *To:* Linlin Zhou <mailto:[e-mail]>;
>         draft-ietf-regext-org-ext
>         <mailto:[e-mail]>; regext
>         <mailto:[e-mail]>
>         *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
>>         ------------------------------------------------------------------------
>>         [e-mail]
>>
>>             *From:* Adam Roach <mailto:[e-mail]>
>>             *Date:* 2018-07-28 07:04
>>             *To:* draft-ietf-regext-org-ext
>>             <mailto:[e-mail]>;
>>             [e-mail] <mailto:[e-mail]>
>>             *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
>
>