Subject: [regext] WGLC: draft-ietf-regext-org-02

From: "James Galvin" <[email-masked]>
Date: Fri, 13 Apr 2018 09:21:37 -0400

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 13 Apr 2018 13:47:34 +0000

> -----Original Message-----
> From: regext [mailto:[email-masked]] On Behalf Of James Galvin
> Sent: Friday, April 13, 2018 9:22 AM
> To: Registration Protocols Extensions <[email-masked]>
> Subject: [EXTERNAL] [regext] WGLC: draft-ietf-regext-org-02
>
> for submission to the IESG to be considered for publication as a Proposed
> Standard:
>

I support publication of this document in concept, but I just noticed some significant omissions that need to be addressed before it can move forward.

There is text missing to describe how the Role Values Registry described in Section 7.3 should be created and managed by IANA. The authors might want to look at Section 2 of RFC 8126 for a description of the kind of information that's needed.

In Section 7.1, text needs to be added to include registration of the schema from Section 5. Section 6 of RFC 5731 can be used as an example of the instructions for registering both the XML namespace and the XML schema. Note that there is no XML included with registration of the namespace.

Scott

---

From: Pieter Vandepitte <[email-masked]>
Date: Fri, 13 Apr 2018 16:06:29 +0200

I don't want to delay the publication, and I support it, but there are still some issues/concerns

Typos/errors

> EPP provides two commands to retrieve domain information

Should be: "EPP provides two commands to retrieve organization information". 

>    This document does not define a mapping
>    for the EPP <transfer> command to retrieve domain-object transfer
>    status information..

change domain-object to organization-object

> 
>    EPP provides four commands to transform organization object
>    information: <create> to create an instance of an organization
>    object, <delete> to delete an instance of an organization object,
>    <transfer> to manage organization-object sponsorship changes, and
>    <update> to change information associated with an organization
>    object.  This document does not define a mapping for the EPP
>    <transfer> and <renew> command.

It should be three commands. (Also remove the part " <transfer> to manage organization-object sponsorship changes,"). 
(I'm even not sure that the draft should not support transfer. )

In 4.2.1:

>    o  A <org:status> element that contains the operational status of the
>       organization, as defined in Section 3.4 <https://tools.ietf.org/html/draft-ietf-regext-org-02#section-3.4>.

I think it's zero, one or more org:status elements. It can be clientUpdateProhibited and clientDeleteProhibited at the same time for instance...

Food for thought:

Postal Info

(1) Why do we still stick to the original model of contacts as the new model for organization, with postal info is required (and within the postalInfo, name and address is required)? I think, we should be very cautious when making attributes required. If it's required for the protocol, I agree, but this is not the case. It's more a policy thing, which must be described in other documents (like ICANN policy documents). E.g. at .be, we are considering to model resellers, but we don't need the address, only the URL. Moreover, this original contact model can potentially become problematic in the context of GDPR (although i don't see a lot of issues with reseller contact data)

(2) I would not define a postalInfo type. The sole purpose as far as I can think of, is to make the postal info legible for people that use ascii script in their language (transliteration). If transliteration would be the use case, I would not restrict that to transliterations between ascii and "the rest", but then I would define a "script" or "lang" tag, which defines the script of the postal info, and allow zero to infinite postalInfo elements to allow multiple transliterations (not only to us-ascii).
( As a side note: I always struggled with the "int" type. For me, "Int" = "international" = any script / character set allowed, which is the opposite)

(3) As mentioned in a previous post, I still doubt the need for different contact types within an organization, but let's make abstraction of that... Can't the organization's postalInfo data be modeled as a linked contact? Much simpler

Organization Roles

(1) Although I doubt the need for a roleid, I think we should either remove it, or extend it. The role id is the id of the organization in a third party source (e.g. in case of a Registrar, IANA is a third party source, and id is "the IANA-id"). It is IMO possible that an object is known in different sources with different "IDs"
So, for completeness, the org:roleid should have an attribute indicating the authoritative source of the id, in case of a Registrar IANA id, it could be "iana". 

