Dear Adam,
I have included my feedbacks for the remaining issues. Please see below.
Regards,
Linlin
zhoulin...@cnnic.cn
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
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.
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
