[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: ietf-provreg@cafax.se
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Sat, 10 Feb 2001 22:00:33 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Transfer Notification a requirement?

I don't have a problem with striking 3.7-[8] if no one objects.

<Scott/> 

> -----Original Message-----
> From: Jordyn A. Buchanan [mailto:jordyn@register.com]
> Sent: Friday, February 09, 2001 12:06 PM
> To: James Seng/Personal; Ayesha Damaraju; ietf-provreg@cafax.se
> Subject: Re: Transfer Notification a requirement?
> 
> 
> At 01:18 PM 2/9/2001 +0800, James Seng/Personal wrote:
> >I would like to point out again that this is one area where specific
> >design and policy which leak into requirements.
> >
> >The problem here is that Object Transfer must both 
> registrars to agree.
> >And to prevent abuse, it is policy decision that such transfer who
> >require giving the losing registrar to stop the transfer. (In other
> >words, it is the SERVER which is suppose to keep track of 
> this, not the
> >protocol).
> 
> I agree with James that 3.7 still contains some policy 
> language.  Can we 
> just lose 3.7 [8]?  That's a policy issue.  Everything else 
> just describes 
> capabilities that the protocol should have.  The protocol 
> *should* include 
> a capability for the losing registrar to stop the transfer 
> because some 
> registries do this.  If your registry doesn't act this way, 
> then you don't 
> have to pay attention.
> 
> >This problem _could_ be solved in another way, ie, by having
> >authorization access directly on objects. This allows the
> >owner/registrant to do whatever he wants with the object including
> >transfer so long he can provide the appropriate authorization.
> 
> This is already handled.  Everything is extensible and 3.7 
> [4] says "The 
> protocol MUST provide services to confirm registrar authorization to 
> transfer an object."  It's up to the registry to determine what that 
> authorization is.
> 
> >There are many ways to solve a problem. IMHO, requirements should be
> >independent of any design.
> 
> True.  I think we should lose 3.7 [8].  Then there's no policy in 3.7.
> 
> Jordyn
> 

Home | Date list | Subject list