Current Meeting Report

2.1.12 Provisioning Registry Protocol (provreg)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 11-Feb-02
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
Jan 02   Return the original requirements to the IESG
Feb 02   Advance the core specs to the IESG
Mar 02   New version of the non-core, first round specs
Mar 02   EPP over SMTP first mature draft
Jun 02   Interoperabilty test
No Request For Comments

Current Meeting Report

Provreg Meeting minutes

1. WG status (Ed Lewis)
- Core Documents: In IESG process in various stages
- Other documents - no discussion
- 1 Unsolicited individual submission
- Next target: move core drafts to draft standard as per RFC 2026
Patrik F: We need 2 independent client and 2 servers to test interop. (all must work together)

2. Last Call Comments on EPP drafts (Scott Hollenbeck)
- Requirements Draft:
1. WG last call completed
2. Comments by IESG in Feb, completed in Feb.
3. Waiting IESG
- EPP core drafts
1. Last call ends 29 March - few comments for additions or corrections
- Questions
Patrik F: IESG or AD has not received any more comments than those mentioned in the meeting.

3. In-process documents
- BEEP - new revision available in the future.
1. Comment: Is anyone planning any implementation on this draft?
- Container draft - will not be continued.
- SMTP draft - Still being worked on (rumor). Some interest in seeing this as a draft.
- Push feature draft - missing description document. No one has responsibility for that draft. If Push feature is desired, please submit an individual submission draft.

4. Implementations (about 5 )
- RTK (Sourceforge project) release Java version of registry tool
1. Different releases for different levels of EPP(draft revisions) - plan on restructuring releases into one package

- Melbourne IT (for AusRegistry work) (B. Tonkin): .au registry release
(also a Sourceforge project).
1. Does contain implementation specific extensions (differs from .us extensions)
2. first country code to use EPP

- Verisign (S. Hollenbeck).
1. Non-core effort (smaller domains) using EPP for registry
2. When EPP reaches RFC status, .com/net/org will go to EPP
3. Registry (Verisign) will not hold customer information/contact. That will still reside at the registrar level.
4. All RRP based registration systems will eventually migrate to EPP once contract expires

- .sg registry (E. Chung)
1. Issue encountered: multiple statuses for a domain name.
2. Need for additional EPP messages in core documents?

- NIC Mexico (F. Arias):
1. looking at rolling EPP out. But using other means to authenticate the registrant. Either using the registrar and EPP (with some further security functionality like PKI) or some other authentication protocol (not relying on EPP).

5. Registry-specific extensions (H. Liu)
- .us TLD implementation for public review
- Informational - may not be WG draft, but informational as an extension to EPP. Test to see if EPP really is extensible and still remain interpretational.
- Differences from draft specs:
1. Collect NEXUS info for usTLD registration
2. 2 new parameters: AppPurpose and NexusCatagory
- Alternatives: Name-value pairs or new XML schema definition
- Comments:
1. Where scheme modified? ContactObject extension field

6. Scott H. draft on EPP and DNSSEC/ENUM an individual submission, but belongs/will remain independent submission (not DNSEXT) and hoped to be included in DNSOP WG

7. Next Steps
- Need for a BCP/Informational RFC on how these extensions should look?
1. moved to list
- Interoperability test: of core protocol specs, not extensions.
1. When: wait until we get RFC status - winner
- No BEEP/SMTP comments

General comments/questions
1. if we start talking about extensions - rechartering necessary?
2. Question of "status of command" request message - what it means and the status of the draft.
- Original poser of the question not present, so no further progress on debate could be made - Scott Hollenbeck gave some explination of the status of the draft (on hold).


EPP Last Call Comments
EPP for usTLD