Eric,
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.
I provide a description of the access control algorithm that is defined in the
EPP RFCs (5731-5733) and in draft-ietf-regext-org below:
clientUpdateProhibited Case:
Pre-condition: Organization “res1523” has the clientUpdateProhibited Status
Access Control Algorithm:
If (Organization <update> Command received with only a
<org:rem><org:status>clientUpdateProhibited</org:status></org:rem> update) then
Execute Change
Return Success 1000 “Command completed successfully”
Else // Other updates included with Organization <update> Command
Reject Change
Return 2304 “Object status prohibits operation”
serverUpdateProhibited Case:
Pre-condition: Organization “res1523” has the serverUpdateProhibited Status
Access Control Algorithm:
If (Organization <update> Command received) then
Reject Change
Return 2304 “Object status prohibits operation”
The clientUpdateProhibited status blocks all updates except removing of the
clientUpdateProhibited status by the client. The serverUpdateProhibited status
blocks all client updates. The client cannot set or unset (alter) the server
statuses, including the serverUpdateProhibited status.
I hope this helps clarify the EPP access control algorithm that is defined in
the EPP RFCs (5731-5733) and in draft-ietf-regext-org. Let me know if you need
any further clarification.
Thanks,
—
JG
[cid:image001.png@01D255E2.EB933A30]
James Gould
Distinguished Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
From: Eric Rescorla <e...@rtfm.com>
Date: Wednesday, October 31, 2018 at 10:24 AM
To: "zhoulin...@cnnic.cn" <zhoulin...@cnnic.cn>
Cc: "regext-cha...@ietf.org" <regext-cha...@ietf.org>,
"pieter.vandepi...@dnsbelgium.be" <pieter.vandepi...@dnsbelgium.be>, iesg
<i...@ietf.org>, "regext@ietf.org" <regext@ietf.org>,
"draft-ietf-regext-...@ietf.org" <draft-ietf-regext-...@ietf.org>
Subject: [EXTERNAL] Re: Re: [regext] Eric Rescorla's Discuss on
draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Resent-From: <alias-boun...@ietf.org>
Resent-To: <zhoulin...@cnnic.cn>, <ietf...@gmail.com>, <zhouguiq...@cnnic.cn>,
<ya...@cnnic.cn>, James Gould <jgo...@verisign.com>
Resent-Date: Wednesday, October 31, 2018 at 10:24 AM
On Tue, Oct 30, 2018 at 7:25 PM Linlin Zhou
<zhoulin...@cnnic.cn<mailto: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
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
