Dear Adam,
I have included my feedbacks for the remaining issues. Please see below.
Regards,
Linlin
------------------------------------------------------------------------
zhoulin...@cnnic.cn
*From:* Adam Roach <mailto:a...@nostrum.com>
*Date:* 2018-08-07 07:27
*To:* Linlin Zhou <mailto:zhoulin...@cnnic.cn>; regext
<mailto:regext@ietf.org>; draft-ietf-regext-org
<mailto:draft-ietf-regext-...@tools.ietf.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
------------------------------------------------------------------------
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.
[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>.
---------------------------------------------------------------------------
§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.
[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
