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