Once upon a time, Perry E. Metzger <perry@piermont.com> said:

If people like Melbourne IT are going to claim they can't act on weekends, it might also be sensible not to allow transfers to be processed between Thursday and Sunday, though honestly I think if you are going to be a registrar, you are going to have to deal with problems over weekends.

We're a relatively small ISP compared to many on NANOG, but we have a 24x7 on-call system with an answering service. All domain registrars should be required to have 24x7 service. The GTLD (and other TLD) servers have a 2 day TTL on all records; if panix.com was fixed right now it would be Tuesday before everyone saw it. How hard would it be for Verisign (and other registries) to have the TTL "ramp up" after a change? In other words, when the NS records for domain.com get changed (but not after an initial registration), put them in the .com zone initially with a short TTL, maybe 6 hours, and then after 2 days move the TTL up to 12 hours, after another 2 days move it to 24 hours, and then after a week total move it to 2 days. How much more load would that really cause? Especially with the "streamlined" transfer procedure now in place, this would be a very good idea. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

Adrian Chadd wrote:

I agree they should have 24/7 support.

Just remember that, as an example, Melbourne IT has probably two orders of magnitude more clients than you. A 24x7 pager service would attract a /lot/ of "Emergencies" and as such they'd have to consider running at least a muppet level call service outside of hours to filter "emergency" requests away from the normal signup procedures and over to the People Who Really Fix Things.

I'm not saying MIT needs 24x7 support, I am saying they need on-call staff. One person might be enough; perhaps more than one may be needed. (A couple people called me on this point offlist and I felt the need to clarify my opinion.) I resell GoDaddy and they do have 24x7 customer support, but I don't think that's necessary to properly run a registrar. Just have X people available to deal with emergency situations. X will vary based on the size of the customer base. -- JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638) Steven J. Sobol, Geek In Charge / sjsobol@JustThe.net / PGP: 0xE3AE35ED "In case anyone was wondering, that big glowing globe above the Victor Valley is the sun." -Victorville _Daily Press_ on the unusually large amount of rain the Southland has gotten this winter (January 12th, 2005)

On Sun, 16 Jan 2005, Jim Shankland wrote:

Of course it's unreasonable to expect a registrar to have to put up with such a burden during off hours: God only knows what kind of silly calls would come in. "Emergencies" are best handled in a batch during the regular work week. For the stuff that really won't wait, you just put a lawyer on retainer, who can fax off a letter telling the complainant to sod off until Monday morning, or until the moon is in the seventh house and Jupiter aligns with Mars, whichever comes first.

I mean, if we can't be on the golf course by 3:00, what are we in this business for, anyway -- right?

The registrar DOES need to define "Emergency." "Emergency" does not mean "page on-call staffers because I forgot to renew my domain and it's fallen out of the roots, and Customer Service is closed Saturday." Such an event is defined as being "My Own Fault, Not Due to Catastrophic Conditions" and doesn't warrant bugging the person on-call. As long as the registrar defines what constitutes a page-able emergency, they should be ok. (Or is this overly simplistic?) -- JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638) Steven J. Sobol, Geek In Charge / sjsobol@JustThe.net / PGP: 0xE3AE35ED "In case anyone was wondering, that big glowing globe above the Victor Valley is the sun." -Victorville _Daily Press_ on the unusually large amount of rain the Southland has gotten this winter (January 12th, 2005)

Paul G wrote:

ime, the act of defining 'emergency' does not provoke compliance therewith.

Of course. It must be enforced. How, I'm not sure at this point (and not being an employee of a company acting as registrar or registry, I'm not sure I'd be able to offer any constructive suggestions as to how to enforce it). -- JustThe.net - Apple Valley, CA - http://JustThe.net/ - 888.480.4NET (4638) Steven J. Sobol, Geek In Charge / sjsobol@JustThe.net / PGP: 0xE3AE35ED "In case anyone was wondering, that big glowing globe above the Victor Valley is the sun." -Victorville _Daily Press_ on the unusually large amount of rain the Southland has gotten this winter (January 12th, 2005)

On Sun, 16 Jan 2005, Alexei Roudnev wrote:

...

If people like Melbourne IT are going to claim they can't act on weekends, it might also be sensible not to allow transfers to be processed between Thursday and Sunday, though honestly I think if you are going to be a registrar, you are going to have to deal with problems over weekends.

It is their dirty problem - if they can not act on weekend, they can not maintain a registry, that's all.

provided their contract requires some form of 24/7 support, and there is an SLA to manage that requirement. If there isn't then there is no need for 24/7 support (no contractual reason), it just becomes a business differentiator for clients when chosing registrar X or registrar Y (or so it seems to me)

On Mon, 17 Jan 2005 07:12:58 +0000 (GMT) "Christopher L. Morrow" <christopher.morrow@mci.com> wrote:

provided their contract requires some form of 24/7 support, and there is an SLA to manage that requirement. If there isn't then there is no need for 24/7 support (no contractual reason), it just becomes a business differentiator for clients when chosing registrar X or registrar Y

(or so it seems to me)

Then you miss the point that there was no contractual relationship between the real PANIX and MelbourneIT, yet in the first instance it was MelbourneIT that needed to respond so that an investigation into this unfortunate incident could be started. However excellent the SLA that a domain owner may have with their registrar, it is inevitably of no value when the central system is compromised (as appears on the surface to have been the case here). Your argument would have been completely sound if, in addition to whatever level of customer support they choose/contract to provide, there were an obligation for every accredited registrar to guarantee a response within a given timescale and on a 24/7 basis, to any emergency request received from any other accredited registrar. Indeed, such may already have been the case. Fire Drills have a habit of discovering shortcomings within well-planned emergency arrangements! -- Richard Cox

