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? 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? 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 ---------------------------------------------------------------------- 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. 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? 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? 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 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? 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? 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? 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. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
