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 <mailto:a...@nostrum.com>
*Date:* 2018-07-27 09:35
*To:* regext@ietf.org <mailto:regext@ietf.org>;
draft-ietf-regext-org <mailto:draft-ietf-regext-...@tools.ietf.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.
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
