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

From: Adam Roach <[email-masked]>
Date: Thu, 26 Jul 2018 20:35:10 -0500

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

===========================================================================

General:

Examples of elements that contain user-facing strings (<msg> and 
<org:reason>,
for example) should probably contain "lang" attributes, even when using the
default of English, so as to encourage readers of the examples to implement
localization features.

---------------------------------------------------------------------------

§2:

Please update the boilerplate to match RFC 8174.

---------------------------------------------------------------------------

§3.2.3:

 >  A role MAY have a third party assigned identifier such as the IANA ID
 >  for registrars.  Its corresponding element is <org:roleid>.

Shouldn't this element be called "roleID", to match the convention for 
other EPP
identifiers? (e.g., clID, crID, upID)

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§3.6:

 >  Loops SHOULD be prohibited.  If organization A has B as parent
 >  identifier, organization B must not have organization A as parent
 >  identifier.

This is confusing on a couple of fronts. It starts with a "SHOULD be
prohibited," followed by a "must not have" that *appears* to be stating 
the same
thing. While the second sentence appears to be a non-normative example, 
it still
needs to take care not to contradict normative language by appearing to
strengthen it.

The other bit of confusion is that the second sentence is not stated as an
example, and so its omission of larger loops (e.g., A->B->C->A) might be 
read to
indicate that they are not problematic. I would suggest rephrasing along 
these
lines:

    Loops SHOULD be prohibited. For example: if organization A has B
    as its parent identifier, organization B should not have organization
    A as its parent identifier. The same is true for larger loops involving
    three or more organizations.

---------------------------------------------------------------------------

§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?

---------------------------------------------------------------------------

§4.1.1:

 >  o  An OPTIONAL <org:reason> element that MAY be provided when an
 >     object cannot be provisioned

"OPTIONAL" is redundant with "MAY" here. Pick one to be normative, and 
use the
non-uppercase form for the other.

---------------------------------------------------------------------------

§4.1.2:

 >  o  A <org:roid> element that contains the Repository Object

Shouldn't this element be called "roID", to match the convention for 
other EPP
identifiers? (e.g., clID, crID, upID)

---------------------------------------------------------------------------

§4.1.2:

 >     If an internationalized form (type="int") is provided,
 >     element content MUST be represented in a subset of UTF-8 that can
 >     be represented in the 7-bit US-ASCII character set.

This falls apart if UTF-16 is used, as explicitly allowed (even if not
recommended) by section 6. I would suggest this be rephrased to simply say
"the subset of Unicode in the range U+0020 - U+007E."

This comment is also applicable to the similar text in sections 4.2.1 
and 4.2.5.

---------------------------------------------------------------------------

§4.1.2:

 >  o  An OPTIONAL <org:voice> element that contains the organization's
 >     voice telephone number.

This is underspecified. I would expect to see something like
https://tools.ietf.org/html/rfc5733#section-2.5 (or a citation to that 
section).

This is also applicable to similar language in sections 4.2.1 and 4.2.5.

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§6:

Please cite UTF-8 (RFC 3629) and UTF-16 (RFC 2718).

---------------------------------------------------------------------------

§7.3:

 >  The following values should be registered by the IANA in the "EPP
 >  Organization Role Values" registry.  The registration policy for this
 >  registry is "Expert Review" [RFC8126].

It's not clear, from this text, that the document is asking to create a new
table. I would recommend making that clearer in this section.

===========================================================================

My remaining comments are minor editorial points.

General:

The examples use "http" for all of the organization URLs. With the current
industry shift to use https instead of http, it would probably be better 
to use
"https" in such examples.

---------------------------------------------------------------------------

§2:

 >  "org-1.0" in is used as an abbreviation for
 >  "urn:ietf:params:xml:ns:org-1.0".

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

---------------------------------------------------------------------------

§3.2.1:

 >  An organization role MUST have a type which support a list of values.

"...which supports..."

---------------------------------------------------------------------------

§3.2.3:

 >  A role MAY have a third party assigned identifier such as the IANA ID

"...third-party-assigned..."

---------------------------------------------------------------------------

§3.3:

 >  All EPP contacts are identified by a server-unique identifier.
 >  Contact identifiers are character strings with a specific minimum
 >  length,

Should this say "specific" or "specified"? If "specific" is correct, I would
expect to see the specific number either in this document or in another
document that is referenced here.

---------------------------------------------------------------------------

§3.6:

 >  Take a reseller organization for example, the parent identifier is

"...organization, for example. The..."
                 ^            ^
---------------------------------------------------------------------------

§4.1.1:

 >  In addition to the standard EPP command elements, the <check> command
 >  MUST contain a <org:check> element

"...contain an <org:check>..."

---------------------------------------------------------------------------

§4.1.2:

 >  o  A <org:id> element that contains the server-unique identifier of
 >     the organization object to be queried.

"An <org:id>..."

 >  o  A <org:roid> element that contains the Repository Object

"An <org:roid>..."

 >  o  One or more <org:role> elements that contains the role type, role

"...that contain..."

 >     *  A <org:type> element that contains the type of the

"An <org:type>..."

 >     *  One or more <org:status> elements that contains the role

"...that contain..."

 >     *  An OPTIONAL <org:roleid> element that contains a third party
 >        assigned identifier, such as IANA ID for registrars, as defined
 >        in Section 3.2.3.

"...third-party-assigned..."

---------------------------------------------------------------------------

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

---------------------------------------------------------------------------

