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

Benjamin Kaduk <kaduk@mit.edu> Wed, 31 October 2018 03:23 UTC

Return-Path: <kaduk@mit.edu>
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 534F8124C04; Tue, 30 Oct 2018 20:23:26 -0700 (PDT)
X-Quarantine-ID: <UScYxqFFbLgk>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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 UScYxqFFbLgk; Tue, 30 Oct 2018 20:23:24 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BD8127332; Tue, 30 Oct 2018 20:23:23 -0700 (PDT)
X-AuditID: 12074423-c65ff7000000589a-19-5bd92028a434
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 74.77.22682.92029DB5; Tue, 30 Oct 2018 23:23:21 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id w9V3NI5c016482; Tue, 30 Oct 2018 23:23:19 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id w9V3NCCw019396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Oct 2018 23:23:15 -0400
Date: Tue, 30 Oct 2018 22:23:12 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Linlin Zhou <zhoulinlin@cnnic.cn>
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>
Message-ID: <20181031032312.GF45914@kduck.kaduk.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2018103110254261670452@cnnic.cn>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hRV1tVUuBlt8KJH0+LCpU4mixWvz7Fb zPgzkdni795ZzBYvu54yW1ydcITR4tfHl4wO7B6brkl6fJ90nt1jyZKfTB6TH7cxB7BEcdmk pOZklqUW6dslcGVs+XKDsWCbcMWB51tYGxiv8ncxcnJICJhINPz4zAZiCwmsYZKYtt+si5EL yN7IKHHjz2RWCOcuk8TPyZdYQKpYBFQl1h85zQxiswmoSDR0XwazRYDi30/NZwRpYBZoYJLo e/SaCSQhLJAtcWDpGrAVvEDrFp74wQwx9QSTxP8fv5khEoISJ2c+AdvALKAlcePfS6BmDiBb WmL5Pw4Qk1NAT2LfYyGQClEBZYm9fYfYJzAKzELSPAtJ8yyE5gWMzKsYZVNyq3RzEzNzilOT dYuTE/PyUot0zfRyM0v0UlNKNzGCQp3dRXkH48s+70OMAhyMSjy8D5JvRAuxJpYVV+YeYpTk YFIS5c3muRktxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3agVQOW9KYmVValE+TEqag0VJnHdi y+JoIYH0xJLU7NTUgtQimKwMB4eSBC+PPNBQwaLU9NSKtMycEoQ0EwcnyHAeoOG/5IBqeIsL EnOLM9Mh8qcYFaXEeUVAmgVAEhmleXC9oFQkkb2/5hWjONArwry8IFU8wDQG1/0KaDAT0GAu dpCri0sSEVJSDYz8hXtuS7I2WYhVnlO8Oy1AIj9o6eydZXPjvlz0+rlhw65DVf/4TV6KmSyP 9nH5d1RIKf+GkYoxT+lh07PvP8tMu3usftbB8sO/O1VuJy2IaRNyX5/uGlXwsN9yiXDojSne qZ8eMn8/8+rolaY23sOCGfvYszyzzI9WfBOY+cipzf5DPd/dY5FKLMUZiYZazEXFiQDvo4nM IAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/P1YzK6rjOZlTvzpl2S_E47JCKJU>
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:23:26 -0000

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