RE: [registrars] Registrars Collecting on Multi-Year Registrations

["Ross Wm. Rader" <ross@tucows.com>]

The proposal, as I read it, is not to move data to the registry that was
not there before, but to request that the registry operator publish
additional elements that they already possess.

Patrick - if I have misinterpreted your comments, please advise.



                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Got Blog? http://www.byte.org/blog

Please review our ICANN Reform Proposal:
http://www.byte.org/heathrow


 

> -----Original Message-----
> From: owner-registrars@dnso.org 
> [mailto:owner-registrars@dnso.org] On Behalf Of Siegfried Langenbach
> Sent: Thursday, September 05, 2002 8:13 AM
> To: registrars@dnso.org
> Subject: RE: [registrars] Registrars Collecting on Multi-Year 
> Registrations
> 
> 
> Hallo,
> 
>  pardon me, but again I can not agree.
>  the fact that some registrars (not all) fail the obligation 
> to publish 
> true data on the whois can not result in moving the whois (or part of 
> it) to the registry. If we continue with that logic we will be asking 
> soon that the registry takes over other duties of registrars....and 
> finally we have a monopoly again (with a registry whose registrar 
> does publish false data according to ICANN ) .
> 
> There is a contract between ICANN, registry and registrar... 
> what about to enforce the provisions...is it that strange? not in 
> europe.
> 
> siegfried
> 
> 
> On 5 Sep 2002 at 7:24, Ross Wm. Rader wrote:
> 
> > > > 2. Verisign suddenly begins to display expiry date in 
> the internic
> > > > whois. This may bring in a large amount of support level 
> > > confusion and
> > > > headaches for the registrar
> > > 
> > > This would be a *very* good idea, as it would help a lot for
> > > transfers. Because, other than doing that, there is no way 
> > > for a Registrar to know the ``true'' expiration date (some 
> > > Registrar whois are funky about this) and this is needed. 
> > > Customers would also be able to see the truth (when their 
> > > Registrar does not submit multi-year registrations to the 
> Registry).
> > > 
> > > The date of creation would also be nice.
> > 
> > I think this is a good idea to bring before the transfers 
> TF. One of 
> > the issues that we are struggling with is the data accuracy in the 
> > whois. With Afilias and Neulevel, this isn't so much of an 
> issue as it 
> > is with Verisign. I'll leave this open to commments until 
> say Friday 
> > and then bring forward a proposal based on our 
> constituency's comments 
> > at our next teleconference next week.
> > 
> > 
> > 
> > 
> >                        -rwr
> > 
> > 
> > 
> > 
> > "There's a fine line between fishing and standing on the 
> shore like an 
> > idiot."
> > - Steven Wright
> > 
> > Got Blog? http://www.byte.org/blog
> > 
> > Please review our ICANN Reform Proposal: 
> http://www.byte.org/heathrow
> > 
> > 
> >  
> > 
> > > -----Original 
> Message-----
> > > From: owner-registrars@dnso.org
> > > [mailto:owner-registrars@dnso.org] On Behalf Of Patrick
> > > Sent: Thursday, September 05, 2002 4:04 AM
> > > To: registrars@dnso.org
> > > Subject: Re: [registrars] Registrars Collecting on Multi-Year 
> > > Registrations
> > > 
> > > 
> > > On Thu, Sep 05, 2002 at 11:07:01AM +0530, Bhavin Turakhia
> > > took time to write:
> > > > 2. Verisign suddenly begins to display expiry date in 
> the internic
> > > > whois. This may bring in a large amount of support level 
> > > confusion and
> > > > headaches for the registrar
> > > 
> > > This would be a *very* good idea, as it would help a lot for
> > > transfers. Because, other than doing that, there is no way 
> > > for a Registrar to know the ``true'' expiration date (some 
> > > Registrar whois are funky about this) and this is needed. 
> > > Customers would also be able to see the truth (when their 
> > > Registrar does not submit multi-year registrations to the 
> Registry).
> > > 
> > > The date of creation would also be nice.
> > > 
> > > Patrick.
> > > 
> > 
> > 
> 
>