Re: [regext] Eric Rescorla's Discuss on draft-ietf-regext-org-11: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Thu, 08 November 2018 07:40 UTC
Return-Path: <ekr@rtfm.com>
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 8DCAC130E1A for <regext@ietfa.amsl.com>; Wed, 7 Nov 2018 23:40:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 kSm3McvbcoSc for <regext@ietfa.amsl.com>; Wed, 7 Nov 2018 23:40:51 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953C51294D0 for <regext@ietf.org>; Wed, 7 Nov 2018 23:40:46 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id u18so13417897lff.10 for <regext@ietf.org>; Wed, 07 Nov 2018 23:40:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hCZWwGvJu9S30Ru5j9Ma+QjM1aH0ltiKYmpJfAwJbOo=; b=c9Yh49osv4q5Mufcc9YMyZQfCKCKWyUeJHL7qNTAXvN0z0U8Zz3ccHyl0GP3/IrNOT 4QsE9uKKXvOqtAZUJfH6Fn9ijNoB2+LJRxhN6TrM2x8pPfSx5ZOTKNxR6ygrn68146NH Rri8Tqs3nJgpMMBrXGmA0WUxG62IXJ5DgfHszb/+WgHAkDv3ZQF+I26LOUtrKM9q6ecK YjiQkobg9RKC8JhAiCtWTDLknfNMv3N9yFBiwBmvYHC6n25YKdj+ip+o68CnNyfuV8fc YxFmdq81OM9V86EzlQbkacKBOXsZ58Eh1x19ZhfgYu1KIt5GDLW9Ukcv2tfXZEwyztuR zmUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hCZWwGvJu9S30Ru5j9Ma+QjM1aH0ltiKYmpJfAwJbOo=; b=aoLsC840kRhLD8NV4jFfIl1XiaZ37D9USrJVLYwfr7G/dhYsmlAOmT0NhoTLxjjgKt 4mnuYMDyT2jch63TqS+NVQl20LQePszucZ/GsPj0Vfuiw33ELDwIYPvgBF/KR8S3RCOV 3wPwVRbz9YdGIE/DxIAc3x5MehESHjjmSALHD/36cylCrz5EdJR5z1ax0i8VY1LAQ3e5 vwuRvP/gkm5uHiZHkv2rdInj4ZlWuYRuZXInmQiX3eS8z/pMl9/skc686Pwvu8ijmskT tnRefwsVWYvnC66Kx/K5gT0mUnXkxzWOOgZFpI8spZ4b5pRBBRU/meHIvGCKzuQq1jF3 qFEA==
X-Gm-Message-State: AGRZ1gJIUf3Mhg9wjK6krOZpUxrYnZMfN7jB5dAENf24ZN4hI98pFhol QC0TQsTvr9l4OplNq6aReSS3F/0+rgnqUwyqIT53VQ==
X-Google-Smtp-Source: AJdET5fcK1DUHevkMcXDTLBnkEbZ5ZvXw+ZAGt+ME+Eah7XnEGcrys6v1yGcoYPQyEvr7KVZKccpnUHoDyKIVGVh3/A=
X-Received: by 2002:a19:54d7:: with SMTP id b84mr1872225lfl.131.1541662844621; Wed, 07 Nov 2018 23:40:44 -0800 (PST)
MIME-Version: 1.0
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> <36DF20D1-5898-4403-9EC2-CAFEE8E38277@verisign.com> <CABcZeBPER9Nn_i-rCWBbgf37TXV11ZcBM37Nrb52toNhg3Se-w@mail.gmail.com> <173650BC-038F-4B37-ABE9-D1EFC13B0C85@verisign.com> <CABcZeBN20hJON2GTTMEuiX91WsGXAgXYEzONA92UDDt3jsm2bA@mail.gmail.com> <E9FBAD82-EE40-4717-9F3A-12F66CE90929@verisign.com>
In-Reply-To: <E9FBAD82-EE40-4717-9F3A-12F66CE90929@verisign.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 07 Nov 2018 23:40:06 -0800
Message-ID: <CABcZeBNkH=r8c42jH=Mix-3eT9B3NvnoYUML2gN-pLPvSXLXwQ@mail.gmail.com>
To: "Gould, James" <jgould@verisign.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, zhoulinlin@cnnic.cn, regext-chairs@ietf.org, pieter.vandepitte@dnsbelgium.be, IESG <iesg@ietf.org>, regext@ietf.org, draft-ietf-regext-org@ietf.org
Content-Type: multipart/related; boundary="00000000000037fb5a057a225a71"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/jdUZPWLhUqCsihm48Cw-QWc2jvI>
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: Thu, 08 Nov 2018 07:40:55 -0000
LGTM. I have already cleared my DISCUSS -Ekr On Wed, Nov 7, 2018 at 11:36 PM Gould, James <jgould@verisign.com> wrote: > 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 > > > [image: cid:image001.png@01D255E2.EB933A30] > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *Eric Rescorla <ekr@rtfm.com> > *Date: *Thursday, November 8, 2018 at 2:30 PM > *To: *James Gould <jgould@verisign.com> > *Cc: *Benjamin Kaduk <kaduk@mit.edu>, "zhoulinlin@cnnic.cn" < > zhoulinlin@cnnic.cn>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, " > pieter.vandepitte@dnsbelgium.be" <pieter.vandepitte@dnsbelgium.be>, IESG < > iesg@ietf.org>, "regext@ietf.org" <regext@ietf.org>, " > draft-ietf-regext-org@ietf.org" <draft-ietf-regext-org@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 <jgould@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 > > > [image: cid:image001.png@01D255E2.EB933A30] > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *Eric Rescorla <ekr@rtfm.com> > *Date: *Thursday, November 8, 2018 at 10:48 AM > *To: *James Gould <jgould@verisign.com> > *Cc: *Benjamin Kaduk <kaduk@mit.edu>, "zhoulinlin@cnnic.cn" < > zhoulinlin@cnnic.cn>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, " > pieter.vandepitte@dnsbelgium.be" <pieter.vandepitte@dnsbelgium.be>, IESG < > iesg@ietf.org>, "regext@ietf.org" <regext@ietf.org>, " > draft-ietf-regext-org@ietf.org" <draft-ietf-regext-org@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-bounces@ietf.org> > *Resent-To: *<zhoulinlin@cnnic.cn>, <ietfing@gmail.com>, < > zhouguiqing@cnnic.cn>, <yaojk@cnnic.cn>, James Gould <jgould@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 <jgould@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 > > jgould@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" <kaduk@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] Eric Rescorla's Discuss on draft-ietf-re… Eric Rescorla
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Linlin Zhou
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Linlin Zhou
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Linlin Zhou
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Benjamin Kaduk
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Linlin Zhou
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Linlin Zhou
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Linlin Zhou
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Gould, James
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Gould, James
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Benjamin Kaduk
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Gould, James
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Gould, James
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Gould, James
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [regext] Eric Rescorla's Discuss on draft-iet… Benjamin Kaduk