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

[Eric Rescorla <[e-mail]>]

On Wed, Nov 7, 2018 at 11:22 PM Gould, James <[e-mail]> wrote:

> Eric,
>
>
>
> No, both statuses only stops the client from doing updates.  The
> difference is that the server can only set and unset the
> serverUpdateProhibited status.  The prohibited statuses don’t apply to the
> server executing the commands.
>
>
>
> Based on this, the revised sentence would read:
>
>
>
> If clientUpdateProhibited or serverUpdateProhibited is set, the client
> will not be able to update the object.  For clientUpdateProhibited, the
> client will first need to remove clientUpdateProhibited prior to attempting
> to update the object.
>

>
>
> Does that help?
>

Yes. Could you add a sentence that says that the server can modify anything
at any time?

In any case, I think we're on the same page. I'll clear my DISCUSS and
trust you to update.

Thanks,
-Ekr

—
>
>
>
> JG
>
>
> [image: 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: *Thursday, November 8, 2018 at 10:48 AM
> *To: *James Gould <[e-mail]>
> *Cc: *Benjamin Kaduk <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, IESG <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *Subject: *[EXTERNAL] Re: 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: *Thursday, November 8, 2018 at 10:48 AM
>
>
>
> OK, so I think the key point here is that either "clientUpdateProhibites"
> or "serverUpdateProhibited" will stop both sides from doing updates.
>
>
>
> So I think what I would say is somewhere:
>
> Note that if clientUpdateProhibited is set, the client will not be able to
> update the object. It will first need to remove that field prior to
> attempting to update the object.
>
>
>
> Would that work?
>
> -Ekr
>
>
>
>
>
>
>
>
>
> On Wed, Nov 7, 2018 at 3:39 AM Gould, James <[e-mail]> wrote:
>
> Benjamin,
>
>
>
> This seems overly zealous to the point of being harmful.  For example, if a
>
> server sets the status to "ok", a client cannot replace it by
>
> clientLinkProhibited?
>
>
>
> The “ok” status is the default status and not classified as a server
> status, since it is not prefixed with “server”.  The sentence “A client
> MUST NOT alter status values set by the server.” means that the client
> cannot set or remove a server status, such as serverUpdateProhibited.  I
> hope this clarifies what is defined in the EPP RFCs (5730-5733) and
> draft-ietf-regext-org.
>
>
>
> Thanks,
>
>
>
> —
>
> JG
>
>
>
>
>
>
>
> James Gould
>
> Distinguished Engineer
>
> [e-mail]
>
>
>
> 703-948-3271
>
> 12061 Bluemont Way
>
> Reston, VA 20190
>
>
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> On 10/31/18, 10:23 AM, "Benjamin Kaduk" <[e-mail]> wrote:
>
>
>
>     Trimming to just one potentially problematic suggestion...
>
>
>
>     On Wed, Oct 31, 2018 at 10:25:42AM +0800, Linlin Zhou wrote:
>
>     >
>
>     > Linlin Zhou
>
>     >
> ----------------------------------------------------------------------
>
>     > DISCUSS:
>
>     >
> ----------------------------------------------------------------------
>
>     [...]
>
>     > [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,
>
>
>
>     [bold does not work super-well in text/plain mail, but
>
>     https://www.ietf.org/mail-archive/web/regext/current/msg01912.html
> can show
>
>     it]
>
>
>
>     > 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
>
>
>
>     This seems overly zealous to the point of being harmful.  For example,
> if a
>
>     server sets the status to "ok", a client cannot replace it by
>
>     clientLinkProhibited?
>
>
>
>     -Benjamin
>
>
>
>     > 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
>
>     >
>
>     >
>
>     >
>
>     >
>
>
>
>