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 <zhoulin...@cnnic.cn> 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 > zhoulin...@cnnic.cn <mailto:zhoulin...@cnnic.cn> > > From: Pieter Vandepitte <mailto:pieter.vandepi...@dnsbelgium.be> > Date: 2018-05-20 04:29 > To: regext <mailto:regext@ietf.org> > 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 > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
