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

Ulrich Wisser <ulrich@wisser.se> Tue, 07 April 2020 15:27 UTC

Return-Path: <ulrich@wisser.se>
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 5A9383A0C5D for <regext@ietfa.amsl.com>; Tue, 7 Apr 2020 08:27:56 -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, HTML_MESSAGE=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=wisser.se
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 MN1--SlfkWwd for <regext@ietfa.amsl.com>; Tue, 7 Apr 2020 08:27:53 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 8F80E3A0C58 for <regext@ietf.org>; Tue, 7 Apr 2020 08:27:53 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id n20so3788972ioa.4 for <regext@ietf.org>; Tue, 07 Apr 2020 08:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wisser.se; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SmvpHxT5+lA7Ru2t8nL8bsS5uI56AYlsXm3b7elVusU=; b=JpjRAZxx8YzTfewen0n40Sj1p67Hv17C1Q6M51iO+KQ9NQXnniG5T2cOteMzIn7vMU Tvqzgqbyt6pc+w6k7QYytTML7Wt0RfGcfRaudgQvHackr98sQwwUTP+afAm6CvDH8AGO TGfOHsATE+z8Cbc17F9iCs6g/MJbx7S6lYhOVbh+oyWZmazXOGM+aoJ3Q3ZtpsvZkk6w 3wlK8+6ofN1Fc9m8vh1FN7WEL5Q0j6rFyTLNtS+3q0hBln4B5f1TF/P3HjmuIBB+KfIl /CrJljexvZq3wn64ueLvzPmzdGc4eDXFyERmfoUNBxgwVtB0Z4UElbyhYNb45ZLZrwXD YJJw==
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=SmvpHxT5+lA7Ru2t8nL8bsS5uI56AYlsXm3b7elVusU=; b=ejlFLosJ6dTxwC/UUTk/3DGGb0e0PwYFZVaBBZUfxSr7KxogTylH1WHag3I0I8ghW1 NJneD4HQTwnDZHTumVPLNqPptebjkEzp3Y2854TZjDEWAotSlYP3giNuKOAnXFxjS2nb H/LzGIQo8ZOTKRFKW4rwbIDO7JRCe/2CaO1sMofPGURqlz3ugfFLO/7rpbe4gx9kr6Iw eQMUpVQ0iWdA7q2lU3/Ep5v5jOqrONNEObG5P8xZkk7PELYESlxoThjVCCtSlluDI9T9 zjWfQo1Mn0lGOfL1soIznF6cf/ksYA2ufgf6mv0zC+2irGwX1JcdmpCtQwTGVl9KXiq0 ffUQ==
X-Gm-Message-State: AGi0PubGy1a+lP1D9rmNbKGbq3myjw6M8aJgV6GN3L+26A6CONqLHbdu d7z1eE+wJcR29Hje3M5SLp0xcoDscWYJth4Nv8MMRmuO8cc=
X-Google-Smtp-Source: APiQypKD/zcxUMySZhCNCIuhLXSDLXsUUyZEh6o5jNH9FkrR8wbzN7tU0iVFBS+55FpQd5LVTMZINnEWj8MwR69fHlk=
X-Received: by 2002:a6b:ce02:: with SMTP id p2mr2617169iob.103.1586273272025; Tue, 07 Apr 2020 08:27:52 -0700 (PDT)
MIME-Version: 1.0
References: <19F54F2956911544A32543B8A9BDE075B24192F8@NICS-EXCH2.sbg.nic.at> <20200327094413.73386d66@nbbrfq.loc>
In-Reply-To: <20200327094413.73386d66@nbbrfq.loc>
From: Ulrich Wisser <ulrich@wisser.se>
Date: Tue, 7 Apr 2020 17:27:40 +0200
Message-ID: <CAJ9-zoWU3JMdvGMRKzOy4HWnZ0wDqO-Z83sNm2qADPNKiX0pBg@mail.gmail.com>
To: "regext@ietf.org" <regext@ietf.org>
Cc: Alexander Mayrhofer <alexander.mayrhofer@nic.at>, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>, Michael.Bauland@knipp.de
Content-Type: multipart/alternative; boundary="000000000000e6021805a2b5061a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/rtVp8r1IWZbDLdpwRjREWIIwXhs>
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: Tue, 07 Apr 2020 15:27:56 -0000

Hi,

I have made significant changes to the draft.
Many thanks to contributions by Michael Bauland and Bernhard
Reutner-Fischer.

Please find the draft at
https://datatracker.ietf.org/doc/draft-wisser-registrylock/

And please give it a review.

If your registry currently offers or will offer registry lock in the future
I would be interested to hear how this draft fits or doesn't fit your
business model.

Kind regards from Stockholm

/Ulrich





Am Fr., 27. März 2020 um 09:44 Uhr schrieb Bernhard Reutner-Fischer <
rep.dot.nop@gmail.com>gt;:

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