Hi James,
Thanks for your detail comments. I will have these issues updated and hope we
can add some implementation status in version 04.
Regards,
Linlin
zhoulin...@cnnic.cn
From: Gould, James
Date: 2018-04-28 05:52
To: James Galvin; Registration Protocols Extensions
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
Hi,
In reviewing the draft-ietf-regext-org changes in draft-ietf-regext-org-03, I
found the following issues:
In section 3.2.2. “Role Status”
Change “The values of role status are defined in section 3.5.” to “The values
of the role status are defined in section 3.5.”.
In section 3.4. “Organization Status Values”
Change “The “hold” and “terminated” are server-managed…” to “The “hold” and
“terminated” status values are server-managed…”.
In section 4.1.2. “EPP <info> Command”
Change “One or more <org:role> elements that contains the role type, role
status and optional role id of the organization” to “One or more <org:role>
elements that contain the role type, role statuses and optional role id of the
organization”.
Change “Zero or more <org:status> elements of role. The values of role status
are defined in section 3.5.” to “One or more <org:status> elements that contain
the role statuses. The values of the role status are defined in section 3.5”.
Note, the XML schema will support zero or more role statuses in support of a
create or update, but there should be at least one role status returned per
role in the info response.
In section 4.2 “EPP Transform Commands”
Change “EPP provides three commands…” to “This document provides three
commands…”.
In section 4.2.1 “EPP <create> Command”
Change “Zero or more <org:status> elements of role. The values of role status
are defined in section 3.5.” to “Zero or more <org:status> elements that
contain the role statuses. The values of the role status are defined in
section 3.5”.
I would remove setting of the “ok” role status in the “Example <create>
command”, since the server should set the status to “ok” by default.
In section 4.2.5. “EPP <update> Command”
Change “The <org:add> and <org:rem> elements contain the following child
element:” to “The OPTIONAL <org:add> and <org:rem> elements contain the
following child elements:”.
Change “Zero or more <org:status> elements of role. The values of role status
are defined in section 3.5.” to “Zero or more <org:status> elements that
contain the role statuses. The values of the role status are defined in
section 3.5”.
Change “A <org:chg> element contains the following OPTIONAL child elements.” To
“An OPTIONAL <org:chg> element contains the following child elements, where at
least one child element MUST be present:”. I would remove the sentence “At
least one child element MUST be present:”.
I would explicitly specify that the sub-elements of <org:chg> are OPTIONAL, as
in:
i. An
OPTIONAL <org:parentId> element…”.
ii. Zero to
two <org:postalInfo> elements…”.
iii. An OPTIONAL
<org:voice> element…”.
iv. An OPTIONAL
<org:fax> element…”
v. An OPTIONAL
<org:email> element…”
vi. An OPTIONAL
<org:url> element…”.
—
JG
James Gould
Distinguished Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com
From: James Gould <jgo...@verisign.com>
Date: Wednesday, April 25, 2018 at 8:29 AM
To: James Galvin <gal...@elistx.com>, Registration Protocols Extensions
<regext@ietf.org>
Subject: Re: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02
I'm a co-author on this draft, but I did a re-read and I have the following
items that need to be addressed. Some of this is based on the experience of
implementing draft-ietf-regext-org-02 in the Verisign EPP SDK that includes a
full XML namespace aware and validating client and server.
1. Section 3.2.3 “Example of Organization Roles”
a. I don’t believe the example warrants creating its own section. I
recommend moving the example of “Organization Roles” into section 3.2.2 Role
Identifier, rename it to “Example of organization role identifier:”. I also
recommend removing the “S: “ prefix for the organization role identifier
example and indenting the <org:type> and <org:roleid> elements under the
<org:role> element.
2. Section 3.4 “Organization Status Values”
a. There is no definition of what statuses can be set or removed by the
client versus the server. I believe the setting of the statuses prefixed with
“client” or “server” can match the description in RFC 5731:
i. Status values that can be added or removed by a client are
prefixed with "client". Corresponding status values that can be added or
removed by a server are prefixed with "server".
b. I believe the sentence from RFC 5731 ‘Status values that do not begin
with either "client" or "server" are server-managed’ can be modified in
draft-ietf-regext-org to read ‘The “hold” and “terminated” are server-managed
when the organization has no parent identifier [section 3.6] and otherwise MAY
be client-managed based on server policy’.
3. Section 3.8 is missing the title “Dates and Times”
4. Section 4.1.2 “EPP <info> Command”
a. I believe that the “roleStatus” attribute of the <org:type> element
needs to be moved to its own <org:status> element of the <org:role>, since
there can be many statuses set per role. The “Example of organization role
identifier” in section 3.2.3 would need to be updated along with the XML
schema, text, and examples in section 4.1.2. I noticed that the “roleId” is
defined as a “positiveInteger”. My suggestion is to define it as a “token”
type, since it’s hard to say what a role identifier may be for different types
of roles. The “roleType” type could be defined as:
<complexType name=”roleType”>
<sequence>
<element name=”type” type=”token”/>
<element name=”status” type=”org:roleStatusType” minOccurs=”0”
maxOccurs=”3”/>
<element name=”roleId” type=”token” minOccurs=”0”/>
</complexType>
Note – the minOccurs=”0” and maxOccurs=”3” for the status element is defined to
support use of the “roleType” in the create where no status may be explicitly
set (minOccurs=”0”), and in the info response where the maximum number of role
statuses is 3.
The example in section 4.1.2 could defined as:
<org:role>
<org:type>registrar</org:type>
<org:status>ok</org:status>
<org:status>linked</org:status>
<org:roleId>1362</org:roleId>
</org:role>.
b. The <org:role> element in the XML schema infDataType type needs to set
maxOccurs=”unbounded”.
c. The <org:status> element in the XML schema infDataType type needs to
set maxOccurs=”9”. I believe the maximum number of client and server defined
organization statuses to be “9”.
d. Did we want to make the <org:postalInfo> element optional? If so, I
would define the <org:postalInfo> element as “Zero to two <org:postalInfo>
elements…” and include minOccurs=”0” for the “postalInfo” element of the
“infDataType” type.
e. I would update the examples based on the above proposed change to the
definition of the <org:role> element.
f. The “contact” element of the “infDataType” type and the “createType”
should be defined as below. Currently, the “infDataType” refers to
“domain:contactType”, which needs to be “org:contactType” and I propose setting
maxOccurs=”unbounded” since there is the support for custom types. There is a
similar issue where the “addRemType” references “domain:contactType” instead of
“org:contactType”.
i. <element name=”contact” type=”org:contactType” minOccurs=”0”
maxOccurs=”unbounded”/>
g. The <org:email> element is defined as optional but the XML schema
defines it as required. I recommend setting minOccurs=”0” for the “email”
element of “infDataType”.
5. Section 4.2 “EPP Transform Commands”
a. I would remove “<transfer> to manage organization-object sponsorship
changes”, since the <transfer> command is not supported.
b. I would revise “Once the action has been completed, all clients
involved in the transaction MUST…” to “Once the action has been completed, the
client MUST…”.
6. Section 4.2.1 “EPP <create> Command”
a. I believe that the <org:role> element should include
maxOccurs=”unbounded”, since one or more roles can be defined on the create.
b. The same comment related to supporting zero or more optional role
statuses by moving the “roleStatus” status to its own <org:status> element that
is defined. If the role <org:status> is not defined by the client, the server
will set the status to “ok”.
c. I believe that the <org:status> would need to be defined as OPTIONAL
and allow a list of statuses. The default value assigned by the server would
be “ok”, so I don’t believe a default should be set in the XML schema.
Specifically, in the “createType” of the XML schema, the status element should
be defined as <element name=”status” type=”org:statusType” minOccurs=”0”
maxOccurs=”4”/>. I believe the only statuses that a client can set on create
include “hold” or “terminated”, “clientDeleteProhibited”,
“clientUpdateProhibited”, and “clientLinkProhibited”.
d. I would remove setting of the “ok” status in the Example <create>
command.
e. Did we want to make the <org:postalInfo> element optional? If so, I
would define the <org:postalInfo> element as “Zero to two <org:postalInfo>
elements…” and include minOccurs=”0” for the “postalInfo” element of the
“createType” type.
f. The <org:email> element is defined as optional but the XML schema
defines it as required. I recommend setting minOccurs=”0” for the “email”
element of “createType”.
7. Section 4.2.5 “EPP <update> Command”
a. The <org:role> elements would be best suited to be contained under the
<org:add> and <org:rem> instead of the <org:chg>, since the roles are contained
a list. I recommend moving the <org:role> element after the <org:contact>
element and define it as “Zero or more <org:role> elements…” that matches
supports role statuses like in the info response and the create command.
b. The <org:status> elements would be best suited to be contained under
the <org:add> and <org:rem> instead of the <org:chg>, since the statuses are
contained in a list. I recommend moving the <org:status> element after the
<org:role> element and define it as “Zero or more <org:status> elements…”.
c. The “contact” element in “addRemType” type needs to be defined with
maxOccurs=”unbounded”, since it is describes as zero to many.
d. The same feedback as with the info response and the create command on
the makeup of the <org:role> in specifying the “roleStatus” using <org:status>
elements.
e. The “addRemType” could be defined as based on 7.a., 7.b., and 7.c.
above:
<complexType name="addRemType">
<sequence>
<element name="contact" type="org:contactType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="role" type="org:roleType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="status" type="org:statusType" minOccurs="0" maxOccurs="9"/>
</sequence>
</complexType>
f. I recommend revising the <update> command example to reflect removing
the “billing” contact “sh8014”, adding the role “privacyproxy” with the role
status “clientLinkProhibited”, removing the role “reseller”, adding the status
“clientLinkProhibited”, and removing the status “clientDeleteProhibited”,. The
exact types and values are not important, but it’s important to reflect adding
/ removing contacts, adding / removing roles, adding / removing statuses, and
including the supported change elements.
g. There is no mechanism available to delete the change elements of
parentId, voice, fax, email, and url once they are set. I believe an empty
postalInfo element could be used to delete the postal information.
8. Section 5 “Formal Syntax”
a. Overall, much of the feedback is associated with referencing contact
XML schema types. Although I’m not crazy about copying elements over, I
believe it’s the cleanest thing to do in this case. I believe that the org
mapping should stand on its own and only reference up to the epp and eppcom
schemas and not sideways to another object mapping like contact or domain. I
attach a version of the org-1.0.xsd that does not include any contact or domain
references, so all of the examples can continue to reference the
“urn:ietf:params:xml:ns:org-1.0” XML namespace.
b. The use of the “contact:chkDataType” for the “chkData” element does
not match the example response, since the org namespace is referenced instead
of the contact namespace for the sub-elements of the <org:chkData> element in
the example. I recommend copying the contact:creDataType into the org schema
directly directly to use the org namespace for the <org:chkData> sub-elements.
c. The use of the “contact:creDataType” for the “creData” element does
not match the example response, since the org namespace is referenced instead
of the contact namespace for the sub-elements of the <org:creData> element in
the example. I recommend copying the contact:creDataType definition into the
org schema directly to use the org namespace for the <org:creData>
sub-elements.
d. The use of the “contact:addrType” does not match the info response
example, since the <org:addr> does reference the org namespace, but the
<org:addr> sub-elements need to reference the contact namespace. My
recommendation is to copy all of the referenced contact elements into the org
schema to remove the namespace mixing including the simple types:
“contact:e164Type”, “contact:e164StringType”, “contact:postalLineType”,
“contact:postalLineType”, “contact:postalInfoEnumType”, “contact:pcType”, and
“contact:ccType”. The namespace mixing causes a bigger issue for references
to complex elements, but I believe it’s best for the org extension to stand on
its own without a direct dependency to the contact XML schema.
e. If the contact XML schema references can be removed, the contact
namespace reference and import can be removed.
f. I would remove the import of the domain namespace, since it’s not
needed.
—
JG
James Gould
Distinguished Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 4/20/18, 9:34 AM, "regext on behalf of James Galvin"
<regext-boun...@ietf.org on behalf of gal...@elistx.com> wrote:
This is a reminder that this document is in working group last call.
Please indicate your support for the publication of this document.
If any working group member objects to the publication of this document
please respond on the list by close of business everywhere, Friday, 27
April 2018. If there are no objections the document will be submitted
to the IESG.
During the last call the chairs are looking for a document shepherd for
this document. If you are interested in being the document shepherd
please let the chairs know. The document editors cannot be the document
shepherd.
Jim
On 13 Apr 2018, at 9:21, James Galvin wrote:
> The document editors have indicated that the following document is
> ready for submission to the IESG to be considered for publication as a
> Proposed Standard:
>
> Extensible Provisioning Protocol (EPP) Organization Mapping
> https://datatracker.ietf.org/doc/draft-ietf-regext-org/
>
> Please indicate your support for the publication of this document.
>
> If any working group member objects to the publication of this
> document please respond on the list by close of business everywhere,
> Friday, 27 April 2018. If there are no objections the document will
> be submitted to the IESG.
>
> During the last call the chairs are looking for a document shepherd
> for this document. If you are interested in being the document
> shepherd please let the chairs know. The document editors cannot be
> the document shepherd.
>
> If you’ve never been a document shepherd before don’t worry.
> It’s a great way to understand the IETF process and your chairs
> would be delighted to help you through it.
>
> Thanks,
>
> Antoin and Jim
> WG Co-Chairs
_______________________________________________
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
