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

[Eric Rescorla <[e-mail]>]

On Mon, Oct 29, 2018 at 1:17 AM Linlin Zhou <[e-mail]> wrote:

> Dear Eric,
> Please see my feedbacks inline. I've removed the clarified items.
>
> 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?

>
>>
>>
>>
>> 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.



>
> ----------------------------------------------------------------------
> 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.

>
>
>> 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.

>
>
>> 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.

-Ekr


> -Ekr
>
>
>>
>> _______________________________________________
>> regext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/regext
>>
>>