[regext] Implementations of draft-wisser-registrylock?

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Wed, 25 March 2020 09:30 UTC

Return-Path: <alexander.mayrhofer@nic.at>
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 4E2393A0C47 for <regext@ietfa.amsl.com>; Wed, 25 Mar 2020 02:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=nic.at
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 SXnQ7LV_Vxuc for <regext@ietfa.amsl.com>; Wed, 25 Mar 2020 02:30:01 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 BF66B3A08B1 for <regext@ietf.org>; Wed, 25 Mar 2020 02:30:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nic.at; s=it2019; h=From:From:To:CC:Subject:Date:Message-Id:Content-Type:Received:Received; bh=iLQ0doaRlwdPF5y4rnaO3x8lotoguztG3GfS9B6P2/A=; b=NvNTdboXHzcGce4gAUy0QUrdCToky7GDCpYwudbxECBngfnAkksiNnrc3V8ua8Ao8N+1J24cGRi/EEJr7Yr0uUUK50u+D4qJ87sbCVqOxZ1kLUgs1n63dpXXpRO8ITJ48AeBJ5LXJkxOB9nMYfR6kqF41hfKu4uo/Y0Jz9YLWy1zDyJZEZfHE//e+MGTVCG6TIrae1GR95MOTSWxL71YVJx7KbEFUysbog3DPhxqzxkTbexIXK6dZPww83jjba0h7ULOVWMPSo/LaitmzJckss+NR/yNufU5OdSdqJdCIWz3gLE796F51qzm1MZmi6f5TgJjbCxBoGcl+YNHbpASqg==;
Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) with XWall v3.53 ; Wed, 25 Mar 2020 10:29:58 +0100
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0487.000; Wed, 25 Mar 2020 10:29:53 +0100
Thread-Topic: Implementations of draft-wisser-registrylock?
Thread-Index: AdYChy0ynPHqmjpGSXmN0Sz7uN9i4g==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.3.32]
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: "regext@ietf.org" <regext@ietf.org>
Date: Wed, 25 Mar 2020 10:29:52 +0100
X-Assembled-By: XWall v3.53
Message-ID: <19F54F2956911544A32543B8A9BDE075B24192F8@NICS-EXCH2.sbg.nic.at>
X-XWALL-BCKS: auto
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="_NextPart_1_5eoor9vhyHVnYgbRaPoqIDIfflA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/5bQNdNguBvyQfA8PCc0INjlPzs4>
Subject: [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 09:30:14 -0000

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