RE: Standard of Promptness
On Mon, 17 Jan 2005, David Schwartz wrote: 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. The new (read: current, now) ICANN transfer policy does this. Transfers cannot occur within 60 days of another transfer. I belive this portion of the policy was put in specifically for this reason. Tim Wilde -- Tim Wilde [EMAIL PROTECTED] Systems Administrator Dynamic Network Services, Inc. http://www.dyndns.org/
RE: Standard of Promptness
> 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 <[EMAIL PROTECTED]>
Re: Standard of Promptness
At 3:03 PM -0500 1/17/05, William Allen Simpson wrote: >... > >This will work even in the cases where the bogus domain registrant >submits false contacts, such as happened in panix.com. There >shouldn't be any reason to delay reversion to a known former state. Bill, You indicate "a" known former state, which implies that you'd allow reverting back multiple changes under your proposed scheme... Out of curiosity, how far back would you allow one to revert to? Any previous state within the last two weeks? Longer, or shorter? 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? /John
Re: Standard of Promptness
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 , 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 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.
