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

[Pieter Vandepitte <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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.  

Ok

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

Ok

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


That would be great

>  
> […]
>    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.

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

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

>  
> 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:
>  
> 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”/>
>  
> 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:
>  
> 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
>  
> 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? 
>  

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


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

I can live with a 9

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

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


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


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

Kind regards

Pieter