Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Thu, Oct 25, 2018 at 2:44 AM Linlin Zhou <[e-mail]> wrote:

> Dear Eric,
> Thanks for your review. Please see my feedbacks below with [Linlin].
>
> Regards,
> Linlin
> ------------------------------
> Linlin Zhou
>
>
> *From:* Eric Rescorla <[e-mail]>
> *Date:* 2018-10-25 02:05
> *To:* The IESG <[e-mail]>
> *CC:* regext-chairs <[e-mail]>; Pieter Vandepitte
> <[e-mail]>; draft-ietf-regext-org
> <[e-mail]>; regext <[e-mail]>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext
>
>