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 |
draft-wisser-registrylock-02.txt.diff
Description: Binary data
|
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext