On Thu, Oct 25, 2018 at 2:44 AM Linlin Zhou <zhoulin...@cnnic.cn> wrote:
> Dear Eric, > Thanks for your review. Please see my feedbacks below with [Linlin]. > > Regards, > Linlin > ------------------------------ > Linlin Zhou > > > *From:* Eric Rescorla <e...@rtfm.com> > *Date:* 2018-10-25 02:05 > *To:* The IESG <i...@ietf.org> > *CC:* regext-chairs <regext-cha...@ietf.org>; Pieter Vandepitte > <pieter.vandepi...@dnsbelgium.be>; draft-ietf-regext-org > <draft-ietf-regext-...@ietf.org>; regext <regext@ietf.org> > *Subject:* [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: > (with DISCUSS and COMMENT) > Eric Rescorla has entered the following ballot position for > draft-ietf-regext-org-11: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-regext-org/ > > > > ---------------------------------------------------------------------- > 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". > > > > S 4.1.2. > > C: <org:id>res1523</org:id> > > C: </org:info> > > C: </info> > > C: <clTRID>ABC-12345</clTRID> > > C: </command> > > C:</epp> > > So I can only <info> one org? > [Linlin] Yes, <info> command supports one org id. > > Ok. > > 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. > > S 3.4. > > rejected. > > > > o linked: The organization object has at least one active > > association with another object. The "linked" status is not > > explicitly set by the client. Servers should provide services to > > determine existing object associations. > > I'm not following this text. It is set by the server? > [Linlin] Yes, it is set by the server. Benjamin's comment will be adopted. > Adding a sentence to clarify. "Other status values that do not begin with > either "client" or "server" are server-managed". > > > 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"? > 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. > > > > S 3.6. > > not defined for the top level reseller, namely the registrar of the > > registry. An N-tier reseller has a parent reseller and at least one > > child reseller. A reseller customer has a parent reseller and no > > child resellers. > > > > Loops MUST be prohibited. For example: if organization A has B as > > Who is this a levy on? The server MUST enforce it? What does it do if > there is an error? > [Linlin] It is up to the servers to manage the organization levels. For > example, if client creates a new organization with parentID, the server > should validate this ID has no loop relation with others. If validation > fails , the server should respond with an error code such as "2305" or > other proper error codes. > > OK, that would be good to explain. > S 4.1.2. > > email address. > > > > o An OPTIONAL <org:url> element that contains the URL to the > website > > of the organization. > > > > o Zero or more OPTIONAL <org:contact> elements that contain > > Isn't 0 and OPTIONAL redundant? > [Linlin] Yes. This will be updated. > > S 4.1.2. > > organization object. Contact object identifiers MUST be known to > > the server before the contact object can be associated with the > > organization object. The required "type" is used to represent > > contact types. The type values include "admin", "tech", > > "billing", "abuse", and "custom". The OPTIONAL "typeName" > > attribute is used to define the name of a "custom" type. > > Are duplicates allowed? > [Linlin] If you mean the org can have two contacts with the same "admin" > type, this is allowed according to the XML schema. > > 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? > > 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. -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
