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

From: Adam Roach <[email-masked]>
Date: Mon, 6 Aug 2018 18:51:22 -0500

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
> ------------------------------------------------------------------------
> [email-masked]
>
>     *From:* Adam Roach <mailto:[email-masked]>
>     *Date:* 2018-07-28 07:04
>     *To:* draft-ietf-regext-org-ext
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     *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

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 8 Aug 2018 13:06:51 +0800

Dear Adam,
I have included my feedbacks for the remaining issues. Please see below.

Regards,
Linlin

[email-masked]
 
From: Adam Roach
Date: 2018-08-07 07:51
To: Linlin Zhou; draft-ietf-regext-org-ext; regext
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

[email-masked]
 
From: Adam Roach
Date: 2018-07-28 07:04
To: draft-ietf-regext-org-ext; [email-masked]
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.

 
 
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:
 
>  <extension> element, and the <extension> element MUST contain a child

 

[Linlin]  I've updated some words. Please see the feedback of org draft.
---------------------------------------------------------------------------

§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
 
If the answer is that an error is returned, then that error needs to be 
clearly
specified in this document.

 

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?

 

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

This could do any of the following, and the document needs to be clear which one actually happens:

The command succeeds, and the "reseller" ID is removed from "example.com"
The command fails because "privacyproxy" doesn't exist as an ID on "example.com." No changes are made.
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:
An attempt to remove an ID that does not exist results in an error with a result code of UUUU
An attempt to change an ID that does not exist results in an error with a result code of VVVV
An attempt to add an ID that *does* already exist results in an error with a result code of WWWW
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
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
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>
---------------------------------------------------------------------------

/a

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 8 Aug 2018 13:09:29 +0800

Sorry for some typos, the example should be 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:      <orgext:updData xmlns:orgext="urn:ietf:params:xml:ns:orgext-1.0">
   S:        <orgext:id>res1523</orgext:id>
   S:      </orgext:updData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

[email-masked]
 
From: Linlin Zhou
Date: 2018-08-08 13:06
To: Adam Roach; draft-ietf-regext-org-ext; regext
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

[email-masked]
 
From: Adam Roach
Date: 2018-08-07 07:51

Regards,
Linlin

[email-masked]
 
From: Adam Roach
Date: 2018-07-28 07:04

 

 

 

 
 
§4.2.5:

 
   C:      <orgext:update

 

 

 
   C:      <orgext:update

 

/a

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 9 Aug 2018 10:28:34 +0800

Dear Adam and WG,
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 could refer to an existing association (e.g., attempt to add a link that already exists) or a requested association (e.g., attempt to remove a link that does not exist). The co-authors have discussed this issue and suggested the following changes.

[email-masked]
 
From: Linlin Zhou
Date: 2018-08-08 13:06

Regards,
Linlin

[email-masked]
 
From: Adam Roach
Date: 2018-08-07 07:51

Regards,
Linlin

[email-masked]
 
From: Adam Roach
Date: 2018-07-28 07:04

 

 

 

 
 
§4.2.5:

 
   C:      <orgext:update

 

 

 
   C:      <orgext:update

 

/a

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 9 Aug 2018 11:11:53 +0800

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

[email-masked]
 
From: Linlin Zhou
Date: 2018-08-08 13:06

Regards,
Linlin

[email-masked]
 
From: Adam Roach
Date: 2018-08-07 07:51

Regards,
Linlin

[email-masked]
 
From: Adam Roach
Date: 2018-07-28 07:04

 

 

 

 
 
§4.2.5:

 
   C:      <orgext:update

 

 

 
   C:      <orgext:update

 

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 9 Aug 2018 00:05:59 -0500

Thanks. This all sounds good to me.

/a

