On Mon, Oct 29, 2018 at 1:17 AM Linlin Zhou <zhoulin...@cnnic.cn> wrote:
> 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. > > I'm sorry, but this still isn't clear. Can you perhaps send some pseudocode? > >> >> >> >> 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. > > ---------------------------------------------------------------------- > 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. > > >> 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. > > >> 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. -Ekr > -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
