Dear Eric, Thanks for your review. Please see my feedbacks below with [Linlin].
Regards, Linlin Linlin Zhou From: Eric Rescorla Date: 2018-10-25 02:05 To: The IESG CC: regext-chairs; Pieter Vandepitte; draft-ietf-regext-org; regext 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. 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. 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? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 3.2.1. > object. A client can change the role of an organization object using > the EPP <update> command. > > 3.2.1. Role Type > > An organization role MUST have a type which supports a list of Editorial: I found this confusing. I think you want to say "MUST have a type field. This may have any of the values listed in ...." It's not the type that supports the list. [Linlin] Yes, thank you for your text. 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. 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. 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. 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. _______________________________________________ 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
