Current Meeting Report

2.1.9 Provisioning Registry Protocol (provreg)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 07-Nov-01
Jaap Akkerhuis <>
Ed Lewis <>
Applications Area Director(s):
Ned Freed <>
Patrik Faltstrom <>
Applications Area Advisor:
Patrik Faltstrom <>
Mailing Lists:
To Subscribe:
In Body: subscribe ietf-provreg
Description of Working Group:
Administration of Domain Name Service (DNS) registration increasingly distinguishes between the operation of a "back-end" registry data base service for registrations, versus "front-end" support services by registrars who interact with registrants and with the registry. Especially for various Top-Level Domains, the desire is to permit multiple registrars to share access to the database. Conversely, there is a desire to allow a registrar to access multiple registries via the same protocol, even if the registries differ in operational models.

This working group will develop a specification of the requirements and limitations for a protocol that enables a registrar to access multiple registries and will develop a protocol that satisfies those requirements. The protocol will permit interaction between a registrar's own application and registry applications.

The initial specification will allow multiple registrars to register and maintain domain names within multiple Top Level Domains (TLDs). The specification should be flexible enough to support the different operational models of registries. The specification should allow extension to support other registration data, such as address allocation and contact information. The working group will use as input the "Generic Registry-Registrar Protocol Requirements" (draft-hollenbeck-grrp-reqs-nn) and the Extensible Provisioning Protocol presentation, documented in (draft-hollenbeck-epp-nn).

The group will consider support for multiple operational choices, such as for transport and security; it will create no new transport or security protocols. The group may consider use of the new protocol for diverse registration and update scenarios, in order to understand limitations and possible extensions that are appropriate. Specification for user interface access, such as by a web front end, is beyond the scope of this working group.

Documentation from the working group will:

* Specify the objects exchanged between the registry repository and registrars, the relationships among the objects, and the protocol for exchanging objects between a registrar and the registry; at a minimum the objects will include: domain name, IP address, and contact details for registrants

* Describe appropriate mechanisms for security during registrar access

* List useful examples of registrar access transactions

Goals and Milestones:
Done   Working group agreement on functional requirements for protocol
Done   Initial specification of provreg protocol
Done   Second draft specification
Sep 01   Submit draft for standards track
No Request For Comments

Current Meeting Report

Provreg Minutes

Buchanan appointed as the scribe.

Ed Lewis:

Document status:

Definitions dropped.
Requirements in front of the IESG.
Last call: EPP base; host, domain, and contact info mapping; and EPP over TCP.
Two other documents: Containers and BEEP. Will address later.
What will happen over the next couple of months? Last call was just concluded.

A few comments on last call items:
Scott Hollenbeck:

* Slight issue with the way XML schema deals with choices. Right now could say that you want to use the same things more than once. Tradeoff between getting multiple repeated elements or an empty ("none").
* Modification to domain mapping so that could delegate to name server which is not a host object.
* Last issue: want representation in more UTF-8-ful registration format.

Eric's suggestion-why do you need both? We could just take whatever we get. Requirement in requirements draft. Redundancy and extra elements; get rid of

Jordyn Buchanan:
* The reason we added the non-registered objects as name servers was to solve the out-of-zone hosts?

Hollenbeck: Yes

Buchanan: I would prefer another solution to that problem if one is available.

Daniel Manley: What does the new schema gain us if the first address is still ASCII?

Hollenbeck: Gets rid of some elements, just have a variable number of address elements.

Sheer El-Showk: Wasn't there a way to have per-registrar views of out-of zone objects. That seems like it might solve the problem.

Wesson: Also, there's a difference between objects and records in the document.


Lewis: Will do presentations on implementations now. First, Jim Gould.

Jim Gould: presentation attached (only set of slides presented at meeting)

Rick: Was registry thick or thin?

Gould: We've done both.

(unknown): Did -04 release. Toolkit supports Java/C++, been out since summer. Have been playing with extensions, but not released. Have 100 registrars certified on EPP-04; looking at -05 and beyond.

Wesson: Registrars noticed issues with lengths. Can you discuss:

