Re: [regext] Final review of draft-ietf-regext-org-06

["Gould, James" <[e-mail]>]

Pieter,

Thanks for doing the detailed review.  I’ll let Linlin comment on the proposed wording changes.  I have feedback on some of the items below:


===

3.4<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.4>.  Organization Status Values

I think you forgot to specify that

"linked" status MUST NOT be combined with either "clientLinkProhibited" or "serverLinkProhibited" status.

Or is this in case you want to block linking while there are still links? If so, it's useful to specify this:

A client or server MAY combine linked with either clientLinkProhibited or serverLinkProhibited if new links must be prohibited [...]


The purpose of the [client/server]LinkProhibited statuses are to prohibit additional links without impacting the existing links, so you second proposal would be the most appropriate.


===

3.5<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.5>.  Role Status Values

[…]

o  ok: This is the normal status value for an role that has no
      pending operations or prohibitions.  This value is set and removed
      by the server as other status values are added or removed.

⇒ There are no pending statuses for role statuses, so remove that part

Also here, I think you forgot to specify that

"linked" status MUST NOT be combined with either "clientLinkProhibited" or "serverLinkedProhibited" status.

This is related to the proposal on 3.4 above.  There is no need for the sentence “"linked" status MUST NOT be combined with either "clientLinkProhibited" or "serverLinkedProhibited" status.” since the [client/server]LinkProhibited statuses only prohibit future links.


4.1.2<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-4.1.2>.  EPP <info> Command

Should we mention what happens in case the querying client is not the sponsoring client, or is too much policy?

Yes, I believe that returning the organization object and what organization object attributes to return is up to server policy.  Maybe it makes sense to add a sentence related to it being up to server policy.

[…]
   When an <info> command has been processed successfully, the EPP
   <resData> element MUST contain a child <org:infData> element that
   identifies the organization namespace.  The <org:infData> element
   contains the following child elements:
[…]
   o  Zero or more <org:status> elements that contains the operational
      status of the organization, as defined in Section 3.4<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.4>.

⇒ this conflicts with the XML schema and 3.4, which states:
   An organization object MUST always have at least one associated
   status value.  The default value is "ok".

I agree that it should it should be “One or more <org:status> elements...” to match the XML schema.

 4.2.5<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-4.2.5>. EPP <update> Command
[...]
Zero or more <org:role> elements that contains the role type, role
      statuses and optional role id of the organization

In my opinion the draft is still vague about which role sub-element of role is used for matching the role to be removed (I guess it is the role type, as it is the only required element). I would mention that:

E.g. in secDNS it is mentioned very explicit;

      The <secDNS:keyData> element is part of the Key Data Interface and
      is used to uniquely define the key data to be removed, by using
      all four elements -- <secDNS:flags>, <secDNS:protocol>, <secDNS:
      alg>, and <secDNS:pubKey> -- that are guaranteed to be unique.
      There can be more than one DS record created for each key, so
      removing a key could remove more than one DS record.

The role type is what is unique for the organization’s role.  There cannot be duplicate role types for an organization.  It would be clearer to specify “A <org:type> element contains the role type of the organization, as defined in Section 3.2.  The role type uniquely identifies the role to update.”.

Good instructions for how to remove a contact, I would also add these instructies to parentId, voice, fax email and url:
An empty <org:___> element is supported to allow a type of
      ___ to be removed

===

Maybe it would be best to adopt the language from IETF-98 “Contact Postal Info Elements Discussion”, which included the proposal:


  1.  The <contact:chg> sub-elements do have replace semantics

     *   Existing sub-element data deleted first and then set with updated data.

  1.  <contact:postalInfo> types treated independently

     *   Exclusion of a <contact:postalInfo> type does not implicitely delete it.

  1.  <contact:postalInfo> type deleted via empty element

     *   <contact:postalInfo type=”int/> or <contact:postalInfo type=”loc”/>

The elements supported by the <org:add> and <org:rem> are the list elements <org:contact>, <org:role>, and <org:status>.  The individual attributes (postalInfo can be considered two separate attributes “int” and “loc”) are updated using the <org:chg>.  Maybe the introduction sentence “An OPTIONAL <org:chg> element containing the following element, where at least one child element MUST be present”, can be revised to clarify how the simple elements and complex child elements added, updated, or removed via the <org:chg> element.  How about something like “An OPTIONAL <org:chg> element used to add, update, and delete non-list organization attributes.  An empty <org:chg> sub-element (<org:parentId>, <org:voice>, <org:fax>, <org:email>, and <org:url>, <org:postalInfo> with “type” attribute) is used to remove it and a non-empty sub-element is used to replace it.  For the <org:postalInfo> complex sub-element, the types (“int” and “loc”) are treated independently with replace semantics, where the <org:postalInfo> sub-element data is deleted first and then set with the update data.  The <org:chg> element MUST contain one of the following child elements:”.

There is one big item with my proposal in supporting the removal of the simple <org:postalInfo> sub-elements using empty elements in that the XSD does not support empty elements with the following type definitions:


  1.  parentId - eppcom:clIDType

     *     <simpleType name="clIDType">
     *       <restriction base="token">
     *         <minLength value="3"/>
     *         <maxLength value="16"/>
     *       </restriction>
     *     </simpleType>

  1.  voice – org: e164Type

     *     <complexType name="e164Type">
     *               <simpleContent>
     *                 <extension base="org:e164StringType">
     *                           <attribute name="x" type="token" />
     *                 </extension>
     *               </simpleContent>
     *     </complexType>
     *     <simpleType name="e164StringType">
     *               <restriction base="token">
     *                 <pattern value="(\+[0-9]{1,3}\.[0-9]{1,14})?" />
     *                 <maxLength value="17" />
     *               </restriction>
     *     </simpleType>

  1.  fax – org:e164Type

     *   Same as voice

  1.  email – eppcom:minTokenType

     *     <simpleType name="minTokenType">
     *       <restriction base="token">
     *         <minLength value="1"/>
     *       </restriction>
     *     </simpleType>

  1.  url – anyURI

     *   Does support empty element

The alternative is to make removal explicit with the <org:rem> element by supporting a list of empty elements to remove instead of using the <org:chg> element with empty elements.  For example, the <org:rem> element can support removing elements from the list attributes and can be used to remove the non-list attributes with empty elements (<org:parentId>, <org:voice>, <org:fax>, <org:email>, and <org:url>, <org:postalInfo> with “type” attribute).  This is different from the semantics for RFC 5733.  If this is the case, should the <org:add> element only be capable of adding list items or should it be used to add non-existing attributes.

Thoughts?


===

Shouldn't we have a section like RFC 5731, 5732, 5733 regarding offline review of requested actions?

===

Yes, that makes sense.

===

Do we need to remove the Change Log section?

===

The change log will get removed prior to publication by the RFC Editor.

===

XSD maxOccurs opinion:

<element name="status"
            type="org:statusType" maxOccurs="9"/>

Why 9? I would set this to unbounded. A client may send an org create with 10 times clientDeleteProbited. It should just work.

I thought the same thing, but if you do the math, the maximum number of unique statuses is 9.  The statuses are unique and there should be no duplicates.  If you look at the RFC 5733, the statuses are defined with a maximum, which is being mirrored here based on the unique set of organization statuses.


===

XSD sequence anti pattern


we keep on copying old XML schema's, and hence, for data structures we keep on using xsd:sequence (ordered) instead of xsd:choice. If order is not important (which is the case in this draft and a lot of other RFCs), don't enforce it. It makes implementation and testing often unnecessarily harder.

I don’t view the use of XSD sequence as an anti pattern.  I believe the sequence makes implementation and testing easier and not harder.


===

Model issue: because org:name is part of org:postalInfo, and org:addr is also part of org:postalInfo but required, it is impossible create an organization with a name, but without address... I think this must be possible as this was one of the first discussions in the mailing list: reseller in a separate object vs. or simply add ID and name to a domain.

Proposal: move org:name to a higher level (it's not the name belonging to the address of the org, but the name belonging to the org itself)

How about simply making the addr element in the org:postalInfoType optional (minOccurs=”0”) and add OPTIONAL to the references to <org:addr> in the text?

—

JG

[cid:[e-mail]933A30]

James Gould
Distinguished Engineer
[e-mail]

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

Verisign.com<http://verisigninc.com/>

From: regext <[e-mail]> on behalf of Pieter Vandepitte <[e-mail]>
Date: Saturday, May 19, 2018 at 4:31 PM
To: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] [regext] Final review of draft-ietf-regext-org-06

Hi Linlin,

I did a review with a magnifying glass. Some things should really be fixed (or rather MUST be fixed), some others are opinionated.

I'm preparing a review of the draft-ietf-regext-org-ext-06 too, but that's for tomorrow

===

3.1<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.1>.  Organization Identifier
All EPP organizations are identified by a server-unique identifier.
   Organization identifiers are character strings with a specific
   minimum length, a specified maximum length, and a specified format.
   Organization identifiers use the "clIDType" client identifier syntax
   described in [RFC5730<https://tools.ietf.org/html/rfc5730>].  Its corresponding element is <org:id>.

I would use "specified" instead of "specific". This is more in line with other RFCs (domain and contact). It's also a specific length, format etc… but the emphasis is on the fact that it's all in the specs (hence specified).

===

3.2<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.2>.  Organization Roles
The organization roles are used to represent the relationship an
   organization would have.  Its corresponding element is <org:role>.

⇒ MUST instead of would

An organization object MUST always have at least one associated role. Roles can be set only by the client that
Sponsors an organization object. A client can change the role of an organization object using the EPP <update> command.

===

3.2.1<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.2.1>.  Role Type
An organization would support a list of roles.  See Section 7.3<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-7.3> for a
   list of values.  Its corresponding element is <org:type>.

I think the sentence is wrong. You should talk about role type, not about "list of roles"

An organization role MUST have a type. […]

===

3.2.2<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.2.2>.  Role Status
A role of an organization object would have its own statuses.  Its
   corresponding element is <org:status>.  The values of the role status
   are defined in Section 3.5<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.5>.

I'm not sure if "would" is the best word to use here.

An organization role MAY have a status. […]

===

3.4<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.4>.  Organization Status Values

I think you forgot to specify that

"linked" status MUST NOT be combined with either "clientLinkProhibited" or "serverLinkProhibited" status.

Or is this in case you want to block linking while there are still links? If so, it's useful to specify this:

A client or server MAY combine linked with either clientLinkProhibited or serverLinkProhibited if new links must be prohibited [...]

===

3.5<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.5>.  Role Status Values

[…]

o  ok: This is the normal status value for an role that has no
      pending operations or prohibitions.  This value is set and removed
      by the server as other status values are added or removed.

⇒ There are no pending statuses for role statuses, so remove that part

Also here, I think you forgot to specify that

"linked" status MUST NOT be combined with either "clientLinkProhibited" or "serverLinkedProhibited" status.

===

4.1.2<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-4.1.2>.  EPP <info> Command

Should we mention what happens in case the querying client is not the sponsoring client, or is too much policy?

And a bit lower:

[…]
   When an <info> command has been processed successfully, the EPP
   <resData> element MUST contain a child <org:infData> element that
   identifies the organization namespace.  The <org:infData> element
   contains the following child elements:
[…]
   o  Zero or more <org:status> elements that contains the operational
      status of the organization, as defined in Section 3.4<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.4>.

⇒ this conflicts with the XML schema and 3.4, which states:
   An organization object MUST always have at least one associated
   status value.  The default value is "ok".

===

 4.2.5<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-4.2.5>. EPP <update> Command
[...]
Zero or more <org:role> elements that contains the role type, role
      statuses and optional role id of the organization

In my opinion the draft is still vague about which role sub-element of role is used for matching the role to be removed (I guess it is the role type, as it is the only required element). I would mention that:

E.g. in secDNS it is mentioned very explicit;

      The <secDNS:keyData> element is part of the Key Data Interface and
      is used to uniquely define the key data to be removed, by using
      all four elements -- <secDNS:flags>, <secDNS:protocol>, <secDNS:
      alg>, and <secDNS:pubKey> -- that are guaranteed to be unique.
      There can be more than one DS record created for each key, so
      removing a key could remove more than one DS record.

===

Good instructions for how to remove a contact, I would also add these instructies to parentId, voice, fax email and url:
An empty <org:___> element is supported to allow a type of
      ___ to be removed

===

From the examples, I guess that a role is removed by only matching the type (recall my comments on deleting roles, it must be obvious by reading the text, not by deducing that from the examples). This implies that there's only one role with a specific type allowed. Mention this in 3.2.1. : An organization MUST only have one role for a specific role type.

===

Shouldn't we have a section like RFC 5731, 5732, 5733 regarding offline review of requested actions?

===

Not sure if there is a legalese paragraph required in 5. Formal Syntax

===

6. Internationalization Considerations

   As an extension of the EPP organization object mapping, the elements
   and element content described in this document MUST inherit the
   internationalization conventions used to represent higher-layer
   domain and core protocol structures present in an XML instance that
   includes this extension.

⇒ This RFC is not an extension of itself. I would use the same text as in RFC 5733, especially regarding usage of date and time and the use of int and loc address info:

   All date-time values presented via EPP MUST be expressed in Universal
   Coordinated Time using the Gregorian calendar.  The XML Schema allows
   use of time zone identifiers to indicate offsets from the zero
   meridian, but this option MUST NOT be used with EPP.  The extended
   date-time form using upper case "T" and "Z" characters defined in
   [W3C.REC-xmlschema-2-20041028<https://tools.ietf.org/html/rfc5733#ref-W3C.REC-xmlschema-2-20041028>] MUST be used to represent date-time
   values, as the XML Schema does not support truncated date-time forms
   or lower case "T" and "Z" characters.
Humans, organizations, and other entities often need to represent
   social information in both a commonly understood character set and a
   locally optimized character set.  This specification provides
   features allowing representation of social information in both a
   subset of UTF-8 for broad readability and unrestricted UTF-8 for
   local optimization.

I personally have issues with the above claim that "int" - or US-ASCII - is commonly understood, but I can live with that for now ;-)  ( I hope in future drafts we can just simply drop the address type )

===

Do we need to remove the Change Log section?

===

XSD maxOccurs opinion:

<element name="status"
            type="org:statusType" maxOccurs="9"/>

Why 9? I would set this to unbounded. A client may send an org create with 10 times clientDeleteProbited. It should just work.

===

XSD sequence anti pattern


we keep on copying old XML schema's, and hence, for data structures we keep on using xsd:sequence (ordered) instead of xsd:choice. If order is not important (which is the case in this draft and a lot of other RFCs), don't enforce it. It makes implementation and testing often unnecessarily harder.

===

Model issue: because org:name is part of org:postalInfo, and org:addr is also part of org:postalInfo but required, it is impossible create an organization with a name, but without address... I think this must be possible as this was one of the first discussions in the mailing list: reseller in a separate object vs. or simply add ID and name to a domain.

Proposal: move org:name to a higher level (it's not the name belonging to the address of the org, but the name belonging to the org itself)

===



Kind regards

Pieter