NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Jaap Akkerhuis <jaap@sidn.nl>
Ed Lewis <lewis@tislabs.com>
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Patrik Faltstrom <paf@cisco.com>
General Discussion:ietf-provreg@cafax.se
To Subscribe: ietf-provreg-request@cafax.se
In Body: subscribe ietf-provreg
Archive: http://www.cafax.se/ietf-provreg/maillist/
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
Feb 01 |
|
Working group agreement on functional requirements for protocol |
Apr 01 |
|
Initial specification of provreg protocol |
Jun 01 |
|
Second draft specification |
Sep 01 |
|
Submit draft for standards track |
· Domain Name and Related Definitions
· Generic Registry-Registrar Protocol Requirements
· Extensible Provisioning Protocol
· Extensible Provisioning Protocol Contact Mapping
· Extensible Provisioning Protocol Domain Name Mapping
Provreg Meeting Minutes
8-8-01, London England
Thanks to the primary note taker... Tom McGarry.
1. Agenda bashing - Ed Lewis
The "slides":
=============================================================================
Provisioning Registry Protocol WG (provreg)
Mailing list: ietf-provreg@cafax.se
Charter: http://www.ietf.org/html.charters/provreg-charter.html
Web Page: http://www.cafax.se/ietf-provreg
Wednesday, August 08 at 1530-1730 (3:30pm-5:30pm)
=================================================
CHAIRS: Jaap Akkerhuis (jaap@sidn.nl)
Ed Lewis (lewis@tislabs.com)
AGENDA:
The usual: bashing (the agenda) & document/wg status.........15 minutes
Minute taker (http://www.ietf.org/instructions/minutes.html)
Blue Sheets
OPP draft, comparison w/EPP and GRRP (James).................25 minutes
draft-jseng-provreg-opp-00.txt
Discussion on Data Collection Requirements (Scott)...........20 minutes
draft-ietf-provreg-grrp-reqs-02.txt
http://www.cafax.se/ietf-provreg/maillist/2001-07/msg00002.html
EPP drafts, outside deadlines (Scott) ........................5 minutes
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-*-02.txt
XRP draft, comparison w/EPP and GRRP (Eric)..................25 minutes
http://www.ietf.org/internet-drafts/draft-brunner-xrp-00.txt
RIR comments on Provreg (Cathy, others?).....................15 minutes
Implementation-to-date commentary (?)........................15 minutes
Discussion: comments are sought on the state of implementations of the proposals. (Volunteers sought.)
============
2 hours
Other Items that may creep into the agenda (but haven't been allotted time:
The Definitions document
draft-ietf-provreg-dn-defn-01.txt
)From the charter page:
Milestones
Feb 2001 WG agreement on functional requirements for protocol
Apr 2001 Initial specification of provreg protocol
Jun 2001 Second draft specification
Sep 2001 Submit draft for standards track
Internet-Drafts:
Domain Name and Related Definitions (17681 bytes)
Generic Registry-Registrar Protocol Requirements (46677 bytes)
Extensible Provisioning Protocol (111132 bytes)
Extensible Provisioning Protocol Contact Mapping (62792 bytes)
Extensible Provisioning Protocol Domain Name Mapping (62561 bytes)
Extensible Provisioning Protocol Host Mapping (43321 bytes)
Extensible Provisioning Protocol Transport Over TCP (12703 bytes)
NON-WG docs:
OPP: draft-jseng-provreg-opp-00.txt
XRP: draft-brunner-xrp-00.txt
=============================================================================
Review of milestones
EL - Original milestones were too aggressive. Second draft was too loose.
New milestones are set to meet the groups needs, so we need to make sure to keep pressing with the dates in mind.
Review of draft status
EL - Requirements draft is close to RFC, Core EPP draft has some proposed changes, and other EPP extensions drafts have not yet been reviewed.
Two new non-wg docs; OPP and XRP
2. OPP Presentation - James Sang
Slides unavailable.
Mark Nottingham - Did you use existing XML protocol rather than develop a new DTD?
JS - Other author needs to answer. MN -I'll bring it to the list
Dave Crocker - What within EPP does not meet the needs of China?
JS - EPP is a 2 entity protocol, does not support communications btwn other nodes (r'ant-r'ar, r'ar-r'ar, etc.). (Ask Dave.)
Eric Brunner-Williams - What kind of graph is OPP?
Rich Shockey - How will you maintain transactional intergrity btwn the nodes?
JS - Every request is signed by each node.
RS - Do you prefer any transport protocol?
JS - No we are transport agnostic.
Dave Crocker - Clarification
Jordyn Buchanan - Can't EPP meet your needs if we added the requirements for signatures btwn nodes?
Mark Nottingham Guy - Do you plan on using XML schema rather than new DTD
Dan Manly - How do you make sure proper security is in each node?
Rich Shockey - What application would require coordination btwn four nodes?
Jordyn Buchanan - R'ant need to authenticate with a r'y, discussed on the list and has been desire of some ccTLDs.
JS - Multiple tiered phone companies. Scott Hollenbeck response to JB, current EPP draft doesn't provide this capability, but there's o reason why it couldn't be updated or extension added.
EL - Should the WG accept the document?
Dave Crocker - Not good to have two protocol documents but we could try to address the needs met in the document by integrating it into EPP documents.
EL - It may be best for JS to get the document where he wants it before accepting it.
George Ballotsky - Process is too rushed to get a good protocol.
EL - We'll take the question to the list.
(Document has since been withdrawn from consideration.)
4. Data Collection Policy Requirement - Scott Hollenbeck
Slides attached.
Dave Crocker - You can keep the rqmt knowing that it can't be resolved right now.
Dan Manly - There can be a preference hierarchy.
Eric Brunner-Williams - I've addressed the suggested changes on the list. R'ys need to distinguish btwn social and technical data. Policy announcement by R'ys is the problem that needs to be solved. P3P is used as a starting point because it exists, there's no suggestion that Provreg follow P3P policies or procedures.
SH - What is the information that you want presented?
EBW - Current policy at the time of the transaction.
Jordyn Buchanan - There are instances where r'ants may want to pick a policy but r'y contracts dictate what the r'y does.
EBW - R'ars or r'ys may request data that is above and beyond what is necessary and not required by the contracts.
Dan Manly - R'ys can provide that information on their websites or by other means.
Jordyn Buchanan - It would be good to hear from non-gTLDs.
Dave Crocker - It's an important issue and should be addressed, but it's not in the critical path of ths group.
EBW - It's been done so this is not a
Paul Kane - There are rqmts similar to this in some countries.
EL - Straw pole; As is - a few, Changed - none, Deferred - more than as is.
Dan Manly - Does deferring this break any laws in any countries? Many Yes's shouted out, no No's.
5. EPP Status - Scott Hollenbeck
6. XRP - Eric Brunner-Williams
Slides attached.
Jordyn Buchanan - I prefer distinct documents. Is it possible to separate BEEP from Push?
EBW - Yes.
Scott Hollenbeck - I support separate documents. Push has some problems if client is off. Messages need to Que. I support including it and moving forward.
Dan Manly - Experience shows that r'ars are having a problem understanding EPP. Further extensions would only add to the confusion.
Dave Crocker - I originally thought that polling was the est solution however the internet comunty has ot had allot of experience with transaction models the more I learn about it the more I believe that there are great performance benefits in push.
Jordyn Buchanan - There should be consistency with the event model.
Bruce Tonkin - R'ants should expect different models from different r'ys. I support push as an option of the core protocol.
Rich Shockey - I support Bruce and disagree with Jordyn. Let's not preclude features that support other (non-domain name) r'ys.
Scott Hollenbeck - Push could create push-storms to the r'ars.
Dave Crocker - Queing problems could be solved out of the protocol such and email.
7. Notes on GRRP/EPP from an RIR - Cathy Murphy (ARIN)
Presentation Notes:
===========================================================================
ProvReg
Focus: How the drafts might or might not relate to the RIR's (mostly not)
* Current drafts are okay, but definitely domain centric, focus on relationships that can be seen with domain registrations
Commonalities:
- do registration of some kind of information at a basic level
- some user scenarios are the same (many ISPs act as re-sellers/brokers)
- similar registration of nameserver information (in-addr.arpa)
- similar registration of contact information (Whois)
Differences/Issues:
*1* fundamental difference: any "rights" of usage of domain name ends up with the registrant versus IP control is fundamentally hierarchical
- end-user subject to upstream, whether an ISP, NIR, LIR or RIR
- IP "transfer" is a top-down, not bottom-up, process
- IP registration request is not for a specific, identifiable object like a domain name; rather, it describes an amount (/18), which they might or might not receive.
*2* Most domain registrations (GRRP) tend to be session-oriented, versus RIR registration process, which is longer and may extend over several days/weeks.
- EPP 2.0 "All EPP commands are atomic and idempotent."
- XRP 2.3 "XRP supports four major types of services ...
Each of these services is atomic in nature and identifies a logical transaction. Each of the requests is idempotent, either succeeding completely or failing completely and producing predictable results in case of repeated execution."
- GRRP provides near immediate registration; RIR has a whole analysis review period (comparable to if domain registry were required to perform research for the other "IP", i.e., intellectual property and/or trademark research, and confirm application information)
* first contact with RIR is more like an application, not registration
*3* RIRs don't have the volume
- IP and AS Regs: 500 p/wk (max)
- SWIP's/3000-5000K per day
- transfers: 2 week minimum to process
- routing registrations -- "IRR" -- different beast for ARIN; couldn't tell you the numbers
*4* Contact info is "technical" versus "social"
SUMMARY:
Suggest that ProvReg change Generic Registry Registrar Protocol (GRRP) to Generic Domain Registry Registrar Protocol (GDRRP); save GRRP term if and until there is a core protocol that does speak to registration objects other than domain names.
===========================================================================
Domains have rights of the name holder. IP addresses are different.
RIRs don't get requests for specific names.
EPP protocols are connection oriented. IP addresses are not. The processes take longer.
RIRs do not receive the volume of requests DNS R'ys do. 500 in a week would be allot.
Contact information is technical in nature and not social, there's a rqmt to disclose it.
EPP needs to go a layer below.
EBW - Are you aware of anyone selling contact databases?
CM - No.
Mark Kosters - There is social data collected by RIRs. They will need to be concerned about privacy rights.
EBW - Can GRRP be saved or would you prefer it not be intended for RIRs?
CM - I prefer that it get changed to met RIR needs, but I understand that there is a time issue here with the gTLD r'ys.
Scott Hollenbeck - Draft and WG goals are specific to domain names. We could have a new rqmts for RIRs.
Greg Someone Telnic - Some registries may be required
8. XRP vs EPP
Poll - WG preference is to hammer the two into one protocol.
Scott Hollenbeck - The XRP extensions can be included as extensions.
Patrick Falstrom - Is it a problem if there were two models?
JB - If we try it will fail.
Dave Crocker - Worry about long term and high performance.
Scott Hollenbeck - There is interest in writing an SCTP transport. I don't want to be forced to implement BEEP right now even though I believe it is a good thing n the long term.
Mark Nottingham - W3C is also addressing this issue.
EPP Schema Compatible And Three non-Schema Extensions
Data Collection Policy Requirement