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

"Linlin Zhou" <zhoulinlin@cnnic.cn> Wed, 31 October 2018 03:36 UTC

Return-Path: <zhoulinlin@cnnic.cn>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41597127332; Tue, 30 Oct 2018 20:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo-afQTiXv_t; Tue, 30 Oct 2018 20:36:50 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id BCF53124C04; Tue, 30 Oct 2018 20:36:47 -0700 (PDT)
Received: from zll (unknown [218.241.111.73]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BJUPxFI9lby3AFAA--.4727S2; Wed, 31 Oct 2018 11:36:37 +0800 (CST)
Date: Wed, 31 Oct 2018 11:37:51 +0800
From: Linlin Zhou <zhoulinlin@cnnic.cn>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Eric Rescorla <ekr@rtfm.com>, regext-chairs <regext-chairs@ietf.org>, Pieter Vandepitte <pieter.vandepitte@dnsbelgium.be>, iesg <iesg@ietf.org>, regext <regext@ietf.org>, draft-ietf-regext-org <draft-ietf-regext-org@ietf.org>
References: <154040431305.6967.8110836894354286749.idtracker@ietfa.amsl.com>, <20181025174522837431196@cnnic.cn>, <CABcZeBMtZXNJR5oAsb8Do995herP010tShq46N_6JZaZxHtp8A@mail.gmail.com>, <20181029161835451937137@cnnic.cn>, <CABcZeBO5n1WXmaQAkOYBkhtOi6BJXzdnBWxxyskauHjX1myiug@mail.gmail.com>, <2018103110254261670452@cnnic.cn>, <20181031032312.GF45914@kduck.kaduk.org>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <2018103111375023030480@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart502253455812_=----"
X-CM-TRANSID: AQAAf0BJUPxFI9lby3AFAA--.4727S2
X-Coremail-Antispam: 1UD129KBjvJXoWxXw43GFW5tw1Dtr4kuF1ftFb_yoW5Ar4Upa y3Gr47tw4DJF47A39rKa4UGF18Jrn3ZryUJrn8Xr1xJFs8Ar1jvF4Yyry8Xa47GFyFq3W5 JrWjv34Yka1UAFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPKb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVCF0I0E 4I0vr24l5I8CrVC2j2CEjI02ccxYII8I67AEr4CY67k08wAv7VC0I7IYx2IY67AKxVWUJV WUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAK I48JM4xvF2IEb7IF0Fy264kE64k0F24lFcxC0VAYjxAxZF0Ex2IqxwCY02Avz4vE14v_Gr 4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWU GVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7V AKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j 6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJVW8Jw CI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU 0xZFpf9x07jOjjgUUUUU=
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Ak6Wi5BHZKcYXOf93oNgPZjnf14>
Subject: Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Oct 2018 03:36:54 -0000

Dear Benjamin,
"A client MUST NOT alter status values set by the server." The client can set "clientLinkProhibited" but can not alter "ok". "ok" and "clientLinkProhibited" can coexist.

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 
> 
>  
> 
>