Eric, Yes, that can be done, with one small change of “anything” to “the object” to be consistent with the subject of the modification. The complete revised text is:
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. The server can modify the object at any time. — 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: Thursday, November 8, 2018 at 2:30 PM 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: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT) On Wed, Nov 7, 2018 at 11:22 PM Gould, James <jgo...@verisign.com<mailto: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 [cid:image001.png@01D255E2.EB933A30] James Gould Distinguished Engineer jgo...@verisign.com<http://jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> Date: Thursday, November 8, 2018 at 10:48 AM To: James Gould <jgo...@verisign.com<mailto:jgo...@verisign.com>> Cc: Benjamin Kaduk <ka...@mit.edu<mailto:ka...@mit.edu>>, "zhoulin...@cnnic.cn<mailto:zhoulin...@cnnic.cn>" <zhoulin...@cnnic.cn<mailto:zhoulin...@cnnic.cn>>, "regext-cha...@ietf.org<mailto:regext-cha...@ietf.org>" <regext-cha...@ietf.org<mailto:regext-cha...@ietf.org>>, "pieter.vandepi...@dnsbelgium.be<mailto:pieter.vandepi...@dnsbelgium.be>" <pieter.vandepi...@dnsbelgium.be<mailto:pieter.vandepi...@dnsbelgium.be>>, IESG <i...@ietf.org<mailto:i...@ietf.org>>, "regext@ietf.org<mailto:regext@ietf.org>" <regext@ietf.org<mailto:regext@ietf.org>>, "draft-ietf-regext-...@ietf.org<mailto:draft-ietf-regext-...@ietf.org>" <draft-ietf-regext-...@ietf.org<mailto: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<mailto:alias-boun...@ietf.org>> Resent-To: <zhoulin...@cnnic.cn<mailto:zhoulin...@cnnic.cn>>, <ietf...@gmail.com<mailto:ietf...@gmail.com>>, <zhouguiq...@cnnic.cn<mailto:zhouguiq...@cnnic.cn>>, <ya...@cnnic.cn<mailto:ya...@cnnic.cn>>, James Gould <jgo...@verisign.com<mailto: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<mailto: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<mailto: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
