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

["Gould, James" <[e-mail]>]

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:[e-mail]933A30]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: Eric Rescorla <[e-mail]>
Date: Wednesday, October 31, 2018 at 10:24 AM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, iesg <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, James Gould <[e-mail]>
Resent-Date: Wednesday, October 31, 2018 at 10:24 AM


On Tue, Oct 30, 2018 at 7:25 PM Linlin Zhou <[e-mail]<mailto:[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






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