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

Erwin Lansing <erwin@lansing.dk> Wed, 25 March 2020 10:39 UTC

Return-Path: <erwin@lansing.dk>
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 4A8863A0C11 for <regext@ietfa.amsl.com>; Wed, 25 Mar 2020 03:39:59 -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=lansing.dk
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 OOEpbYdyxzGq for <regext@ietfa.amsl.com>; Wed, 25 Mar 2020 03:39:56 -0700 (PDT)
Received: from mail.droso.net (sloth.droso.dk [IPv6:2001:4b98:dc2:41:216:3eff:fe4d:cf5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8749E3A0CEA for <regext@ietf.org>; Wed, 25 Mar 2020 03:39:20 -0700 (PDT)
Received: from 2a02-0980-2510-ba00-a1f1-7c12-a056-e610.v6.fullrate.ninja (2a02-0980-2510-ba00-a1f1-7c12-a056-e610.v6.fullrate.ninja [IPv6:2a02:980:2510:ba00:a1f1:7c12:a056:e610]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.droso.net (Postfix) with ESMTPSA id 03ECD40220; Wed, 25 Mar 2020 10:39:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lansing.dk; s=lansing.dk-20160916; t=1585132758; bh=q2mhxy/4yAm/lP/nLw8Hfh0O5bwwT/iPlFYKwVUyU7M=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=lw+hGlhNPm1znSRVfzwhBppfwzp3DDw1X46JxrLYaVZvzPHusabKlrF8FWT0xlqsT BGw3an8/ASHrMQO/tq44+GsqvlUSJ+l6O8o3fXX+rnyh8kt9y7S56q7zoMv78XJKk6 LPOGFfrDd0pQABaPx1gWz9nrdxAtjZzu4xNVwKAeL6ZqG261JN3PTVF4/wwKGrSjWH oIiFq860rJ6BNXqVST5ET9Xg54tEWI9U18mht3n6DLkVAYOC6Y+BIP0OKTp5CbEC6A NDho63uspfWneRTkmnohb0Givg+NBQabUkyy5v8yAsHbmm3pYogmX697S9+Cu0G1ia K+bkuz0FpzWAA==
From: Erwin Lansing <erwin@lansing.dk>
Message-Id: <6FDD73C5-8A43-4DAA-973E-D2A43E5C0CAD@lansing.dk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_31F4340F-5AEF-4714-A2D7-6A4D4252CAF0"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 25 Mar 2020 11:39:16 +0100
In-Reply-To: <19F54F2956911544A32543B8A9BDE075B24192F8@NICS-EXCH2.sbg.nic.at>
Cc: "regext@ietf.org" <regext@ietf.org>
To: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
References: <19F54F2956911544A32543B8A9BDE075B24192F8@NICS-EXCH2.sbg.nic.at>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/VrvPobmCCBBYOi8QTVSztWoVSAM>
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: Wed, 25 Mar 2020 10:39:59 -0000

Hi Alex,

There are several business models for registry lock. One size doesn’t fit all, but rather than every registry reinventing the wheel, we are trying to boil those down to 2-4 basic models within CENTR. That work is first and foremost looking at the user experience, but should hopefully also lead to only a few standard implementations.

For .dk we do not want to offer the same product as .se. I haven’t read Ulrichs draft in detail, but I expect it not to fit our business model, although we (hopefully) can use parts of it. So rather than creating the Danish registry lock, we’re trying to come up with a more generic model, that can be reused by other registries. I hope we have something read to present in a few weeks.

Best,
Erwin



> On 25 Mar 2020, at 10.29, 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 process of evaluating whether that draft would fit into a) our processes and b) the need of our registrars. We do – of course – want to avoid introducing any “weird local special procedures”, and therefore I’d appreciate feedback on
>  
> -          Any registry (besides .se) implementing the respective extension (in its current draft form, obviously)
> -          What are registrars planning with regards to that (or similar) interfaces to administrate registrylock?
>  
> 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.
>  
> Best,
> Alex
>  
> _______________________________________________
> regext mailing list
> regext@ietf.org <mailto:regext@ietf.org>
> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>,