On Wed, Nov 7, 2018 at 11:22 PM Gould, James <jgo...@verisign.com> 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: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: *Thursday, November 8, 2018 at 10:48 AM > *To: *James Gould <jgo...@verisign.com> > *Cc: *Benjamin Kaduk <ka...@mit.edu>, "zhoulin...@cnnic.cn" < > zhoulin...@cnnic.cn>, "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: 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: *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 <jgo...@verisign.com> 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 > > jgo...@verisign.com > > > > 703-948-3271 > > 12061 Bluemont Way > > Reston, VA 20190 > > > > Verisign.com <http://verisigninc.com/> > > > > On 10/31/18, 10:23 AM, "Benjamin Kaduk" <ka...@mit.edu> 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 > > > > > > > > > > > > > > > >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
