I agree that it makes no sense.  I'm assuming that since the domain does 
not move to the New RSP that the Prior RSP will bill for the next 
Renewal.  Isn't that kind of like NSI continuing to bill for domains that 
have moved to OSRS?

To make this clean from the start, we advocate only allowing renewals 
through the current RSP.  You can't renew at OSRS for a domain registered 
with NSI, so why should RSPs be any different?  It will be potentially 
confusing to the customer and there could be some abuse as well.

We do not see why making this change now requires the automated RSP-RSP 
transfer system to be in place.  We also do not see why this change makes 
it more restrictive on the customer.  What we do see is potential confusion 
and potential abuse.

We do not advocate reacting by closing the coral gate after the horses have 
escaped.  We think that being prudent, looking at the big picture and 
mitigation is a much better approach.


At 01:55 AM 1/6/01 +0100, you wrote:

>Chuck Hatcher wrote :
> >
> > The renewing RSP is debited, but the domain does not move to the renewing
> > RSP's list.
>
>If this is correct, it makes no logical sense - to me anyway.
>
>
> >  Name servers do not change.
> >
> > I think this needs to be changed so that no RSP other than the current one
> > can renew, without an actual RSP change.
> >
> > ----- Original Message -----
> > From: "A. I. Sinclair" <[EMAIL PROTECTED]>
> > To: "Chuck Hatcher" <[EMAIL PROTECTED]>
> > Sent: Friday, January 05, 2001 7:23 PM
> > Subject: RE: renewals
> >
> >
> > > The whole discussion as far as I know has been the fact that if
> > a renewal
> > is
> > > made at another RSP the domain would move to the renewing RSP's list of
> > > active domains and the renewing RSP is debited for the renewal - that
> > > effectively equates to an RSP transfer.
> > >
> > > Are name servers affected during an RSP renewal transfer if the renewing
> > RSP
> > > has default name servers set up - anyone?
> > >
> > > Regards
> > >
> > > A. I. Sinclair
> > >
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> > > Behalf Of Chuck Hatcher
> > > Sent: Friday, 05 Jan 05, 2001 11:02 PM
> > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > > Cc: Scott Allan
> > > Subject: Re: renewals
> > >
> > >
> > > Currently an OpenSRS domain name can be renewed at any OpenSRS RSP.  As
> > far
> > > as I know, a renewal at an RSP other than the "current" one
> > does not cause
> > > an RSP transfer (except in a "de facto" sense).  For instance, I don't
> > think
> > > it will cause the domain name to move to the renewing RSP's reseller
> > > interface.
> > >
> > > I wouldn't have a problem with an RSP-to-RSP transfer requiring adding a
> > > year to the registration, and I agree with you when you say 'A
> > "straight"
> > > renewal (no transfer) should always only be possible with the current
> > RSP.'
> > >
> > >
> > > ----- Original Message -----
> > > From: "A. I. Sinclair" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>; "Scott Allan" <[EMAIL PROTECTED]>; "Chuck Hatcher"
> > > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > > Sent: Friday, January 05, 2001 4:37 PM
> > > Subject: RE: renewals
> > >
> > >
> > > > I am reposting this as I did not see discussion on the issue of
> > > > renewal/extension at time of transfer between RSPs which to my mind
> > should
> > > > be essential.
> > > >
> > > > I am intrested on Tucow's/others' take on this.
> > > >
> > > > Regards
> > > >
> > > > A. I. Sinclair
> > > > ------------------
> > > > My previous post :
> > > >
> > > > The concept here should be simple and consistent with current market
> > > > practices.
> > > >
> > > > The proposed system is based on renewal (through other RSP site)
> > triggers
> > > > transfer - that is not how it works today.
> > > >
> > > > If we stay consistent and if a customer does not like my
> > service, all he
> > > has
> > > > to do is transfer to another RSP and the transfer triggers the renewal
> > > (just
> > > > as is the common practice today when transferring between registrars).
> > > From
> > > > a registrants perspective there should be no difference in
> > events when
> > > > tranferring between RSPs or registrars - it should be the same.
> > > >
> > > > A "straight" renewal (no transfer) should always only be possible with
> > the
> > > > current RSP.
> > > >
> > > > If a customer prefers a cheaper or whatever RSP, he does what he
> > normally
> > > > does today, and that is  to effect a tranfer to another RSP or
> > registrar.
> > > > Transfers between RSP's should also carry the same min one (max ten)
> > year
> > > > renewal period  conditions (sothat cutomers don't tansfer for the sake
> > of
> > > > the transfer). This will keep OSRS "internal" transfers
> > consistent with
> > > the
> > > > market.
> > > >
> > > > It is not a matter of trying to own customers, they (registrants) will
> > > > always have choice.
> > > >
> > > > My point being a transfer between RSPs should always automatically
> > > initiate
> > > > a renewal and never the other way round.
> > > >
> > > > A. I. Sinclair
> > > >
> > > >
> > > > At 11:06 PM 1/2/01 -0500, Chuck Hatcher wrote:
> > > > >Please accept my vote for this to become an issue.
> > > >
> > > > Accepted.
> > > >
> > > > >I think the only way an RSP other than the one who registered the
> > domain
> > > > >name should be able to renew it is if the domain name is
> > transferred to
> > > > that
> > > > >RSP.  (I think there should be an automated process for this
> > that makes
> > > it
> > > > >at least as easy to change RSP's as it is to change
> > registrars. This is
> > > in
> > > > >OpenSRS's best interest, because if an end user wants to leave their
> > RSP,
> > > > >and it is difficult to move to another OpenSRS RSP, they will find
> > > another
> > > > >registrar.)
> > > >
> > > > Agreed.
> > > >
> > > > Again, as I think back as to why this approach was taken, it probably
> > had
> > > a
> > > > lot to do with not having automated RSP to RSP transfers. So, it was
> > > > certainly a compromise based on missing functionality. Not a
> > good thing.
> > > >
> > > > While I have no problem adding in the restriction, I think it might be
> > > best
> > > > to wait until RSP to RSP transfers are automated, which is
> > near the top
> > of
> > > > list of things we are to work on next. Fair?
> > > >
> > > > Personally, I do not see the *real* threat in keeping this open,
> > > > realistically no one would sanely attack this market.  The advantages
> > the
> > > > "sponsoring" RSP has blow this right off the concern meter of real
> > issues
> > > > for me personally (although I do realize many of you are
> > concerned, and
> > I
> > > > respect that).  In my mind, I do appreciate (if I think as an
> > RSP) that
> > > > there seems to be little value in this open-ness, and there is a
> > perceived
> > > > threat, but I can not (as an individual RSP) bring myself to
> > be worried
> > > > about it - if my customers are that easy to poach, or want to
> > leave that
> > > > badly, I deserve to lose them. The open-ness of this policy is
> > > > "pro-registrant", and IMHO we should all keep those
> > registrants in mind,
> > > > since it is to them who we are delivering value.
> > > >
> > > > However, if we have made a wrong judgement call on this
> > issue, lets fix
> > > it!
> > > > I have been wrong before... :)
> > > >
> > > > >"Renew Anywhere" is going to cause a lot of problems with
> > recordkeeping.
> > > > >For instance, if my customer adds two years with another
> > RSP, how will
> > I
> > > > >ever find out about it?
> > > >
> > > > Again, I do not see this being a problem in that many
> > registrants would
> > > > renew with other RSPs. The odds of them renewing with another
> > registrar
> > > are
> > > > far greater. Why would they renew elsewhere? Again, my personal views
> > may
> > > > be different from yours, and as such we may need to adjust
> > our policy to
> > > be
> > > > reflective of what the majority of out RSPs want and need
> > (and there is
> > no
> > > > problem with this) - but I always personally cringe when policies are
> > put
> > > > in place that try and make the customers desires difficult for them to
> > > > fulfill; sound like NS^H^H anyone you know?
> > > >
> > > > Trying to *own* customers through restrictive policies is bad
> > > > (short-sighted) business. IMHO, the only way to *own* a customer is to
> > > > *earn* their business continually. Earning their business means giving
> > > them
> > > > value continually. Granted, not all customers appreciate this, but, I
> > > > maintain the strongest long term customers (the most valuable
> > customers)
> > > do.
> > > >
> > > > >The biggest part of the work is in the initial registration,
> > dns setup,
> > > > >hosting or forwarding configuration.  A lot of business
> > models count on
> > a
> > > > >stream of future renewals to make money.
> > > >
> > > > Absolutely, us included! However, anyone who thinks they can control
> > > > customers through policies as opposed to continually earning their
> > > business
> > > > not do well in the long term.
> > > >
> > > > It should be noted that in no way do I consider OpenSRS a
> > perfect model.
> > > We
> > > > have lots of work to do and much room for improvement wrt
> > *earning* our
> > > > business. I do assure you that we are aware of it, and will
> > continue to
> > > > work hard to earn your support.
> > > >
> > > > Regards,
> > > >
> > > > sA
> > > > Scott Allan
> > > > Director OpenSRS
> > > > [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> >

----
Don Brown - Dallas, Texas USA       Internet Concepts, Inc.
[EMAIL PROTECTED]            http://www.inetconcepts.net
PGP Key ID: 04C99A55                  (972) 788-2364  Fax: (972) 788-5049
Providing Internet Solutions Worldwide - An eDataWeb Affiliate
----

Reply via email to