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

From: Ulrich Wisser <[email-masked]>
Date: Tue, 7 Apr 2020 17:27:40 +0200

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 <
[email-masked]>:

> 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 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
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 7 Apr 2020 16:57:31 +0000

From: regext <[email-masked]> On Behalf Of Ulrich Wisser
Sent: Tuesday, April 7, 2020 11:28 AM
To: [email-masked]
Cc: Alexander Mayrhofer <[email-masked]>; Bernhard Reutner-Fischer <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [regext] Implementations of draft-wisser-registrylock?

Hi,

Many thanks to contributions by Michael Bauland and Bernhard Reutner-Fischer.

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

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.

I hope you’re doing well, Ulrich! The mechanism described in the draft isn’t one that Verisign plans to implement. We do offer a registry lock service, but it doesn’t use EPP to avoid situations in which a compromised registrar/sponsoring client could unlock a domain and make unauthorized changes. We support registrar-initiated management of the client* status values for registrar locking.

Scott

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 7 Apr 2020 13:06:06 -0400

As an end-user i've always liked the out-of-band registrar-initiated
management of the client status.

I can see a registrar offering both in-band and out-of-band to their
clients.

Also, there appear to be some dangling sentences in section 2.

tim

On Tue, Apr 7, 2020 at 12:57 PM Hollenbeck, Scott <shollenbeck=
[email-masked]> wrote:

> *From:* regext <[email-masked]> *On Behalf Of *Ulrich Wisser
> *Sent:* Tuesday, April 7, 2020 11:28 AM
> *To:* [email-masked]
> *Cc:* Alexander Mayrhofer <[email-masked]>; Bernhard
> Reutner-Fischer <[email-masked]>; [email-masked]
> *Subject:* [EXTERNAL] Re: [regext] Implementations of
> draft-wisser-registrylock?
>
>
>
> Hi,
>
>
>
> 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.
>
>
>
> I hope you’re doing well, Ulrich! The mechanism described in the draft
> isn’t one that Verisign plans to implement. We do offer a registry lock
> service, but it doesn’t use EPP to avoid situations in which a compromised
> registrar/sponsoring client could unlock a domain and make unauthorized
> changes. We support registrar-initiated management of the client* status
> values for registrar locking.
>
>
>
> Scott
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

---

From: Ulrich Wisser <[email-masked]>
Date: Mon, 20 Apr 2020 15:02:34 +0200

Hi Scott,

thank you, by now you have probably heard about Swedens unusual way to
handle the virus.
Just in case, here is a short reminder:
https://www.tiktok.com/@armandfuego/video/6817369611206479110

We actually do handle registry lock quite similar. We allow enabling it
through the extension, but we support only "outofband".
Our registrars have to login to our registrar portal to temporarily unlock
the domain or to remove registry lock all together.

For the in-band part of the extension to be used safely, we would first
need to come up with an OTP scheme for EPP.
Maybe that is something to work on for the future?

/Ulrich

---

From: Ulrich Wisser <[email-masked]>
Date: Mon, 20 Apr 2020 15:06:41 +0200

Hi Tim,

thanks for reading the document. I believe the dangling sentence is an
artifact of malformatting.
It tries actually to explain the out-of-band mechanics in more detail. Next
version will fix at
least the formatting.

As I already wrote in my reply to Scott, for the in-band to be used safely
we would need to
introduce an OTP scheme to EPP.

/Ulrich

Am Di., 7. Apr. 2020 um 19:07 Uhr schrieb Tim Wicinski <[email-masked]>:

>> *To:* regext@ietf..org <[email-masked]>