On Sun, 23 Jan 2005 03:40:11 EST, John Curran said:
> At 12:55 AM -0500 1/23/05, [EMAIL PROTECTED] wrote:
> >Do you have a requirement that the domain remain unchanged even in the
> >face of fraud on the part of the registry itself?
>
> I indicated failure or fraud by registrars being the proble
At 12:55 AM -0500 1/23/05, [EMAIL PROTECTED] wrote:
>On Sun, 23 Jan 2005 00:00:29 EST, John Curran said:
>
>> If you believe that REGISTRAR LOCK meets the need, then I've failed
>> to adequately communicate my requirements. The requirement is my
>> domain remains unchanged despite complete failur
On Sun, 23 Jan 2005 00:00:29 EST, John Curran said:
> If you believe that REGISTRAR LOCK meets the need, then I've failed
> to adequately communicate my requirements. The requirement is my
> domain remains unchanged despite complete failure or fraud of any
> number of registrars.
Do you have a r
At 11:02 PM +1100 1/19/05, Bruce Tonkin wrote:
>Hello John,
>
>>
>> It appears that "REGISTRAR LOCK" has interesting
>> per-registrar implementation variations which do not always
>> put the domain holder's interests first. While the registry
>> does not, per se, have a direct business interest w
>
> I can confirm that * did get in touch with our Production
> Manager (*) around 1pm Sunday
>
What I want to know, as a customer of a domain registrar and a holder of
many domains, is why wasn't the person/company paying for the domain
contacted through out this process? It s
Hello Mark,
> That's what happened last weekend: Martin Hannigan and I got
> the ball rolling on Sunday morning about 1000 EST. Our 24x7
> customer service department contacted Dotster and Melbourne
> IT. Melbourne IT changed the panix.com name servers back to
> their original settings and
On Wed, 19 Jan 2005, Bruce Tonkin wrote:
> > > (5) The registry will send a message to the losing registrar
> > > confirming that a transfer has been initiated.
> >
> > Can you confirm or deny whether this actually happened in the
> > case of the panix.com transfer?
>
> I don't have any direct
> The problem that got us here was that registrars have
> historically been not flexible enough at releasing
> domains when the owners *did* want to transfer them.
George,
The point I tried to make in my prior note was that not all domains have
the same temporal property of non-functional change
Hello John,
>
> It appears that "REGISTRAR LOCK" has interesting
> per-registrar implementation variations which do not always
> put the domain holder's interests first. While the registry
> does not, per se, have a direct business interest with the
> domain holder, it should be possible to
PS - If you can contribute "client-side" expertise to many of these
protocols, you will be in high-demand.
And as the other co-chair of the erstwhile PROVREG WG, I agree.
jaap
Hello Thor,
> >
> > (5) The registry will send a message to the losing registrar
> > confirming that a transfer has been initiated.
>
> Can you confirm or deny whether this actually happened in the
> case of the panix.com transfer?
I don't have any direct visibility over this.
I have asked V
on 1/18/05 10:51 PM, George William Herbert at [EMAIL PROTECTED] wrote:
> What you are saying, is that you want to have either
> a level of service at registrars, or a new registrar
> with the additional level of service, that instead of
> being easy to deal with in moves, is designed to maximall
>I want a "transfer process" that is inherently difficult, if not
>broken, for domain names that are business assets. I don't care about
>"competition" between registrars, or how much I get soaked for by the
>registrar and registry, or how evil and/or retarded one or both are.
The problem that g
Hello William,
Thanks for your suggestions.
Comments below.
>
> I would propose the following:
>
> 1. Keep existing model but make it "SHOULD" for old registrar
> to inform
>of upcoming transfer (I still don't understand how that failed in
>panix.com case BTW, because I'm pretty cer
Hello Eric,
Thanks for your descriptions from an operator and web-hosting company
perspective.
Essentially different customers have different needs. Some that value
price higher than reliability/security are likely to want to easily move
names around depending on renewal prices and the prices o
At 7:21 PM + 1/18/05, Eric Brunner-Williams in Portland Maine wrote:
> >From: "Bruce Tonkin" <[EMAIL PROTECTED]>
> >...
> > I am interested to hear what members of the NANOG list believe would be
> > a better transfers process.
>
>The notion of "REGISTRAR LOCK" is simply too weak, it can be fl
Sorry about the subject line. I switched horses in mid-stream.
Bruce,
> I am interested to hear what members of the NANOG list believe would be
> a better transfers process.
Non-functional changes of operationally significant configuration data
is avoided. My thumbs are as thick as the next person's.
I'm quite happy to buy a decade's worth of name, even
Speaking as a co-chair of the erstwhile PROVREG WG, which produced
the EPP documents
(http://www.ietf.org/html.charters/OLD/provreg-charter.html):
At 2:18 PM + 1/18/05, someone wrote:
There seems to be a general lack of IETF design and review of protocols
in this crucial area. Again not goo
At 2:18 PM + 1/18/05, Thor Lancelot Simon wrote:
There seems to be a general lack of IETF design and review of protocols
in this crucial area. Again not good.
Possible there is some confusion here. While there is an informational
RFC describing RRP, it clearly says:
VeriSign Registry Registra
> There seems to be a general lack of IETF design and review of protocols
> in this crucial area.
The IETF does not design and review propriatary protocols. VGRS published
the RRP specifications.
I'm always interested in EPP technical minutia.
Eric
On Tue, Jan 18, 2005 at 06:36:16PM +1100, Bruce Tonkin wrote:
>
> (5) The registry will send a message to the losing registrar confirming
> that a transfer has been initiated.
Can you confirm or deny whether this actually happened in the case of
the panix.com transfer?
The other problem I see i
On Tue, 18 Jan 2005, Bruce Tonkin wrote:
> Hello Brandon,
>
> Thanks for your feedback.
>
> >
> > My experience has been that getting auth_info (which criminal
> > staff would have access to) from bad registrars is almost
> > impossible, with registrar-LOCK too they have enough control
> >
Hello Brandon,
Thanks for your feedback.
>
> My experience has been that getting auth_info (which criminal
> staff would have access to) from bad registrars is almost
> impossible, with registrar-LOCK too they have enough control
> to negate the gain in being able to pull a domain to a new
Hello Alexei,
>
> Problem - you are talking about changing registrar, but in
> reality you describe changing of domain owner.
Yes you are right in that often a number of domain name variables change
at around the same time.
>
> Why (what for) is it allowed to transfer from one registrar
>
> The loophole that led to this error has been closed.
Perhaps for you but this process leaves a lot of registrars in position
to do damage, accidentally or by the criminal action of staff.
> In some cases registrars delegate the obtaining of the approval from a
> reseller
Though well inten
- Original Message -
From: "Alexei Roudnev" <[EMAIL PROTECTED]>
To: "Bruce Tonkin" <[EMAIL PROTECTED]>;
Sent: Tuesday, January 18, 2005 3:45 AM
Subject: Re: Gtld transfer process
>
> Problem - you are talking about changing registrar, but in rea
ction.
- Original Message -
From: "Bruce Tonkin" <[EMAIL PROTECTED]>
To:
Sent: Monday, January 17, 2005 11:36 PM
Subject: Gtld transfer process
Hello All,
Given the recent panix.com hijacking, I will give an outline of the
current ICANN transfers process for gtlds.
In the case o
On 18 Jan 2005 at 18:36, Bruce Tonkin wrote:
> There was an error in the checking process prior to
> initiating the transfer, and thus the transfer
> should never have been initiated. The loophole that
> led to this error has been closed.
more details please.
thanks,
david
Hello All,
Given the recent panix.com hijacking, I will give an outline of the
current ICANN transfers process for gtlds.
In the case of panix.com, evidence so far indicates that a third party
that holds an account with a reseller of Melbourne IT, fraudulently
initiated the transfer. The th
30 matches
Mail list logo