On 8/8/18 10:11 PM, Linlin Zhou wrote:
> 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.
> 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.
>     *From:* Linlin Zhou <mailto:[email-masked]>
>     *Date:* 2018-08-08 13:06
>     *To:* Adam Roach <mailto:[email-masked]>;
>     draft-ietf-regext-org-ext
>     <mailto:[email-masked]>; regext
>     <mailto:[email-masked]>
>     *Subject:* Re: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
>     Dear Adam,
>         *Date:* 2018-08-07 07:51
>         *To:* Linlin Zhou <mailto:[email-masked]>;
>         draft-ietf-regext-org-ext
>         <mailto:[email-masked]>; regext
>         <mailto:[email-masked]>
>         *Subject:* Re: [regext] AD Review: draft-ietf-regext-org-ext-07
>         Responses inline.
>
>>         Thanks for your review. I have my feedbacks started with
>>         [Linlin]. I'll update the draft based on your comments.
>>
>>         Regards,
>>         Linlin
>>             <mailto:[email-masked]>;
>>             [email-masked] <mailto:[email-masked]>
>         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
>          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.
>
>
>
>>
>>             [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,
>>
>>

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 9 Aug 2018 07:45:03 +0000

Hi Linlin,

Other RFC’s do not specify the error codes in particular cases (e.g. 5731 does not specify what to return if you remove a linked contact does not exist). But… on the other hand, I think it can be very useful if all Registries use the same error codes for the same use cases.
It’s just that if you start to specify them, you have to be as complete as possible. You can’t randomly pick some cases. There are quite a lot of other cases, so where do we stop? E.g. deleting an organization object which is already linked, add a link for which the organization does not exist, … to just name a few of them.

Isn’t this useful content for some kind of Best Practices document?

Kind regards

Pieter

--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>

[DNS_PUNT_Belgium_RGB]

From: regext <[email-masked]> on behalf of Linlin Zhou <[email-masked]>
Date: Thursday 9 August 2018 at 05:12
To: Adam Roach <[email-masked]>, draft-ietf-regext-org-ext <[email-masked]>, regext <[email-masked]>
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07

Dear Adam and WG,

Regards,
Linlin
________________________________
[email-masked]

From: Linlin Zhou<mailto:[email-masked]>
Date: 2018-08-08 13:06
To: Adam Roach<mailto:[email-masked]>; draft-ietf-regext-org-ext<mailto:[email-masked]>; regext<mailto:[email-masked]>
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
________________________________
[email-masked]

From: Adam Roach<mailto:[email-masked]>
Date: 2018-08-07 07:51
To: Linlin Zhou<mailto:[email-masked]>; draft-ietf-regext-org-ext<mailto:[email-masked]>; regext<mailto:[email-masked]>
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Responses inline.

Regards,
Linlin
________________________________
[email-masked]<mailto:[email-masked]>

From: Adam Roach<mailto:[email-masked]>
Date: 2018-07-28 07:04
To: draft-ietf-regext-org-ext<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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.

§4.2.5:

   C:      <orgext:update

   C:      <orgext:update

  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.

  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

/a

---

From: "Linlin Zhou" <[email-masked]>
Date: Fri, 10 Aug 2018 10:56:42 +0800

Dear Pieter,
Maybe we defined a "role" element for the organizations. I think some of the error cases are referenced with "role" but not with the organization IDs in <update> command. So this is something that is different from RFC5731. From my understanding of AD's comments, this role may lead to some errors that do not happen before. You should have some considerations about these cases.

Regards,
Linlin

[email-masked]
 
From: Pieter Vandepitte
Date: 2018-08-09 15:45
To: Linlin Zhou; Adam Roach; draft-ietf-regext-org-ext; regext
Subject: Re: [regext] AD Review: draft-ietf-regext-org-ext-07
Hi Linlin,

 
Kind regards
 
Pieter
 
-- 
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be

 
 
Dear Adam and WG,

 
Regards,
Linlin

[email-masked]
 
From: Linlin Zhou
Date: 2018-08-08 13:06
 
Regards,
Linlin

[email-masked]
 
From: Adam Roach
Date: 2018-08-07 07:51

Regards,
Linlin

[email-masked]
 
From: Adam Roach
Date: 2018-07-28 07:04

 

 

 

 
 
§4.2.5:

 
   C:      <orgext:update

 

 

   C:      <orgext:update

 

 

 

 

/a