On Tue, Oct 30, 2018 at 7:25 PM Linlin Zhou <[email protected]> wrote:
> 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. *S**tatus 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 > > I think we are talking past each other. The question I am asking is what is the access control algorithm for changing other values depending on whether {client,server}UpdateProhibited is set. -Ekr > >>> >>> >>> >>> 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 [email protected] https://www.ietf.org/mailman/listinfo/regext
