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

2018-08-07 Thread Adam Roach 

Your proposed resolutions sound fine to me. Thanks!

/a

On 8/7/18 1:23 AM, Linlin Zhou wrote:

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:27
*To:* Linlin Zhou ; regext
; draft-ietf-regext-org

*Subject:* Re: [regext] AD Review: draft-ietf-regext-org
On 7/28/18 3:00 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-27 09:35
*To:* regext@ietf.org ;
draft-ietf-regext-org

*Subject:* [regext] AD Review: draft-ietf-regext-org
This is my AD review for draft-ietf-regext-org-08.  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.
I also have one comment that needs to be addressed prior to
IETF last call.
Thanks to everyone who worked on this document.

---
This comment (and only this comment) is blocking, and needs
to be addressed
prior to IETF last call.
§4.1.1:
>  In addition to the standard EPP command elements, the
 command
>  MUST contain a  element that identifies the
organization
>  namespace.
Is the intention here to be more restrictive than normal XML
namespace
handling? For example: is it intended to outlaw cases in
which the org
namespace is defined in an ancestor element? Given that the
rest of XML
processing is in line with normal XML behavior, this
exception would
need some
justification in this document, or a citation to a document that
provides such
justification.
This issue arises in other parts of the document for
,
, , , ,
,
, and .
 [Linlin] Take the  command as an example. In RFC 5730
section 2.9.2.1, it is said that,
In addition to the standard EPP command elements, the  command 
contains the following child elements:

   -  An object-specific  element that identifies the objects
  to be queried.  Multiple objects of the same type MAY be queried
  within a single  command.
The  is specified by a certain object using EPP
extension framwork which is not in the standard EPP command
elements.

And in RFC 5730 section 2..7.2,
protocol elements that contain data specific to objects are
identified using XML namespace notation with a reference to an XML 
schema that defines the namespace.
For example,
 C:
 C:  
 C:
 C:  
 C:

So the newly added organization object has the namespace
.

In RFC 5731, 5732 and 5733, some words such as
" In addition to the standard EPP command elements, the  command MUST 
contain a  element that identifies the domain namespace.",
are explicitly written to say that you should have
, etc. under a certain command or
response. To inline with the previous EPP object RFCs, so we
use the same text to express that we have an
organization-specific command element.




Sure. The issue I'm seeing here is that, in XML, the following
snippets are semantically identical:

 C:
 C:  
 C:
 C:  
 C:

 C:
 C:  
 C:
 C:  
 C:

However, the current text appears to allow the first while
outlawing the second.

[Linlin] How about "In addition to the standard EPP command
elements, the  command MUST contain a  element.
This element or its ancestor element MUST identify the
organization namespace."
The same changes will be applied to other parts of this document
for , , , ,
, , , and .



---

§5, Page 34:
>   
> 
>   
>       minOccurs="0"/>
> 
>   
The "reason" element needs to have a "maxOccurs" of greater
than one
(presumably "unbounded") to allow for the conveyance of

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

2018-08-07 Thread Linlin Zhou 
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 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  and  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  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, si

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

2018-08-07 Thread Linlin Zhou 
Sorry for some typos, the example should be like this,

  S:
   S:
   S:  
   S:
   S:  Object exists
   S:
   S:
   S:  
   S:res1523
   S:  
   S:
   S:
   S:  ABC-12345
   S:  54321-XYZ
   S:
   S:  
   S:



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 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  and  elements do not result in