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