Bill,

The Registry is the party that must revert the data to the previous state. For the stability of the Internet, it must be done as quickly as possible before old correct caches time out. Therefore, that's where the penalties should apply.

Agree. This is a solution to the publication problem, and putting my hat <wicked_expired_{g,cc}tld_registry="on>, I can say that acting in lieu of a temporarily or permanently defunct registrar is normal, as is mark-up by hand of zonefiles, post-production but pre-publication. At <insert worthless {g,cc}tld operator here> I used to say all the time, "We are the registrar of last resort, when things go awry, we go acorn or asquash [1]."

(2) a 4 hour standard of promptness for all Registrars, starting from initial notice of any kind. That gives them enough time to:

Here's where it gets crappy. The gTLDs are in Reston, Reston, Toronto, Toronto and Reston, Reston and New York. The latter three have little or no facilities-based names, and are out of scope. The registrars are in more than 18 timezones, and may be fictional. In fact, for malfeasence, the bad actors are likely to be resellers, not registrars, or what Bob Connolley refers to as "phantom registrars". When we started working EPP the universe of writers (the cred problem) was 70. Last week's mail from ICANN is that they expect that 60 more registrars will be accredited within the next 60 days, which is a drop off from the growth in the number of registrars over the past year. Turn to http://www.iana.org/assignments/registrar-ids and check it every so often (does anyone have dated snapshots? I want same, TiA), the integer identifier is a lot closer to 1k than 1c. Why non-linear growth in the number of registrars three years after the bottom dropped out of the market? The drop market. There is speculation that applications have been prepared in bulk. These are the "phantom registrars". The bottom has fallen out of the secondary market too. Independent of the utility or morality of the secondary market, and my registrar makes pin money in that market, there are hundreds more write access tokens to the VGRS dbms than there was two, or four years ago. In the quasi-contractual world of ICANN agreements, which everyone is ready to wave threateningly at any registrar for lack of due diligence over what amounts to less than the price of a bottle of Chilean wine, there is the equal access clause. That clause means that all of the accredited registrars, including the "phantom registrars", are in your risk universe. They all have read|write creds, and some have very, very little technical staffing, or involvement. You wrote off-list during this mess to someone at a business that offers parties that have gotten ICANN papers an outsourced operations and hosting solution, "no hands but marketing". The current chair of the registrar constituency offers "registrar in a M$ can" solutions to new registrars. As the saying goes in ICANN registrar and registry policy debates, ICANN has no business determining business models. The skill and clue level for a significant set of the registrar universe is difficult to underestimate. So, with that sleet on the city workers, every hour of every day a "phantom registrar" is going "dark" for at least 18 hours, if not longer, and that assumes that the "phantom registrar" of the hour keeps "business hours". With that in mind, would you like to try and restate the temporal properties of registrar function, where unlike the prior regime, a registrar could decline to ack a xfr request and become a loosing registrar, a gaining registrar can now decline to ack a post-xfr request to re-instate, for 18 hours plus weekends and holidays. In passing, it is possible that for the "phantom registrar" class of business models, the penalty of de-accreditation is overstated. Eric [1] Its an Indian joke. There were two of us. That's wicked rare in the network rackets. We told jokes.

Bill,

I'm not speaking for Bill. These are my views.

You indicate "a" known former state, which implies that you'd allow reverting back multiple changes under your proposed scheme...

You would have to. Otherwise, two quick transfers would defeat the scheme. An alternative approach would be to prohibit a transfer within one week of another transfer.

Out of curiosity, how far back would you allow one to revert to? Any previous state within the last two weeks? Longer, or shorter?

I would say two weeks would be a reasonable maximum. One week would be a reasonable minimum. One could also do it in terms of business days, but I think this may cause confusion with international issues and which days count as business days.

Given the potential for disruption through fraudulent demands to revert, one has to carry over previous servers for at least this interval to be safe, or do I misunderstand your proposal?

This would mean that a transfer would not really be final for some number of days after the transfer was initiated. This would, of course, create a new problem with fraudulent reverts. A no questions asked revert policy would create one class of problems, whereas a requirement for proof for reversion would create another class. I personally think the best solution is as follows: 1) A domain cannot be transferred within one week of a previous transfer. 2) Once a domain that was in normal status has been transferred, it can be reverted by request of the losing registrar for one week from the time of the transfer, no questions asked, as soon as possible. (Should Verisign do this? Or the losing registrar through an automated interface?) 3) If the gaining registrar questions the reversion, the losing registrar must then provide proof of request for reversion from the previous owner and the gaining registrar can provide proof of release from the previous owner. Some method to resolve this dispute would be needed. Perhaps arbitration at the initial expense of the gaining registrar (who could, of course, bill their customer however they choose). The arbitrator could award costs to the winner of the dispute (in case of total bogus reversion requests). This would allow people to protect valuable domains by picking registrars with sensibe reversion policies. It would also prevent dishonest registrars from holding domains through reversion without authorization, though they could impose costs on the gaining registrar if they wished). The downside would be that when you acquired a new or newly-transferred domain, you would want to wait a week before using it for anything mission critical. You also couldn't consider the act of transferring a domain proof positive of intent to give it to you. You might want to wait a week before, for example, making payment. Or you would want to possess proof of the owner's intent to transfer, not just proof of a transfer. David Schwartz <davids@webmaster.com>