§4.2.1:

 >  o  A <org:id> element that contains the desired server-unique

"An <org:id>..."

 >  o  One or more <org:role> elements that contains the role type, role

"...that contain..."

 >     *  A <org:type> element that contains the type of the

"An <org:type>..."

 >     *  Zero or more <org:status> elements that contains the role

"...that contain..."

 >     *  An OPTIONAL <org:roleid> element that contains a third party
 >        assigned identifier

"...third-party-assigned..."

 >  o  Zero of more <org:status> element that contains the operational

"Zero or more <org:status> elements that contain the..."
        ^                          ^             ^

 >        +  A <org:city> element that contains the organization's city.

"An <org:city>..."

 >        +  A <org:cc> element that contains the organization's country

"An <org:cc>..."

---------------------------------------------------------------------------

§4.2.1:

 >  EPP command elements, the <delete> command MUST contain a
 >  <org:delete> element

"...an <org:delete> element..."

 >  o  A <org:id> element that contains the server-unique identifier of

"An <org:delete> element..."

---------------------------------------------------------------------------

§4.2.5:

 >  o  A <org:id> element that contains the server-unique identifier of

"An <org:id>..."

 >  MAY be omitted if an <update> extension is present. The OPTIONAL
 >  <org:add> and <org:rem> elements contain the following child element:

"...following child elements:"

 >  o  Zero or more <org:role> elements that contains the role type, role

"...that contain..."

 >     *  A <org:type> element that contains the role type of the

"An <org:type>..."

 >     *  Zero or more <org:status> elements that contains the role

"...that contain..."

 >  o  Zero or more <org:status> element that contains the operational

"...that contain..."

 >     *  A <org:name> element that contains the name of the

"An <org:name>..."

 >        +  A <org:city> element that contains the organization's city.

"An <org:city>..."

 >        +  A <org:cc> element that contains the organization's country

"An <org:cc>..."

---------------------------------------------------------------------------

§4.3:

 >  o  A <org:id> element that contains the server-unique identifier of

"An <org:..."

 >  o  A <org:paTRID> element that contains the client transaction

"An <org:..."

 >  o  A <org:paDate> element that contains the date and time describing

"An <org:..."

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Jul 2018 17:12:26 -0500

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: "Linlin Zhou" <[email-masked]>
Date: Sat, 28 Jul 2018 16:00:22 +0800

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.

 

 

 
 [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.
===========================================================================
 
General:

[Linlin] Yes. We will change them to <msg lang="en">, <org: reason lang="en">.
---------------------------------------------------------------------------
 
§2:

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

 
 
Shouldn't this element be called "roleID", to match the convention for 
other EPP
identifiers? (e.g., clID, crID, upID)
 [Linlin] OK. We will make it as "roleID".
---------------------------------------------------------------------------

 

[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. 
---------------------------------------------------------------------------

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

 
Same comment as above about "ok" as default.
 [Linlin] I suggest removing this sentence.
---------------------------------------------------------------------------

 

[Linlin] Yes. 

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

 
"OPTIONAL" is redundant with "MAY" here. Pick one to be normative, and 
use the
non-uppercase form for the other.
 [Linlin] This will be updates as "An OPTIONAL" <org:reason> element that may be provided when an object cannnot be provisioned.". 
---------------------------------------------------------------------------

 

[Linlin] OK. We will make it as "roleID". 
---------------------------------------------------------------------------

 
 
 [Linlin] OK.

 

[Linlin] Add a sentence to refer to RFC 5733 section 2.5 here.
---------------------------------------------------------------------------

 

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

[Linlin] Yes.

 
 
[Linlin] IANA has created a new category of protocol registry for values of the organization roles.  The name of this registry is "EPP Organization Role Values". The registration policy for this registry is "Expert Review" [RFC8126].
===========================================================================

General:

[Linlin] OK. I'll modify the example URIs.
---------------------------------------------------------------------------

 

[Linlin] OK, thanks.

 
"...which supports..."

[Linlin] OK.

 

[Linlin] OK.

 
 
[Linlin] The contact identifiers should be inline with the RFC 5733. In RFC 5733, it is "specified minimum length". I'll correct it.
---------------------------------------------------------------------------

 

[Linlin] OK.
                ^            ^

 
 
 [Linlin] OK.

 
"An <org:id>..."

"An <org:roid>..."

"...that contain..."

"An <org:type>..."

"...that contain..."

[Linlin] OK.

 

[Linlin] This reseller is managed by registrar "registrar1362".  "registrar1362" is its upper level organization. You can find the element <org:parentId>registrar1362</org:parentId>.
---------------------------------------------------------------------------

 
"An <org:id>..."

"...that contain..."

"An <org:type>..."

"...that contain..."

 

 
"An <org:city>..."

"An <org:cc>..."

[Linlin] OK.

 

 
[Linlin] OK.

 
"An <org:id>..."

 
 
"...that contain..."

"An <org:type>..."

"...that contain..."

"...that contain..."

"An <org:name>..."

"An <org:city>..."

"An <org:cc>..."

[Linlin] OK.

 
"An <org:..."

"An <org:..."

"An <org:..."

[Linlin] OK.
 
/a
 
_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: "Linlin Zhou" <[email-masked]>
Date: Sat, 28 Jul 2018 16:32:27 +0800

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
Date: 2018-07-28 06:12
To: [email-masked]; draft-ietf-regext-org
Subject: Re: AD Review: draft-ietf-regext-org

 

/a