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


To: "Jordyn A. Buchanan" <jordyn@register.com>
cc: Jarle Greipsland <jarle@uninett.no>, ietf-provreg@cafax.se, brunner@nic-naa.net
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date: Wed, 08 Aug 2001 09:33:05 -0400
In-Reply-To: Your message of "Wed, 08 Aug 2001 14:03:15 BST." <a05100c0ab796d897d2cf@[217.33.137.193]>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: EPP reliance on registrar sponsorship model

Ditto, and ditto.

> Glad to have your comments.  Your concerns reflect others that 
> several folks from the ccTLD community have raised, and I feel like 
> we need to do a better job addressing them because so many ccTLD 
> folks have similar reactions to the existing drafts.  (For that 
> matter, we've got similar problems with non-DNS registries such as 
> the RIRs.)

I know we are getting ARIN and RIPE input as of today, so the RIR & LIR
lacuna is being fixed.

> It's true that the existing documents rely on a registrar sponsorship 
> model.  I've heard the following explanations of why reseller/broker 
> approaches are different from the registrar model:
...
> EPP drafts don't explicilty allow for this [sponsor scoped commands]
> at present, but that 
> wouldn't be very hard to fix (and I certainly wouldn't have any 
> problem with it).

Ditto.

> Jarle makes the specific suggestion of allow authorization of each 
> command by providing a password, digital signature, etc.  This is 
> potentially a helpful suggestion, and not that long ago, Scott's 
> drafts included a requirement that some sort of authentication be 
> made for each write command.  There's no fundamental reason that this 
> can't be done, but the suggestion makes me wonder whether there are 
> any registries using a policy like this today?  (In other words, do 
> you allow your resellers to make changes to objects in your registry 
> by providing some sort of authentication that is known to the 
> registrant?)  It might be helpful to see how this works in the real 
> world before we try to implement it in the protocol.

We are going to try this, AFAIK. It has an effect of vastly simplifying
the transfer set of messages.

> Jarle also suggests:
> 
> >A more general authorization model will also make it possible to
> >restrict the referencing of registry objects.  This can be useful in
> >situations where for instance an ISP is working hard to decommision an
> >old name server, and don't want referenced in any new domain name
> >registrations.  If the registry supports a notion of "reference
> >approvals", the ISP can put an attribute on the name server object
> >that rejects any new references.

We think we've got a nice mechanism to meet this in containers, and their
templates. I'll go over this in more detail if time allows, but I'm better
at writing than speaking.

> It seems like we could accomplish this through the use of a status 
> that disallows new associations.  I think this is a separate issue, 
> but it may be a useful feature to add nonetheless.

It is.

> Jordyn

Eric

Home | Date list | Subject list