(unknown): As lengths changed, been very difficult to keep up. From an operational perspective, would be nice to get consistent. Haven't had to truncate because have been growing.

Hollenbeck: Speaking of length, one last call issue was an increase of postal address from 64 to 255 characters.

Lewis: Now Sheer El-Showk's presentation.

El-Showk: We did both registry and registrar implementations. I'm not talking about the protocol itself. A few small points. Contact name field is only a single field, versus two (first, last) in Whois. Makes for a difficult mapping. Name/organization; name is a required field, whereas organization is not. Response codes should be more informative; not sure extension mechanism would be appropriate. New statuses may be required. Business logic for statuses horrendous to implement; a significant part of the business logic. XML very expensive for check commands. Lots of overhead that is not necessary; because form data is identical, makes it easier to do cryptanalysis. Not clear how to implement an error condition on a single check.

Manley: Discussion of change in semantics of check command, adding additional returned data.

El-Showk: I don't like the idea of making it more complicated, should the whole check fail if 1 out of 1000 returns an error.

Gould: I would assume that if one fails.

Buchanan: Scenarios may exist in which one out of many could fail exist.

Gould: Then just fail the whole thing if your server logic can't figure out what to do.

Wesson: There's no provision anywhere saying Whois has to say firstname/lastname, so that's not a big deal.

El-Showk: I also mentioned retry commands. Relying on commands versus transaction ID means that it may make it more difficult in the future. Why not client/server ID?

Hollenbeck: Idempotency is a property. By it's definition, it's the structure of the command. Take away or adding properties could hurt it.

El-Showk: It's in mappings, not base protocol?

Hollenbeck: Yes.

El-Showk: Wouldn't it be useful in the base protocol? A unique client trans ID could allow.

Hollenbeck: We said the server wouldn't necessarily track; it's not a requirement.

El-Showk: In our implementation I did.

Lewis: Now Dan Manley.

Manley: A couple of comments; we used an early version of EPP, so many comments are now out of date. From a registrar perspective, transfers aren't handled very well in batch. May want to transfer hundreds or thousands of names. Easy to assimilate in RRP. In EPP, it's more difficult because each object could have different auth_info. Couldn't guarantee that the same domains had the same auth_info. If there was a way to group, that would be good. Other issue is contacts, and contact objects. They are cool, but even more difficult to transfer; might have to transfer many contacts. Transfer a subset of the profile. Containers could solve; extend domain transfer command to take all contacts with it.

Hollenbeck: Here's a scenario-I have a domain object with a specified registrant, and a tech contact that belongs to an ISP. Should the domain transfer take the tech contact with it?

Manley: True. Hard to solve.

Wesson: Might be appropriate to write a document on BCP from registry/registrar perspective. Would be really good.

Manley: I'll try to put my notes into a document.

Gould: When you start selling other things than domains, they have to be completely decoupled. Might break other product associations.

Dan: This might move onto container discussions.

Buchanan: Could transfer contacts instantaneously and then act on them, since the contact has the authorization built in and generally no billing implications.

El-Showk: But then your domain and contacts could be out of sync.

Buchanan: I'm talking about situations when domain has already been transferred and domain has been left behind.

Lewis: Should we be trying to send these documents up this month?

Wesson: I would encourage the group to move the documents forward. Many of the comments have been issues dealing with tracking the protocol as opposed to actual implementation issues.

Lewis: For implementations out there, over time we want to do some interoperability testing. That is the real test.

Two documents still being working on. Two promised: EPP over mail; EPP push. Also some murmur of new issues. Could start considering because base has been worked well. Don't want to. Will update milestones; only one left is about to be accomplished.


Anyone have comments on containers?

Manley: Containers, at first and second glance, provide a lot of good functionality. For registrars, could help with transfers-able to transfer an entire profile in a single command. Could be scary on the server side.

Billing? Objects could be in various states. Makes it easy to change and do mass changes. I had some questions that were not all answered.

Tom McGarry: We'll volunteer to do push. Re: containers. Not implemented yet. What are options other than standardize?

Lewis: Experimental versus standards track.

McGarry: Customers like the idea.

Wesson: Not convinced that transfers and containers aren't a big security issue.


None received.