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

From: Pieter Vandepitte <[email-masked]>
Date: Sat, 19 May 2018 22:29:58 +0200

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

---

From: "Gould, James" <[email-masked]>
Date: Mon, 21 May 2018 13:40:42 +0000

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

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

[…]

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

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.

[…]
      status of the organization, as defined in Section 3.4<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.4>.

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

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

===

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?

===

===

Yes, that makes sense.

===

===

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

===

XSD maxOccurs opinion:

<element name="status"

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.

===

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.

===

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

James Gould
Distinguished Engineer
[email-masked]

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

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

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

Hi Linlin,

===

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>.

===

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

===

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>.

===

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>.

===

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

===

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

[…]

===

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

And a bit lower:

[…]
      status of the organization, as defined in Section 3.4<https://tools.ietf.org/html/draft-ietf-regext-org-06#section-3.4>.

===

 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

===

===

===

===

===

   [W3C.REC-xmlschema-2-20041028<https://tools.ietf.org/html/rfc5733#ref-W3C.REC-xmlschema-2-20041028>] MUST be used to represent date-time

===

===

XSD maxOccurs opinion:

<element name="status"

===

===

===

Kind regards

Pieter

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 22 May 2018 10:49:03 +0800

Dear Pieter,
Please find my feedbacks below on other comments besides James' feedbacks. Thanks for your review. I am preparing the update.

Regards,
Linlin

[email-masked]
 
From: Pieter Vandepitte
Date: 2018-05-20 04:29
To: regext
Subject: [regext] Final review of draft-ietf-regext-org-06
Hi Linlin,

===
 
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].  Its corresponding element is <org:id>.

[Linlin] Changed to "with a specified minimum length".
=== 
 
3.2.  Organization Roles
 
⇒ MUST instead of would

 [Linlin] Yes.
===

3.2.1.  Role Type
An organization would support a list of roles.  See Section 7.3 for a
   list of values.  Its corresponding element is <org:type>.

[Linlin] "An organization role MUST have a type which support a list of values.  See Section 7.3 for the role type values."
===
 
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.

 
[Linlin] OK.
===
 
3.4.  Organization Status Values

 

[Linlin] Yes, "clientLinkProhibited" or "serverLinkProhibited" can combine with "linked" if new links must be prohibited. Your suggested sentence will be added.
=== 
 
3.5.  Role Status Values
 
[…]

 

