Re: Registry lock - setting statuses on hosts
Stuart Olmstead-Wilcox <[email protected]> Thu, 10 Oct 2013 01:41:10 +0000
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
Jan, We are in agreement on both counts. > From my point of view the Server flags is never ever something that the registrar should be able to set over EPP. This (in my opinion) is something that > the registry only can set, and perhaps the registrar och registrant with some other, out of bound, method At least for our initial implementation we will not be allowing locking via epp. > But if we put that aside, i think one have to separate the domain lock from the host lock. Fundamentally agree. The only consideration here is ease of use for rant / rar if we cascade server statuses to all hosts assigned to a domain ... a "super" lock for lack of a better term. I'm concerned about rant's who think their domain is locked, but it is actually still potentially vulnerable because the host(s) are not locked. Stu -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jan Saell Sent: October-06-13 12:10 PM To: [email protected] Subject: Re: [provreg] Registry lock - setting statuses on hosts -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all. - From my point of view the Server flags is never ever something that the registrar should be able to set over EPP. This (in my opinion) is something that the registry only can set, and perhaps the registrar och registrant with some other, out of bound, method. But if we put that aside, i think one have to separate the domain lock from the host lock. Think of the possibility that you have one domain having hosts (name servers) from another domain. IN that case, you might want to lock the domain without host and also unlock a has separate to update it. This is my 5 cents. Mvh jan On 10/03/2013 05:13 PM, Stuart Olmstead-Wilcox wrote: > Hello, > > > > At CIRA we are working through our approach to Registry Lock and are > wondering what perspectives there are out there on the approach to > setting of server statuses on hosts – i.e. the locking of hosts. > > > > We are considering two main approaches: > > > > 1. From the setting of a “domain lock” (serverUpdate, > serverTransfer and serverDelete prohibited statuses set), > automatically cascade the related host statuses (serverUpdate and > serverDelete > prohibited) to all host entities assigned (nameservers) to the domain > in question. > > > > 2. Separate the locking of domains and hosts into disparate > transactions – i.e. one domain update transaction to set the domain > server statuses followed by subsequent host update transactions to set > server statuses on desired hosts. > > > > Our main considerations here are balancing ease of use from a > registrar’s perspective vs differing too far from a consistent > industry approach. > > > > All feedback would be appreciated. > > > > Thanks, > > Stu > > > > *Stu Olmstead-Wilcox, *Development Manager Canadian Internet > Registration Authority (CIRA) > Tel: (613) 237-5335 x265 | www.cira.ca |Twitter: @CIRASYSTEMS > <http://twitter.com/CIRANEWS> Trends, Commentary, Perspective. Stay > tuned to cirablog.ca <http://www.cirablog.ca/> > > > > > > _______________________________________________ > provreg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/provreg > - -- +------------------------------------------------------------------- ! Irial / YASK AB ! Att: Jan Saell ! Box 59, S-692 21 KUMLA, SWEDEN ! Tel: 019-58 25 15 Int +46-19 58 25 15 Fax +46-19 58 38 05 ! E-mail: [email protected] ! PGP Fingerprint: E957 23C8 9F51 0958 B9AD 7F18 404A 5DA1 F944 A08B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJRi10ACgkQQEpdoflEoIvL9gCeNAOCtTo7/Dgn1M/HRZk3U4UI ktUAn1KKcV7kV1Zvtir0yD9DdNmxjCWm =S7Ik -----END PGP SIGNATURE----- _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg