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

[Erwin Lansing <[e-mail]>]

Hi Ulrich,

Thanks for creating this draft.

My impression from reviewing the different registry business models is, that most differences are related to sales channel and out-of-band unlocking methods. As long as locking trough create and update is optional for the server implementation, and since the draft is staying well away from prescribing out-of-band methods, I think it is flexible enough to cover most, if not all, different business models.

Admittedly, I’m not an EPP implementer, and may not be the intended audience, but I had a hard time putting two and two together for some of the features. There are a lot of nuances, that could be brought more clear forward to explain their intention and what they mean to achieve. Two examples that could be highlighted more:
- Front and center: renew - always allowed, transfer and delete - always refused, update - depends on lock status.
- unlockUntil - can only be used at the same time as the initial lock of the domain to delay when the lock becomes active (at least, that’s what I read).

WRT to your question on subordinate hosts, in .dk we agree that they are owned by the domain owner and follow the same procedures as the domain itself.

Finally some nits, I think the last sentence in 2.2 belongs in 2.1, and some typos attached.

Best,
Erwin


> On 7 Apr 2020, at 17.27, Ulrich Wisser <ulrich=[e-mail]> wrote:
> 
> 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/ <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
>