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

["Linlin Zhou" <[e-mail]>]

Dear Eric,
Sorry for my misunderstanding. Followings are some pseudocode examples for status value changes. But in the real domain business model, there may be other requirement limitations, running code may be different.  Please note that I just listed some major situations, not all of them.

1. organization create

add "pendingCreate"

2. organization update

if ("serverUpdateProhibited" or "pendingDelete" or "pendingUpdate" existed) 
    cannot update
else 
    go 

if ("pendingCreate" existed) 
    can update but no "pendingUpdate" 
else 
    update and add "pendingUpdate"

if ("clientUpdateProhibited" existed) 
    cannot update
else 
    go 

if (recv 'remove clientUpdateProhibited' && other status update commands) 
    cannot update

3. organization delete

if ("clientDeleteProhibited" or "serverDeleteProhibited" or "pendingUpdate" or "pendingDelete" existed)//no pendingCreate 
    cannot delete 
    cannot add "pendingDelete" 

if ("pendingCreate" existed) 
    remove "pendingCreate" 
    add "pendingDelete" 

4. other status actions

if (organization is linked with an EPP object && "clientLinkedProhibited" or "serverLinkedProhibited" not exist) 
    add "linked" 

if (organization status is null || only "linked" existed) 
    add "ok" 
else 
    remove "ok"

Regards,
Linlin


Linlin Zhou
 
From: Eric Rescorla
Date: 2018-10-31 11:23
To: zhoulinlin
CC: regext-chairs; pieter.vandepitte; IESG; regext; draft-ietf-regext-org
Subject: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)


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