Re: [regext] Implementations of draft-wisser-registrylock?

Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> Fri, 27 March 2020 08:44 UTC

Return-Path: <rep.dot.nop@gmail.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 D28743A0793 for <regext@ietfa.amsl.com>; Fri, 27 Mar 2020 01:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5ipAUWnN9jTz for <regext@ietfa.amsl.com>; Fri, 27 Mar 2020 01:44:24 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 75C683A052C for <regext@ietf.org>; Fri, 27 Mar 2020 01:44:24 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id w25so6747513wmi.0 for <regext@ietf.org>; Fri, 27 Mar 2020 01:44:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Vxl+wZH+6D3BYVzRq80TB/bk5tsyA3Utvkn+Blta/0c=; b=FMU4dBvxV4w7ksgSD9fG57hr+5w+9XHzDAPPGCP4j3e+jtcId+cQbUTEhntk0q0ErB 1WpNmyFL7JjJV5whgmY+6sVJ4XrfhNJDui7qxgI6BjO4g6yP7OkBEW+KsM3HUfDKw+Em OMRKTedW/bLgdrZCbvpQDwsNJHJhjq3GzgCtUAFbZVwGf9Tm6nU7f8E/oz1J9GWba6Lv OION8QTwekZ5ai4OkHJoBiMz4PC5bnnI8GYpYT8Q8lCzYHYVreDqGArnScTsQA03YY2y YZFuFxdtXex7EjiGTtUniucUqpF5nj4r3+QHDWf5k0PdAeCdHSBgvKYKi0cds6QtFQ3J LGkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Vxl+wZH+6D3BYVzRq80TB/bk5tsyA3Utvkn+Blta/0c=; b=mSJJUPUDVTXkTRNQTFhxW1mkPbdy5iorAZo8XSuCRRDt3nhUQdhoYJJK5oe5mN9VGN qPfpwYGTESwLpD4Hzklf2xnWmoCSdsTmKcvnyDHje9fQErDOqjY/LH4WN/F8vQTvtpZN lX4gs0fjcymMuyljv+aefO4MUc7uo2LrMWLVEHhsfZmcL+BSiW1p6TaDJG4JtvKRgZvH RMBHWBTAMRm4IFHyfWiFoRKK9eOR8xyQpAcZ+oYLcx8CHm9xUCrdidzTXQ542pRQqh+o bNaIqs8l48kToh0n28T+zxcJ7JFbacXeXxOTC4phNooZx09hpfkogE93LbxuBJxrA6XM FyWg==
X-Gm-Message-State: ANhLgQ3xdOpo3p/hJ2FQ8NtVYJ8z4LhhxmMh7m1MhvVaBd10qUgpBYel 9V+60o/Md9dUnp1fbIovz9ZIEN2R
X-Google-Smtp-Source: ADFU+vsok0BLZob16JFIvioo2HUzmUbLjtiw5vMPNw2MX8GhExATNKv+m2i9q/eTWxomZ4M6w1OCWQ==
X-Received: by 2002:a05:600c:2dd7:: with SMTP id e23mr4093967wmh.159.1585298662858; Fri, 27 Mar 2020 01:44:22 -0700 (PDT)
Received: from nbbrfq.loc (217-149-168-187.nat.highway.telekom.at. [217.149.168.187]) by smtp.gmail.com with ESMTPSA id q17sm7629073wrp.11.2020.03.27.01.44.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Mar 2020 01:44:22 -0700 (PDT)
Date: Fri, 27 Mar 2020 09:44:13 +0100
From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
To: Ulrich Wisser <ulrich@wisser.se>
Cc: Alexander Mayrhofer <alexander.mayrhofer@nic.at>, "regext@ietf.org" <regext@ietf.org>, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Message-ID: <20200327094413.73386d66@nbbrfq.loc>
In-Reply-To: <19F54F2956911544A32543B8A9BDE075B24192F8@NICS-EXCH2.sbg.nic.at>
References: <19F54F2956911544A32543B8A9BDE075B24192F8@NICS-EXCH2.sbg.nic.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/WC-Pk7mBvtsLmOt96X0feuEz9M8>
Subject: Re: [regext] Implementations of draft-wisser-registrylock?
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: Fri, 27 Mar 2020 08:44:26 -0000

On Wed, 25 Mar 2020 10:29:52 +0100
Alexander Mayrhofer <alexander.mayrhofer@nic.at> wrote:

> Hello everyone,
> 
> Ulrich has published a new revision of his registry lock draft (draft-wisser-registrylock). We're currently in the

In 4.2.5.  EPP <update> Command
s/SEVER_UPDATE_PROHIBITED/serverUpdateProhibited/

> I know that - as always - it's a chicken and egg problem, but I'd like to get a temperature of the room. And I know the document is an individual draft, but I suppose this working group is the most appropriate place to pose that question. I'm also more than happy to help in further development of the draft, if registries and registrars believe the document is useful!
> 
> Feedback appreciated.

The unlockUntil element was the missing bit.

In 2.3.  Command Execution Restrictions
There is
---8<---
OPEN QUESTION: If a domain is under registry lock, can a subordinate
   host be updated?
---8<---
That's a policy decision which might be further complicated by hostObj
versus hostAttr. I would leave this as implementation defined.


4.1.2.  EPP <info> Command
---8<---
      An OPTIONAL <unlockedUntil> element if the object currently can be
      changed by the sponsoring client.  The field indicates the time
      stamp when further changes will be impossible.
---8<---
I'd clarify that as s/when/after which/ as in "the time stamp after
which further changes".

4.2.1.  EPP <create> Command
s/inteded/intended/g

This allows for an initial domain:create with the lock unlockUntil set
which is maybe useful for some. I hope registrars will get the data
correct in the create frame right from the start but wouldn't reject
seeing unlockUntil here. Can be handled by generic code and does no
harm.

4.2.5.  EPP <update> Command
s/unock/unlock/

AFAICS this allows for the case of an existing normal domain being
updated to add a registry lock where the lock is optionally unlockUntil
which is handy.

Just skimming over the -1 diff, did not read it thoroughly.

Thanks for the update, Ulrich!
cheers,
Bernhard