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

[Eric Rescorla <[e-mail]>]

On Tue, Oct 30, 2018 at 7:25 PM Linlin Zhou <[e-mail]> wrote:

> Dear Eric,
> Please see my feedbaks below.
>
> 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?
> [Linlin] Our proposal is to add the lead-in bolded text to match the
> existing EPP RFC's to the Organization mapping. There has been no issues
> with the interpretation of the statuses with the EPP RFCs, so it's best to
> match them as closely as possible. In section 3.4,
>
> An organization object MUST always have at least one associated status
> value.
>
>
>
>
> *Status values can be set only by the client that sponsors an organization
> object and by the server on which the object resides. A client can change
> the status of an organization object using the EPP <update> command. Each
> status value MAY be accompanied by a string of human-readable text that
> describes the rationale for the status applied to the object. *
>
>
>
>
>
> *A client MUST NOT alter status values set by the server. A server MAY
> alter or override status values set by a client, subject to local server
> policies. The status of an object MAY change as a result of either a
> client-initiated transform command or an action performed by a server
> operator.*
>
> Status values that can be added or removed by a client are prefixed
> with "client". Corresponding status values that can be added or
> removed by a server are prefixed with "server". The "hold" and
> "terminated" status values are server-managed when the organization
> has no parent identifier [Section 3.6] and otherwise MAY be client-
> managed based on server policy. *S**tatus values that *
> * do not begin with either "client" or "server" are server-managed.*
>
> Take "clientUpdateProhibited" for example.
> If status value "clientUpdateProhibited" is set by a client
> then <update> command is not allowed to perform by a client
> If status value "clientUpdateProhibited" is removed by a client or a
> server
> then no limitation of performing EPP commands
>
>
I think we are talking past each other. The question I am asking is what is
the access control algorithm for changing other values depending on whether
{client,server}UpdateProhibited is set.

-Ekr


>
>>>
>>>
>>>
>>> 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.
> [Linlin] Yes, thank you.
> If the element can appear once, the keyword "OPTIONAL" is used to specify
> it as an optional element.
> If the element can appear multiple times, the word "zero" is used to
> specify it as an optional element.
> Other elements are mandatory.
>
>
>>
>> ----------------------------------------------------------------------
>> 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.
> [Linlin] Yes. Please see the above updated text in section 3.4. "Status
> values that
> do not begin with either "client" or "server" are server-managed."
>
>>
>>
>>> 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.
> [Linlin] Please see the first issue feedback.
>
>>
>>
>>> 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
> [Linlin] We want to have this document match what has been done in the
> other EPP RFCs. People always feel convenient with the existing patterns.
> As implementers of the EPP RFCs, they have been familiar with the EPP
> spcifications for years and we believe that it makes things easier for
> implementers.
>
> -Ekr
>
>>