Dear Eric, Please see my feedbacks inline. I've removed the clarified items.
Regards, Linlin Linlin Zhou ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3624 This DISCUSS should be easy to clear. I have noted a few points where I do not believe that the spec is sufficiently clear to implement. DETAIL S 3.4. > > o clientUpdateProhibited, serverUpdateProhibited: Requests to update > the object (other than to remove this status) MUST be rejected. > > o clientDeleteProhibited, serverDeleteProhibited: Requests to delete > the object MUST be rejected. How does access control work here? If either of these values are set, then it must be rejected? [Linlin] If you mean that clientUpdateProhibited and serverUpdateProhibited are set, these two statuses can coexist in the system. "clientUpdateProhibited" is set by the client and "serverUpdateProhibited" is set by the server. That's not what I mean. What I mean is "what is the access control rule that the server is supposed to apply". [Linlin] The EPP statuses defined in draft-ietf-regext-org follows the model used in the other EPP RFC's, including RFC 5731- RFC 5733. The statuses define the command-level access control rules, where each supported transform command (update and delete) includes a corresponding client-settable ("client") and server-settable ("server") that prohibits execution of the command by the client. The client is allowed make an update only to remove the "clientUpdateProhibited" status when the "clientUpdateProhibited" status is set. Client-specific access control rules (e.g., sponsoring client versus non-sponsoring client) is not defined by the statuses, but is up to server policy. S 4.1.2. > > o One or more <org:status> elements that contain the operational > status of the organization, as defined in Section 3.4. > > o An OPTIONAL <org:parentId> element that contains the identifier of > the parent object, as defined in Section 3.6. It's not clear to me what's really optional here, because you say above that it's up to the server but then you label some stuff here as OPTIONAL [Linlin] If this sentence makes confusion. How about changing it to "It is up to the server policy to decide what optional attributes will be returned of an organization object." or just remove it? I don't know, because I don't understand the semantics you are aiming for. Are the other attributes optional. [Linlin] To be consistent with other EPP RFCs, I suggest removing the sentence "It is up to the server policy to decide what attributes will be returned of an organization object." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 3.4. > has been processed for the object, but the action has not been > completed by the server. Server operators can delay action > completion for a variety of reasons, such as to allow for human > review or third-party action. A transform command that is > processed, but whose requested action is pending, is noted with > response code 1001. Who can set this? [Linlin] The server can set the error code to 1001 and send the response to the client. Sorry, context got lost. Who can set "pendingCreate"? [Linlin] PendingCreate or PendingXXX statuses are set by servers. S 3.5. > association with another object. The "linked" status is not > explicitly set by the client. Servers SHOULD provide services to > determine existing object associations. > > o clientLinkProhibited, serverLinkProhibited: Requests to add new > links to the role MUST be rejected. see above question about access control [Linlin] If both the clientXXXProhibited and serverXXXProhibited are set, this situation is permitted. Sorry, this is still not clear to me. [Linlin] Please see the above response. S 4.2.1. > status of the organization, as defined in Section 3.4. > > o An OPTIONAL <org:parentId> element that contains the identifier of > the parent object, as defined in Section 3.6. > > o Zero to two <org:postalInfo> elements that contain postal-address These rules looks duplicative of <info>. Is there a way to collapse them? [Linlin] The attributes need to be defined differently for the create and the info response, since the info response needs to be more flexible with what is returned based on server policy decisions. Yes, they are the same elements, but whether they are required or optional may be different in a create than in a info response. The attributes are duplicated in the other EPP RFCs (RFC 5731 – 5733) for ease in implementation. Attempting to collapse the attributes will make it more difficult for implementors and will not be consistent with the other EPP RFCs. S 4.2.5. > where at least one child element MUST be present: > > o An OPTIONAL <org:parentId> element that contains the identifier of > the parent object.. > > o Zero to two <org:postalInfo> elements that contain postal-address This also seems duplicative. [Linlin] Indeed some elements descriptions appear some times in the document. I'd like to have some explanations here again. This document borrowed the text structure from RFC5731, RFC5732 and RFC5733 of EPP. I think the intension of having some duplicated descriptions is for users' easy reading. When seeing the examples, they do not have to scroll up and down to find the elements definitions. Some descriptions are a little different, although <org:postalInfo> elements appear to be duplicated. Such as, "One or more <org:status> elements" in <info> response and "Zero or more <org:status> elements" in <create> command. Of course putting all the elements definitions in a section is a concise way for the document structure. It's much harder for implementors because they don't know how to refactor common code. [Linlin] Duplicating the attributes is needed to address server policy differences between create and the info response, to make it easier for implementors, and to be consistent with the other EPP RFCs (RFC 5731 - RFC 5733). -Ekr _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
