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 07:08 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 9CAC61286E7; Wed, 31 Oct 2018 00:08:45 -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 cPdwWv0HINUK; Wed, 31 Oct 2018 00:08:43 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2941277BB; Wed, 31 Oct 2018 00:08:39 -0700 (PDT)
Received: from zll (unknown [218.241.111.73]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BJUPzuVNlb0ncFAA--.4773S2; Wed, 31 Oct 2018 15:08:30 +0800 (CST)
Date: Wed, 31 Oct 2018 15:09:45 +0800
From: Linlin Zhou <zhoulinlin@cnnic.cn>
To: zhoulinlin <zhoulinlin@cnnic.cn>, Benjamin Kaduk <kaduk@mit.edu>
Cc: Eric Rescorla <ekr@rtfm.com>, draft-ietf-regext-org <draft-ietf-regext-org@ietf.org>, regext-chairs <regext-chairs@ietf.org>, Pieter Vandepitte <pieter.vandepitte@dnsbelgium.be>, iesg <iesg@ietf.org>, regext <regext@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>, <2018103111375023030480@cnnic.cn>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <20181031150944697318136@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart004827780553_=----"
X-CM-TRANSID: AQAAf0BJUPzuVNlb0ncFAA--.4773S2
X-Coremail-Antispam: 1UD129KBjvJXoWxWry7Wry8KrW3Cr47try8Grg_yoW5ur1fpa y3Gw47Jw1DJF47A3srCFWUGF1Fqr1fZrWUJFn8Xrn7tFs8Ar1jqF4YyrykXa47GFyvqa15 JrWjv34Yka1UAaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmF14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j 6F4UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVW0oV Cq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E42I26xC2a48xMc02F40Ex7xS67I2 xxkvbII20VAFz48EcVAYj21lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r 1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0II8E6IAq YI8I648v4I1lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07MxkIecxEwV AFwVW8CwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E 14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GFylIx kGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAF wI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r 1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcSsGvfC2 KfnxnUUI43ZEXa7VUbE1v3UUUUU==
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/gGGtRg4eekUp78Bi28dPVDh-4sk>
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 07:08:46 -0000

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