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 protected]>: > On Wed, 25 Mar 2020 10:29:52 +0100 > Alexander Mayrhofer <[email protected]> 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 >
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
