Dear Eric, Please see my feedbaks below. 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. I'm sorry, but this still isn't clear. Can you perhaps send some pseudocode? [Linlin] Our proposal is to add the lead-in bolded text to match the existing EPP RFC's to the Organization mapping. There has been no issues with the interpretation of the statuses with the EPP RFCs, so it's best to match them as closely as possible. In section 3.4, An organization object MUST always have at least one associated status value. Status values can be set only by the client that sponsors an organization object and by the server on which the object resides. A client can change the status of an organization object using the EPP <update> command. Each status value MAY be accompanied by a string of human-readable text that describes the rationale for the status applied to the object. A client MUST NOT alter status values set by the server. A server MAY alter or override status values set by a client, subject to local server policies. The status of an object MAY change as a result of either a client-initiated transform command or an action performed by a server operator. Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". The "hold" and "terminated" status values are server-managed when the organization has no parent identifier [Section 3.6] and otherwise MAY be client- managed based on server policy. Status values that do not begin with either "client" or "server" are server-managed. Take "clientUpdateProhibited" for example. If status value "clientUpdateProhibited" is set by a client then <update> command is not allowed to perform by a client If status value "clientUpdateProhibited" is removed by a client or a server then no limitation of performing EPP commands 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." Does that mean the other attributes are mandatory? If so, you need to say that. [Linlin] Yes, thank you. If the element can appear once, the keyword "OPTIONAL" is used to specify it as an optional element. If the element can appear multiple times, the word "zero" is used to specify it as an optional element. Other elements are mandatory. ---------------------------------------------------------------------- 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. Then you should say so in the text. [Linlin] Yes. Please see the above updated text in section 3.4. "Status values that do not begin with either "client" or "server" are server-managed." 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. Sorry, still not clear. [Linlin] Please see the first issue feedback. 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. This is a comment, not a DISCUSS, so you're free to ignore it, but as someone who as implemented quite a few specifications, I don't agree with the claim that it would make things more difficult for implementors. Implementors want to reuse code and if it's a lot of work to see the difference between two parts of the spec, this leads to mistakes. 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). Again, it's *not* easier for implementors [Linlin] We want to have this document match what has been done in the other EPP RFCs. People always feel convenient with the existing patterns. As implementers of the EPP RFCs, they have been familiar with the EPP spcifications for years and we believe that it makes things easier for implementers. -Ekr
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
