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

["Linlin Zhou" <[e-mail]>]

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

Regards,
Linlin


[e-mail]
 
From: Pieter Vandepitte
Date: 2018-05-20 04:29
To: regext
Subject: [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.  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>.
 
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).

[Linlin] Changed to "with a specified minimum length".
=== 
 
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.
 [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>.

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

An organization role MUST have a 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.
 
I'm not sure if "would" is the best word to use here.

An organization role MAY have a status. […]
 
[Linlin] OK.
===
 
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 [...]

[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
 
[…]
 
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.
 
[Linlin] Please see the above feedback.
===
......

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] 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 )

[Linlin] I'll update this section to be compliant with other EPP RFCs. 
===
 
Do we need to remove the Change Log section?

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

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.

[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