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
|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|
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
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
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
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