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

2018-08-08 Thread Linlin Zhou 
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.

An EPP error response MUST be returned if an  command cannot be 
processed for any reason. 



zhoulin...@cnnic.cn
 
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


zhoulin...@cnnic.cn
 
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


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-07-28 07:04
To: draft-ietf-regext-org-ext; 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
>   element, and the  element MUST contain a child
>   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  and 
.
 
[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:  
   C:
   C:  
   C:
   C:  
 
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 .


Is the answer the same for  as for ?


Similarly, if  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  element contains multiple  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:  
   C:
   C:  
   C:  
   C:
   C:  


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 r

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

2018-08-08 Thread Linlin Zhou 
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  or  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  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
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


zhoulin...@cnnic.cn
 
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


zhoulin...@cnnic.cn
 
From: Adam Roach
Date: 2018-07-28 07:04
To: draft-ietf-regext-org-ext; 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
>   element, and the  element MUST contain a child
>   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  and 
.
 
[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:  
   C:
   C:  
   C:
   C:  
 
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 .


Is t

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

2018-08-08 Thread Adam Roach 

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  or  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  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 
*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

zhoulin...@cnnic.cn

*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

zhoulin...@cnnic.cn

*From:* Adam Roach 
*Date:* 2018-07-28 07:04
*To:* draft-ietf-regext-org-ext
;
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
>   element, and the  element MUST
contain a child
>   element that identifies the extension
namespace if
>  the client wants to associate data defined in this
extension to the
>  object.
I presume the same ans