(2) As I understand, organization roles can be used in links. But what if a link exists for a specific role, and the organization role is removed afterwards from the organization? As I understand from James in a previous reply to Patrick, this should match (in fact it's a MUST). This is not described as far as I can see. Wouldn't it be a good idea, in order to have a unambiguous understanding, to describe that in draft-ietf-regext-org-ext (create, update) and in draft-ietf-regext-org (update, delete)? 

Kind regards

Pieter

> On 13 Apr 2018, at 15:21, James Galvin <[email-masked]> 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:
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 13 Apr 2018 14:41:34 +0000

> From: regext [mailto:[email-masked]] On Behalf Of Hollenbeck,
> Scott
> Sent: Friday, April 13, 2018 9:48 AM
> To: [email-masked]' <[email-masked]>; [email-masked]'
> <[email-masked]>
> Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02
>
> > 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:
> >
> I support publication of this document in concept, but I just noticed some
> significant omissions that need to be addressed before it can move
> forward.
>
> There is text missing to describe how the Role Values Registry described
> in Section 7.3 should be created and managed by IANA. The authors might
> want to look at Section 2 of RFC 8126 for a description of the kind of
> information that's needed.
>
> In Section 7.1, text needs to be added to include registration of the
> schema from Section 5. Section 6 of RFC 5731 can be used as an example of
> the instructions for registering both the XML namespace and the XML
> schema. Note that there is no XML included with registration of the
> namespace.

Sorry, missed one: In Section 7.2, the IESG should be named as the registrant for a standards track extension.

Scott

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 16 Apr 2018 11:05:16 +0800

Dear Scott,
Thanks for your comments. I've already updated them in the new version and will submit it before the end of WGLC.

Regards,
Linlin

[email-masked]
 
From: Hollenbeck, Scott
Date: 2018-04-13 22:41
To: [email-masked]'; [email-masked]'
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02

Scott

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 16 Apr 2018 17:52:59 +0800

Dear Pieter,
Thanks for your support. I'll update the text according to your comments. Please see some my feedbacks inline.

Regards,
Linlin

[email-masked]
 
From: Pieter Vandepitte
Date: 2018-04-13 22:06
To: James Galvin
CC: Registration Protocols Extensions
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
I don't want to delay the publication, and I support it, but there are still some issues/concerns

Typos/errors

change domain-object to organization-object
[Linlin] These typos will be modified.

[Linlin] Yes. Words will be updated.

In 4.2.1:

   o  A <org:status> element that contains the operational status of the
      organization, as defined in Section 3.4.

I think it's zero, one or more org:status elements. It can be clientUpdateProhibited and clientDeleteProhibited at the same time for instance...
[Linlin]  I'd like to change the text to "Zero or more OPTIONAL org:status elements".

Food for thought:

Postal Info

(3) As mentioned in a previous post, I still doubt the need for different contact types within an organization, but let's make abstraction of that... Can't the organization's postalInfo data be modeled as a linked contact? Much simpler
[Linlin] As I expalined before, our requirements was to have a reseller extension with its own contacts and hierarchy. So we keep the postInfo part of RFC5733 to store the address information. For most of the registries and registrars, this structure is more familiar with them. 

Organization Roles

(1) Although I doubt the need for a roleid, I think we should either remove it, or extend it. The role id is the id of the organization in a third party source (e.g. in case of a Registrar, IANA is a third party source, and id is "the IANA-id"). It is IMO possible that an object is known in different sources with different "IDs"
So, for completeness, the org:roleid should have an attribute indicating the authoritative source of the id, in case of a Registrar IANA id, it could be "iana". 
[Linlin] Until now, the optional is only used for the IANA-id. I am not sure what are other sources to get the roleid? 

(2) As I understand, organization roles can be used in links. But what if a link exists for a specific role, and the organization role is removed afterwards from the organization? As I understand from James in a previous reply to Patrick, this should match (in fact it's a MUST). This is not described as far as I can see. Wouldn't it be a good idea, in order to have a unambiguous understanding, to describe that in draft-ietf-regext-org-ext (create, update) and in draft-ietf-regext-org (update, delete)? 
[Linlin] There are some words in section 4.2.2 "An organization object MUST NOT be deleted if it is associated with other known objects.  An associated organization MUST NOT be deleted until associations with other known objects have been broken." I am not sure if this is ok for you.

Kind regards

Pieter

Thanks,

Antoin and Jim
WG Co-Chairs

---

From: Pieter Vandepitte <[email-masked]>
Date: Mon, 16 Apr 2018 15:51:35 +0200

Thanks Linlin!

Seems OK for me

> Zero or more OPTIONAL org:status elements

Optional here is not necessary, since it's zero, imo, but maybe sometimes you can't be explicit enough i think ;-)

Kind regards

Pieter

> On 16 Apr 2018, at 11:52, Linlin Zhou <[email-masked]> wrote:
> 
> Dear Pieter,
> [email-masked] <mailto:[email-masked]>
>  
> From: Pieter Vandepitte <mailto:[email-masked]>
> Date: 2018-04-13 22:06
> To: James Galvin <mailto:[email-masked]>
> CC: Registration Protocols Extensions <mailto:[email-masked]>
>> On 13 Apr 2018, at 15:21, James Galvin <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-regext-org/ <https://datatracker.ietf.org/doc/draft-ietf-regext-org/>
>>

---

From: "James Galvin" <[email-masked]>
Date: Fri, 20 Apr 2018 09:33:51 -0400

This is a reminder that this document is in working group last call.

Jim

On 13 Apr 2018, at 9:21, James Galvin wrote:

> 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

---

From: "Gould, James" <[email-masked]>
Date: Wed, 25 Apr 2018 12:29:52 +0000

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”
     *   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”
     *   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’.

  1.  Section 3.8 is missing the title “Dates and Times”
  2.  Section 4.1.2 “EPP <info> Command”
     *   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>.
     *   The <org:role> element in the XML schema infDataType type needs to set maxOccurs=”unbounded”.
     *   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”.
     *   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.
     *   I would update the examples based on the above proposed change to the definition of the <org:role> element.
     *   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”/>

     *   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”.
  1.  Section 4.2 “EPP Transform Commands”
     *   I would remove “<transfer> to manage organization-object sponsorship changes”, since the <transfer> command is not supported.
     *   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…”.
  2.  Section 4.2.1 “EPP <create> Command”
     *   I believe that the <org:role> element should include maxOccurs=”unbounded”, since one or more roles can be defined on the create.
     *   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”.
     *   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”.
     *   I would remove setting of the “ok” status in the Example <create> command.
     *   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.
     *   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”.
  3.  Section 4.2.5 “EPP <update> Command”
     *   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.
     *   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…”.
     *   The “contact” element in “addRemType” type needs to be defined with maxOccurs=”unbounded”, since it is describes as zero to many.
     *   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.
     *   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>
     *   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.
     *   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.
  4.  Section 5 “Formal Syntax”
     *   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.
     *   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.
     *   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.
     *   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.
     *   If the contact XML schema references can be removed, the contact namespace reference and import can be removed.
     *   I would remove the import of the domain namespace, since it’s not needed.

—

JG

James Gould

Distinguished Engineer

[email-masked]

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" <[email-masked] on behalf of [email-masked]> wrote:

    to the IESG.

    shepherd.

    Jim

    regext mailing list

    [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Fri, 27 Apr 2018 21:52:07 +0000

Hi,

In reviewing the draft-ietf-regext-org changes in draft-ietf-regext-org-03, I found the following issues:

  1.  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.”.
  2.  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…”.
  3.  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.
  4.  In section 4.2 “EPP Transform Commands”
     *   Change “EPP provides three commands…” to “This document provides three commands…”.
  5.  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.
  6.  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
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>
From: James Gould <[email-masked]>
Date: Wednesday, April 25, 2018 at 8:29 AM
To: James Galvin <[email-masked]>, Registration Protocols Extensions <[email-masked]>
Subject: Re: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02

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:

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>

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

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

    to the IESG.

    shepherd.

    Jim

    regext mailing list

    [email-masked]

---

From: "Linlin Zhou" <[email-masked]>
Date: Sat, 28 Apr 2018 10:15:29 +0800

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

[email-masked]
 
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 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
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

—
JG

James Gould
Distinguished Engineer
[email-masked]
 
703-948-3271
12061 Bluemont Way
Reston, VA 20190

    

    
    Jim