Peiter, You are correct, by adding a link of a domain to O via R1, both O and R1 would have the “linked” status and R2 would have the “ok” status. The reason is that there is at least one active link (of any role) to the organization (O “linked” status), there is at least one active R1 link (R1 “linked” status), and there is no active R2 link (R2 “ok” status).
Thanks, — JG [cid:image001.png@01D255E2.EB933A30] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org> on behalf of Pieter Vandepitte <pieter.vandepi...@dnsbelgium.be> Date: Tuesday, May 22, 2018 at 8:53 AM To: Linlin Zhou <zhoulin...@cnnic.cn> Cc: regext <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Final review of draft-ietf-regext-org-06 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<mailto: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
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
