Sorry for correction. The client can set "clientLinkProhibited" but can not 
alter "ok". "ok" should be removed by the server.



Linlin Zhou
 
From: Linlin Zhou
Date: 2018-10-31 11:37
To: Benjamin Kaduk
CC: Eric Rescorla; draft-ietf-regext-org; regext-chairs; Pieter Vandepitte; 
iesg; regext
Subject: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: 
(with DISCUSS and COMMENT)
Dear Benjamin,
"A client MUST NOT alter status values set by the server." The client can set 
"clientLinkProhibited" but can not alter "ok". 

Regards,
Linlin


Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-31 11:23
To: Linlin Zhou
CC: Eric Rescorla; regext-chairs; Pieter Vandepitte; iesg; regext; 
draft-ietf-regext-org
Subject: Re: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: 
(with DISCUSS and COMMENT)
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

Reply via email to