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

[Bernhard Reutner-Fischer <[e-mail]>]

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