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

Dear Adam,
Thanks for your review. I have my feedbacks started with [Linlin]. I'll update the draft based on your comments.

Regards,
Linlin

zhoulinlin@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
>  <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.
---------------------------------------------------------------------------

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.

The same question needs to be answered for <orgext:chg>. Additionally: if no
error is returned, then behavior for <orgext:chg> needs to clearly spell out
whether attempts to update a role that is not already present in the object
causes that role to be added, or if the object remains unchanged.

[Linlin] Originally, there is a response example for <update>. But the WG thought that the example is exactly the same with RFC 5731, so it was removed. The exmaple is,

When an <update> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.

   Example <update> response:

   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="1000">
   S:      <msg>Command completed successfully</msg>
   S:    </result>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

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 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. If this is the case, my 
strong
recommendation is to specify that operations are atomic (that is, they 
either
succeed completely or make no state change whatsoever).

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." ?
---------------------------------------------------------------------------

"Copyright Notice" section:

>  This document may contain material from IETF Documents or IETF
>  Contributions published or made publicly available before November
>  10, 2008.  The person(s) controlling the copyright in some of this
>  material may not have granted the IETF Trust the right to allow
>  modifications of such material outside the IETF Standards Process.

This is typically only true of revisions of older documents, which 
necessarily
obsolete published RFCs. So, to double-check: is this the correct 
boilerplate
for this document?

[Linlin] This paragraph will be removed.
===========================================================================

The remaining comments on this document are minor and editorial.

§1:

>  In the business model of domain registration, we usually have 3 roles
>  of entities, a registrant, a registrar and a registry.

"...of entities: a registrant,..."
               ^

>  operators, privacy proxy, etc.

"...proxies..."

>  A domain reseller is an individual or a company that acts as a agent

"...an agent..."

[Linlin] OK.
---------------------------------------------------------------------------

§2:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Please update this boilerplate to match RFC 8174.

[Linlin]Yes. This section will be updated to match RFC 8174.
---------------------------------------------------------------------------

§2:

>  white space in examples are provided only to illustrate element
>  relationships and are not a REQUIRED feature of this specification.

This isn't really how RFC-2119-defined terms are intended to be used. 
Suggest
changing "REQUIRED" to lowercase.

[Linlin] Yes.
---------------------------------------------------------------------------

§2:

>  orgext-1.0 in this document is used as an abbreviation for
>  urn:ietf:params:xml:ns:orgext-1.0.

I can't find where this abbreviation is used. I suggest removing this 
sentence.

[Linlin] OK, I'll remove this sentence. I think there is the same issue in org draft.
---------------------------------------------------------------------------

§4.1.2:

>  This extension does not add any element to the EPP <info> command

"...elements..."

>  o  Zero or more <orgext:id> elements are allowed that contains the

"...contain..."

[Linlin] OK.
---------------------------------------------------------------------------

§4.2.5:

>  At least one and only one <orgext:add>, <orgext:rem> or <orgext:chg>
>  element MUST be provided.

This is kind of an odd phrasing that may confuse readers. I think what's 
meant
here is "Exactly one of <orgext:add>..." -- if so, please change the 
description
to be more straightforward.

[Linlin] Yes.
---------------------------------------------------------------------------

§4.2.5:

>  o  One or more <orgext:id> elements that contains the identifier of

"...that contain..."

[Linlin] OK.

_____________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext