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

[Pieter Vandepitte <[e-mail]>]

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