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

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

When using the XML2RFC tool (which it seems you may be), there's an 
attribute of the <rfc/> element called "ipr". This text looks like the 
"ipr" element is set to "pre5378Trust200902" (or some other earlier 
string). You probably want "trust200902" instead.

/a

On 7/28/18 3:32 AM, Linlin Zhou wrote:
> Hi Adam,
> It seems that this paragraph was generated by the xml2rfc tool. I 
> reread this section and I think it is better to remove this paragragh.
>
> Regards,
> Linlin
> ------------------------------------------------------------------------
> [email-masked]
>
>     *From:* Adam Roach <mailto:[email-masked]>
>     *Date:* 2018-07-28 06:12
>     *To:* [email-masked] <mailto:[email-masked]>;
>     draft-ietf-regext-org <mailto:[email-masked]>
>     *Subject:* Re: AD Review: draft-ietf-regext-org
>     On 7/26/18 8:35 PM, Adam Roach wrote:
>     > This is my AD review for draft-ietf-regext-org-08.
>     After sending my original review, I noticed one additional detail
>     that
>     should be addressed:
>     "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?
>     /a
>

---

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

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
>     *Date:* 2018-07-27 09:35
>     *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 <check>
>     command
>     >  MUST contain a <org:check> 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 <org:chkData>,
>     <org:info>, <org:infData>, <org:create>, <org:creData>, <org:delete>,
>     <org:update>, and <org:panData>.
>      [Linlin] Take the <check> 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 <check> command contains the following child elements:
>
>        -  An object-specific <obj:check> element that identifies the objects
>           to be queried.  Multiple objects of the same type MAY be queried
>           within a single <check> command.
>     The <obj:check> 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:<EPPCommandName>
>      C:  <object:command xmlns:object="urn:ietf:params:xml:ns:object">
>      C:    <!-- One or more object-specific command elements. -->
>      C:  </object:command>
>      C:</EPPCommandName>
>
>     So the newly added organization object has the namespace
>     <org:check xmlns:org="urn:ietf:params:xml:ns:org-1.0">.
>
>     In RFC 5731, 5732 and 5733, some words such as
>     " In addition to the standard EPP command elements, the <check> command MUST contain a <domain:check> element that identifies the domain namespace.",
>     are explicitly written to say that you should have
>     <obj:check>,<obj:info> 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:<EPPCommandName>
  C:  <object:command xmlns:object="urn:ietf:params:xml:ns:object">
  C:    <!-- One or more object-specific command elements. -->
  C:  </object:command>
  C:</EPPCommandName>

  C:<EPPCommandName xmlns:object="urn:ietf:params:xml:ns:object">
  C:  <object:command>
  C:    <!-- One or more object-specific command elements. -->
  C:  </object:command>
  C:</EPPCommandName>

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

>     ---------------------------------------------------------------------------
>     §3.4:
>     >  An organization object MUST always have at least one associated
>     >  status value.  The default value is "ok".
>     What is meant by "default" here? Is this the value to be assumed
>     if the
>     element
>     is omitted? If that’s the case, please say so specifically. If
>     this is
>     simply
>     saying that the most common value is "ok," then rephrase to say that.
>
>     [Linlin] It was designed to have the default "ok" value if this
>     element is omitted at first. After somen versions, one or more
>     "status" element can be associated with the org object. I've read
>     the text in this section again and suggested removing this sentence.
>

That sounds good to me.

>     ---------------------------------------------------------------------------
>     §3.4:
>     >  o  linked: The organization object has at least one active
>     >     association with another object.  The "linked" status is not
>     >     explicitly set by the client.  Servers SHOULD provide
>     services to
>     >     determine existing object associations.
>     Given that this is a normative requirement, you need a normative
>     reference
>     here to the specification by which such services are provided.
>     [Linlin] I think servers can make <update> command to change the
>     status value of the org object depending on the server policies or
>     business model. Each registry may have its own method to do this.
>     Whether it is ok to change it to non-normtive requirement.
>     "Servers should provide service to determine existing object
>     associations."
>

That would be fine also.

>     ---------------------------------------------------------------------------
>     §3.5:
>     >  A role SHOULD have at least one associated status value. Valid
>     >  values include "ok", "linked", "clientLinkProhibited", and
>     >  "serverLinkProhibited".  The default value is "ok".
>     Same comment as above about "ok" as default.
>      [Linlin] I suggest removing this sentence.
>

That sounds good.

>     ---------------------------------------------------------------------------
>
>     §3.7:
>     >  The URL represents the organization web home page, as defined with
>     >  the <org:url> element.
>     Is there any intention to limit the scheme here? Like, is ftp
>     okay? Is coap?
>      [Linlin] No limit to the format. Any valid URI is ok.
>

Okay; if that's the intention, then the current text is okay.