[Linlin] Please see the above feedback.
===
......

 
 
   [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time

[Linlin] I'll update this section to be compliant with other EPP RFCs. 
===

[Linlin] Yes, I'd like to remove them when it is published.
===

XSD maxOccurs opinion:
 
<element name="status"

[Linlin] The max unique statuses number is 9. For example, "hold", "linked", "clientLinkProhibited", "serverLinkProhibited", "clientUpdateProhibited", "serverUpdateProhibited", "clientDeleteProhibited", "serverDeleteProhibited", and "pendingUpdate" can be shown together.

......

Kind regards

Pieter

---

From: Pieter Vandepitte <[email-masked]>
Date: Tue, 22 May 2018 14:53:03 +0200

Hi Linlin, James,

One thing that is still not very clear to me. (and the draft offers me no answer)

Suppose a new organization O with 2 roles (R1 and R2). Status of the organization is 'ok', status of the roles are both 'ok'. Right?
Then I link a domain to O via R1. Is it right that status of O is 'linked', status of R1 is 'linked' and status of R2 is ok?

kind regards

Pieter

> On 22 May 2018, at 04:49, Linlin Zhou <[email-masked]> wrote:
> 
> Dear Pieter,
> [email-masked] <mailto:[email-masked]>
> 
> From: Pieter Vandepitte <mailto:[email-masked]>
> Date: 2018-05-20 04:29
> To: regext <mailto:[email-masked]>

---

From: "Gould, James" <[email-masked]>
Date: Tue, 22 May 2018 14:25:02 +0000

Peiter,

You are correct, by adding a link of a domain to O via R1, both O and R1 would have the “linked” status and R2 would have the “ok” status.  The reason is that there is at least one active link (of any role) to the organization (O “linked” status), there is at least one active R1 link (R1 “linked” status), and there is no active R2 link (R2 “ok” status).

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

From: regext <[email-masked]> on behalf of Pieter Vandepitte <[email-masked]>
Date: Tuesday, May 22, 2018 at 8:53 AM
To: Linlin Zhou <[email-masked]>
Cc: regext <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Final review of draft-ietf-regext-org-06

Hi Linlin, James,

kind regards

Pieter

On 22 May 2018, at 04:49, Linlin Zhou <[email-masked]<mailto:[email-masked]>> wrote:

Dear Pieter,

Regards,
Linlin
________________________________
[email-masked]<mailto:[email-masked]>

From: Pieter Vandepitte<mailto:[email-masked]>
Date: 2018-05-20 04:29
To: regext<mailto:[email-masked]>
Subject: [regext] Final review of draft-ietf-regext-org-06
Hi Linlin,

===

⇒ MUST instead of would

[Linlin] OK.
===

[…]

XSD maxOccurs opinion:

<element name="status"

......

Kind regards

Pieter

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 24 May 2018 20:01:47 +0200

I'm sorry to not have answered your questions up until now... @Linlin, do you take into account the remarks of James too?

> On 21 May 2018, at 15:40, Gould, James <[email-masked]> wrote:
> 
> Pieter,
>  

Ok

> 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…

Ok

> 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 ser…

That would be great

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

Ok

> 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…

It would have helped me if that would have been included. It'd be nice if this text is added.

> The <contact:chg> sub-elements do have replace semantics
> Existing sub-element data deleted first and then set with updated data.
> <contact:postalInfo> types treated independently
> Exclusion of a <contact:postalInfo> type does not implicitely delete it.
> <contact:postalInfo> type deleted via empty element
> <contact:postalInfo type=”int/> or <contact:postalInfo type=”loc”/>
>  
> parentId - eppcom:clIDType
>   <simpleType name="clIDType">
>     <restriction base="token">
>       <minLength value="3"/>
>       <maxLength value="16"/>
>     </restriction>
>   </simpleType>
> 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>
> fax – org:e164Type
> Same as voice
> email – eppcom:minTokenType
>   <simpleType name="minTokenType">
>     <restriction base="token">
>       <minLength value="1"/>
>     </restriction>
>   </simpleType>
> url – anyURI
> Does support empty element
>  

To be honest, I think it is OK as it is now. An empty postalInfo to remove it, otherwise, to update it, provide the complete contents of the postalInfo (if I understand it well). It's pretty intuitive

> 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…

I can live with a 9

> 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. 

I'm trying to understand how it makes implementation and testing better. When parsing XML without XML to object binding libraries? 

> 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?

This would be a huge improvement. @Linlin, can you change this in both XSD and text?

Kind regards

Pieter

---

From: "Linlin Zhou" <[email-masked]>
Date: Fri, 25 May 2018 09:23:22 +0800

Yes , I will merge all the comments into the next version. Thanks for review.

Regards,
Linlin

[email-masked]
 
From: Pieter Vandepitte
Date: 2018-05-25 02:01
To: Gould, James
CC: [email-masked]
Subject: Re: [regext] Final review of draft-ietf-regext-org-06
I'm sorry to not have answered your questions up until now... @Linlin, do you take into account the remarks of James too?

Pieter,

===

 

Ok

=== 
 
3.5.  Role Status Values
 
[…]

 

Ok

4.1.2.  EPP <info> Command

That would be great

[…]
      status of the organization, as defined in Section 3.4.

Ok

 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

 

 
===

 

 
 
Thoughts? 

 
===

===
 
Yes, that makes sense.
 
===

===

===
 
XSD maxOccurs opinion:
 
<element name="status"

I can live with a 9

===

 

 
 
===

 

Kind regards

Pieter