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

[Pieter Vandepitte <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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] <mailto:[e-mail]>
> 
> From: Pieter Vandepitte <mailto:[e-mail]>
> Date: 2018-05-20 04:29
> To: regext <mailto:[e-mail]>
> 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 <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).
> 
> [Linlin] Changed to "with a specified minimum length".
> ===
> 
>> 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.
>  [Linlin] Yes.
> ===
> 
>> 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. […]
> 
> [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 <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. […]
> 
> [Linlin] OK.
> ===
> 
>> 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 [...]
> 
> [Linlin] Yes, "clientLinkProhibited" or "serverLinkProhibited" can combine with "linked" if new links must be prohibited. Your suggested sentence will be added.
> ===
> 
>> 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.
> 
> [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 <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 )
> 
> [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
> 
> 
>