>     ---------------------------------------------------------------------------
>     §5, Page 34:
>     >   <complexType name="checkType">
>     >     <sequence>
>     >       <element name="id" type="contact:checkIDType"/>
>     >       <element name="reason" type="eppcom:reasonType"
>     >        minOccurs="0"/>
>     >     </sequence>
>     >   </complexType>
>     The "reason" element needs to have a "maxOccurs" of greater than one
>     (presumably "unbounded") to allow for the conveyance of reasons in
>     multiple
>     languages.
>
>     [Linlin] There is no limit for the "maxOccurs".. In RFC 5733,
>     there is only a "minOccurs" value. Do we need to define this
>     explicitly?
>

Yes. The default value for both minOccurs and maxOccurs is "1" -- if you 
want to allow more than one instance of an element, you need to indicate 
a maxOccurs.

Quickly glancing at RFC 5733: if the intention in that document is to 
allow more than one <reason> element, then its definition is also in error.

>     ---------------------------------------------------------------------------
>     §4.1.2 (at the bottom of Page 13):
>     >  Example <info> response for "Example Reseller Inc." organization
>     >  object of reseller type managed by identifier "registrar1362":
>     This should say "reseller1362".
>
>     [Linlin] This reseller is managed by registrar "registrar1362".
>      "registrar1362" is its upper level organization. You can find the
>     element <org:parentId>registrar1362</org:parentId>.
>

Ah, yes. I misread the sentence. Thank you.

The remaining responses (which I have removed from this email) all look 
good to me. Thanks!

/a

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 7 Aug 2018 14:23:19 +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: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

[email-masked]
 
From: Adam Roach
Date: 2018-07-27 09:35
To: [email-masked]; 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.

 
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 <check> command
 
namespace is defined in an ancestor element? Given that the rest of XML

 [Linlin] Take the <check> 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 <check> command contains the following child elements:

   -  An object-specific <obj:check> element that identifies the objects
      to be queried.  Multiple objects of the same type MAY be queried
      within a single <check> command.
The <obj:check> 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:<EPPCommandName>
 C:  <object:command xmlns:object="urn:ietf:params:xml:ns:object">
 C:    <!-- One or more object-specific command elements. -->
 C:  </object:command>
 C:</EPPCommandName>

So the newly added organization object has the namespace <org:check xmlns:org="urn:ietf:params:xml:ns:org-1.0">. 

In RFC 5731, 5732 and 5733, some words such as " In addition to the standard EPP command elements, the <check> command MUST contain a <domain:check> element that identifies the domain namespace.", are explicitly written to say that you should have <obj:check>,<obj:info> 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:<EPPCommandName>

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 <check> command MUST contain a <org:check> 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 <org:chkData>, <org:info>, <org:infData>, <org:create>, <org:creData>, <org:delete>, <org:update>, and <org:panData>.
---------------------------------------------------------------------------

 
The "reason" element needs to have a "maxOccurs" of greater than one
(presumably "unbounded") to allow for the conveyance of reasons in multiple
languages.

[Linlin] There is no limit for the "maxOccurs".. In RFC 5733, there is only a "minOccurs" value. Do we need to define this explicitly?

Yes. The default value for both minOccurs and maxOccurs is "1" -- if you want to allow more than one instance of an element, you need to indicate a maxOccurs.

Quickly glancing at RFC 5733: if the intention in that document is to allow more than one <reason> element, then its definition is also in error.

[Linlin]  We checked our current running system. The suggested maxOccurs is 5. Of course this value can be discussed.
---------------------------------------------------------------------------

The remaining responses (which I have removed from this email) all look good to me. Thanks!

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 7 Aug 2018 11:43:54 -0500

Your proposed resolutions sound fine to me. Thanks!

/a

On 8/7/18 1:23 AM, Linlin Zhou wrote:
>     *Date:* 2018-08-07 07:27
>     *To:* Linlin Zhou <mailto:[email-masked]>; regext
>     <mailto:[email-masked]>; draft-ietf-regext-org
>     <mailto:[email-masked]>
>     *Subject:* Re: [regext] AD Review: draft-ietf-regext-org
>>     Thanks for your review. I have my feedbacks started with
>>     [Linlin]. I'll update the draft based on your comments.
>>
>>     Regards,
>>     Linlin
>>         draft-ietf-regext-org
>>         <mailto:[email-masked]>
>>         <obj:check>,<obj:info> 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.
>>
>
>
>     [Linlin] How about "In addition to the standard EPP command
>     elements, the <check> command MUST contain a <org:check> 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 <org:chkData>, <org:info>, <org:infData>, <org:create>,
>     <org:creData>, <org:delete>, <org:update>, and <org:panData>.
>>
>     Yes. The default value for both minOccurs and maxOccurs is "1" --
>     if you want to allow more than one instance of an element, you
>     need to indicate a maxOccurs.
>
>     Quickly glancing at RFC 5733: if the intention in that document is
>     to allow more than one <reason> element, then its definition is
>     also in error.
>
>     [Linlin]  We checked our current running system. The suggested
>     maxOccurs is 5. Of course this value can be discussed.
>>