Dear Pieter,
Please find my feedbacks below on other comments besides James' feedbacks.
Thanks for your review. I am preparing the update.
Regards,
Linlin
zhoulin...@cnnic.cn
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
