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 <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.
===========================================================================
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.
[Linlin] Yes. We will change them to <msg lang="en">, <org: reason lang="en">.
---------------------------------------------------------------------------
§2:
Please update the boilerplate to match RFC 8174.
[Linlin] Yes. This section will be updated 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)
[Linlin] OK. We will make it as "roleID".
---------------------------------------------------------------------------
§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.
---------------------------------------------------------------------------
§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."
---------------------------------------------------------------------------
§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.
---------------------------------------------------------------------------
§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.
[Linlin] Yes.
---------------------------------------------------------------------------
§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.
---------------------------------------------------------------------------
§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.
[Linlin] This will be updates as "An OPTIONAL" <org:reason> element that may
be provided when an object cannnot be provisioned.".
---------------------------------------------------------------------------
§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)
[Linlin] OK. We will make it as "roleID".
---------------------------------------------------------------------------
§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.
[Linlin] OK.
---------------------------------------------------------------------------
§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.
[Linlin] Add a sentence to refer to RFC 5733 section 2.5 here.
---------------------------------------------------------------------------
§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?
---------------------------------------------------------------------------
§6:
Please cite UTF-8 (RFC 3629) and UTF-16 (RFC 2718).
[Linlin] Yes.
---------------------------------------------------------------------------
§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.
[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].
===========================================================================
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.
[Linlin] OK. I'll modify the example URIs.
---------------------------------------------------------------------------
§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.
[Linlin] OK, thanks.
---------------------------------------------------------------------------
§3.2.1:
> An organization role MUST have a type which support a list of values.
"...which supports..."
[Linlin] OK.
---------------------------------------------------------------------------
§3.2.3:
> A role MAY have a third party assigned identifier such as the IANA ID
"...third-party-assigned..."
[Linlin] OK.
---------------------------------------------------------------------------
§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.
[Linlin] The contact identifiers should be inline with the RFC 5733. In RFC
5733, it is "specified minimum length". I'll correct it.
---------------------------------------------------------------------------
§3.6:
> Take a reseller organization for example, the parent identifier is
"...organization, for example. The..."
[Linlin] OK.
^ ^
---------------------------------------------------------------------------
§4.1.1:
> In addition to the standard EPP command elements, the <check> command
> MUST contain a <org:check> element
"...contain an <org:check>..."
[Linlin] OK.
---------------------------------------------------------------------------
§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..."
[Linlin] OK.
---------------------------------------------------------------------------
§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>.
---------------------------------------------------------------------------
§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>..."
[Linlin] OK.
---------------------------------------------------------------------------
§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..."
[Linlin] OK.
---------------------------------------------------------------------------
§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>..."
[Linlin] OK.
---------------------------------------------------------------------------
§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:..."
[Linlin] OK.
/a
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
