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

[Ulrich Wisser <[e-mail]>]

Hi,

I have made significant changes to the draft.
Many thanks to contributions by Michael Bauland and Bernhard
Reutner-Fischer.

Please find the draft at
https://datatracker.ietf.org/doc/draft-wisser-registrylock/

And please give it a review.

If your registry currently offers or will offer registry lock in the future
I would be interested to hear how this draft fits or doesn't fit your
business model.

Kind regards from Stockholm

/Ulrich





Am Fr., 27. März 2020 um 09:44 Uhr schrieb 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
>