Return-Path: 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 ; 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 ; 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 ; 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 To: "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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2020 09:30:14 -0000 This is a multi part MIME message. --_NextPart_1_5eoor9vhyHVnYgbRaPoqIDIfflA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 dr= aft 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) in= terfaces to administrate registrylock? I know that - as always - it's a chicken and egg problem, but I'd like to ge= t 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 dr= aft, if registries and registrars believe the document is useful! Feedback appreciated. Best, Alex --_NextPart_1_5eoor9vhyHVnYgbRaPoqIDIfflA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello everyone,

 

Ulrich has published a new revis= ion of his registry lock draft (draft-wisser-registrylock). We’re curr= ently in the process of evaluating whether that draft would fit into a) our = processes and b) the need of our registrars. =20We do – of course – want to avoid introducing any “weir= d local special procedures”, and therefore I’d appreciate feedba= ck on

 

-  &n= bsp;       Any registry (besides .s= e) implementing the respective extension (in its current draft form, obvious= ly)

-  &n= bsp;       What are registrars plan= ning with regards to that (or similar) interfaces to administrate registrylo= ck?

 

I know that – as always &#= 8211; it’s a chicken and egg problem, but I’d like to get a temp= erature of the room. And I know the document is an individual draft, but I s= uppose this working group is the most appropriate place to =20pose that question. I’m also more than happy to help in further dev= elopment of the draft, if registries and registrars believe the document is = useful!

 

Feedback appreciated.=

 

Best,

Alex

 

--_NextPart_1_5eoor9vhyHVnYgbRaPoqIDIfflA--