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

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 25 Mar 2020 10:29:52 +0100

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

---

From: Michael Bauland <[email-masked]>
Date: Wed, 25 Mar 2020 11:18:40 +0100

Hi Alex,

we (TANGO Registry Services) are currently also looking into
implementing a registry lock service. So far, we haven't decided any
specifics yet, but draft-wisser-registrylock is definitely one of the
options.

Talking from the point of view of a company providing software for
registrars, it's certainly a good idea to have some standard for the
handling of registry lock features across the registries. We just want
to avoid a situation as with the Fee Extension where there are currently
about ten different versions used by different registries, which is a
nightmare for registrars to implement and support.

Best regards,

Michael

-- 
____________________________________________________________________
     |       |
     | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                 Martin-Schmeisser-Weg 9
                                 44227 Dortmund
                                 Germany

     Dipl.-Informatiker          Fon:    +49 231 9703-0
                                 Fax:    +49 231 9703-200
     Dr. Michael Bauland         SIP:    [email-masked]
     Software Development        E-mail: [email-masked]

                                 Register Court:
                                 Amtsgericht Dortmund, HRB 13728

                                 Chief Executive Officers:
                                 Dietmar Knipp, Elmar Knipp

---

From: Erwin Lansing <[email-masked]>
Date: Wed, 25 Mar 2020 11:39:16 +0100

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 <[email-masked]> 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
>  
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>,

---

From: Bernhard Reutner-Fischer <[email-masked]>
Date: Fri, 27 Mar 2020 09:44:13 +0100

On Wed, 25 Mar 2020 10:29:52 +0100
Alexander Mayrhofer <[email-masked]> 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…

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