NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Jaap Akkerhuis <jaap@sidn.nl>
Ed Lewis <lewis@tislabs.com>
Ned Freed <ned.freed@innosoft.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 |
ProvReg Working Group/21st March 2001 Tuesday 3:45pm.
http://www.ietf.org/html.charters/provreg-charter.html
Agenda:
- Agenda bashing
- WG Status (Interim meeting etc.)
- WG Document Status
- Design teams presentations (Protocol, Transport, Securty)
- GRRP requirements DOC
- XRP Proposal
- AOB
WG Status - Edward Lewis
- requirements, defination doc
- hopefully to finish within a year
- 3 design team - protocol, transport, security
- not binding, just focus
- 2 current proposal, epp and xrp. xrp is slightly different
Protocol Design Team - Scott Hollenback
- design team members intro
- new requirements issues
- authid for all object updates
- pass-thru element
- common to all objects (aka handle)
- make registration period and period unit optional
- idenfification data purpose?
- base protocol design issues
- client-server vs peer-to-peer (don't preclude client-server)
- ping command?
= Bill Manning: Ping has overloaded use
+ room consensus to change 'ping' to 'check'
- query feature to pull notification
- client hello for connectionless transport e.g. smtp, pipelining
- command/response pipelining
= James: isn't this it is a transport problem?
= Scott: It may impact how to protocol
= George: Large number of transaction.
= Rick: Async transaction? Good or bad?
- renew command vs update option
- should recombine renew and transfer into update? no answer.
- auth id for transfer vs other updates
- non-sponsor use only for transfer request.
- object relationship queries
- good or bad in a provision protocol
- common object design issues
- globally unique ROID for all objects
- <local part>-<globally unique part>
- registry part - local, iana? - globally
- Non-Unicode charset identification
- May need to store non-Unicode identifiers
= Rick: Since we are dealing with XML and UTF-8 is the charset, would it be more appriopriate
= James: strong suggest to use only one charset, e.g UTF-8. See CNRP on how it done properly.
- domain object design issues
- Status flag per registry prolicy or protocol. No consensus
- contact object design issues
- Add extension attribute for E164 numbers
- Data purpose definition - no proposal
- Dual charset representation - TDB
= Sheer: there is an original thing in EPP. There is something sending back TransID from server to client. is it still inside?
= Scott: No. Client can get back lost ID from servers.
Transport Design Team - Jordyn Buchanan
- Goals of the Design Team
- identify issues relating to the movmeent of data between registr*s
- recommend specific transport mechanisms
- creates I-D to describe the use of the transport
- Issues
- Transactional integrity is needed
- How to provide it?
- How do participants recover from loss of association
- Need for two types of transport
- "real-time" with high volumne of transactions
- "email-based" with low volumne of transactions
- Options for Real-Time
- BEEP
- provides standardized framework
- concern about overhead and lack of operational experience
- TLS
- Various "non-literal" transport
= involves mapping base provreg to over-the-wire format
= provide better network efficieny and reduce computation
= Rick: can give an example of "non-literal"?
= Bill: Fax? Can you handle this?
= Jordyn: actually consider binary representation of XML
= Eric: clarify about email-based?
= Jordyn: yes, no consensus
= Rick: request a poll on if this is what transport need to do?
= Dave: already reach a consensus for completeness but want proposal
= George: consider total-paper base transport
= Sheer: try look at volumne of XML over over-the-wire?
= Jordyn: no operation data yet.
= Daren: TLS and BEEP are interoperate...why two choice?
- HTTP
- UDP - not viable
- Ongoing Strategy
- quantitative analysis of various options
- ideally from ops experience, alt. computation based on known characteristics
Jaap: There should be an email transport as well. A lot of the TLDs (such as ccTLDs) are already using email for registration (with ot without templates). An email tranport mechanism will also be a nice transition mechanism for registries who want to upgrade to a standard protocol such as the proposed epp.
Security Design Team - Bill Manning
- ProvReg A&I, Authentication and Integrity - not security, no privacy
= Rick: Privacy over the connection is an important issues
- Security is a nebulous phrase
- Items of real interest are: authenticity and integrity
- Who does what where? - lots of prior (black) art
- Provide guidance to other teams
= William: take encryption as an implication of privacy
= Bill: Privacy are really local manner. Those who decide has to make sure that protocol does not get into the way.
= William: Privacy needed on transport
= Edward: Just in case we run out of time, we will remeet at 2:00pm after the IDN WG. IDN WG may have 1 hour free for us.
XRP - Eric William-Brunner
- not a competiting proposal. It is an internal design doc of Neulevel.
- some comments received on document
- -01 was submit but bounced. intent to submit end of the week.
- diff from epp: BEEP is the explicit transport mechanism
Requirements Draft - Edward Lewis
- "We are really close now." so we thought
- Past month have steady stream of comments so not sure if it is ready for Last Call. Anyone have any other concern.
= Eric: Still concern that we have only client initiation.
= Rick: suggest protocol designer go thru requirements one by one.
= Scott: Yes for EPP. But the Protocol Design Team should do it again.
= Edward: Requirements extensibility
= Eric: Suggest next meeting to get larger block of meeting time.
= Rick: Privacy is something that seem to get cut-off
= Bill: What is about privacy that protocol need to take care.
= Rick: there are some info which only known by the registrant and registry and that needs to be take into consideration.
= Bill: the use of encryption to protect privacy is fine. but have not seen all the design team document to make any comment.
= Dave: encryption can ensure integrity violation is not perfect. protocol privacy and database privacy is different.
= Bill: Privacy is a sensitive word as bad as security.
= Eric: Policy for data-collection as a separate issue from privacy / encryption
= Zhuyu: Why is UDP ruled-out for transport?
= Jordyn: provreg protocol payload is likely to exceed datagram, many services like traffic congestion need to be re-invented.
Resumed 22nd March 2001 2:30pm
= Edward: worried that different teams may overlap each another, e.g. Protocol and Security cross
= Jordyn: weekly digest be publish so they can check
= Edward: by next friday, can every design team put something up
= Edward: what if transport does not provide the same security as the protocol design team expect?
= Jordyn: hope to see nothing we do now will preclude what future users may use this protocol
= Sheer: there is no way to treat security on transport generally, e.g. security over email very different
= Edward: Security - what is it we trying to protect?
= Sheer: privacy refers to maintain data integrity, not privacy as data privacy in data
= Edward: just want to scope this out and doc it it down
= Dave: did u say privacy = data integrity?
= Sheer: yes
= James: feels we still focus too much on domain. while that is a short term goal, strongly support a design team or someone to lead the effort. also we should continue to try to get other registry more involved in this wg.
= Edward: unique handle issues...a lot of discussion on mailing list.
= Scott: a lot of requirements posted and will be captured in the reqs
= Sheer: has consideration been taken that unique handle may be refer object outside the registry?
= Edward: reqs may be ready for last call after one more revision. but some concern over defs. maybe we should put back defs into reqs and send it in.
= Scott: okay, next week or so.
= Edward: next step until London. In a week of half, hopefully status report. feel free to comment on the result of the design team - design team is not final.
= Sheer: should we post weekly digest to the mailing list?
= room: no..yes..no..yes..chuckle
= Edward: I think we have consensus. weekly is good.
---------------------------------------------------------------------------------------------------------------------------
IETF provreg interim meeting
Location: Washington Dulles International Airport Marriott
Date: Feb 20, 2001
Start Time: 10:00 AM EST
End Time: 3:00 PM EST
Chairs present
Ed Lewis
Jaap Akkerhuis
Minutes
Thanks to our scribe, Paul George.
Agenda review
- requests to add items to agenda
* nameservers as objects
* namespaces
* alternate transport strategies
* BEEP
* Security - authentication/PGP
State of the WG
- Neustar's proposal side note
- Slide: WG Documents
- Slide: WG vs Milestones
Begin Requirements Discussion
Handle Issues
- ability to reference objects in other registries, specifically: Contacts
- move to a more general approach
- a global namespace for object storage for each registry
- privacy issues were brought up.
- Decided that there is no reason NOT to use it (But shouldn't be in this protocol - only the ability to do it should be in the protocol)
- Still an open issue
Transport Issues (BEEP, parsing at client)
- statement made that transport alternatives are needed to improve efficiency
- suggestion made to specify that transport is a separate issue
(agreement that it already is).
- BEEP Protocol (short background)
* Performance issues were brought up.
* Suggestion to possibly move the transport, authentication and security out of the protocol to simplify it.
* Noted: the need to discuss the needs of domain lookups vs all other activities.
* Decided that this is not critical for Requirements Document
* Decision to move this discussion to the mailing list.
Data Collection Issues
- data flows defined as technical vs social.
- Identification of 4 data flow/collection properties:
* Purpose
* Recipients
* Retention
* Access
- Issue: who announces their data collection policy and how do they announce it (How to communicate data flow/collection policies)
- It was brought up that this is distinct from security
- Was suggested that this need arises when there are too many relationships to track "out-of-band"
- Decision to continue discussion on mailing list
- Agreement that there should be a data collection section in the requirements doc for the protocol
Security Issues
- Discussion of the use of PGP certs for accessing data
- Ability for the protocol to provide other solutions (from registries and registrars)
- The need to id a request by the Registrant all the way to the Registry
- The need to provide a second (or multiple) access points.
- Agreement to change "Authentication ID" to "Authentication Info"
- Discussion of the types of Contacts
* Note that "billing", "tech" and "Admin" are considered placeholders for the time being.
Lunch
NameServers as objects
- nameserver roles:
1 - attributes of domains
2 - object in their own right
- object would give the ability to lookup data with a handle at the registry and protocol level.
- Consensus that NameServers should be represented as objects in the protocol.
I18N
- discussion about whether or not we should reference either UTF8,
1646,or 2277 as a requirement in the protocol
- note that 2277 was already referenced
- Decided that this was good enough.
Neustar XRP Proposal
- Note that this document should be considered Neustar's view of the RRP
- Recognition that it is very similar to Hollenbeck's draft and noted differences:
* Uses BEEP explicitly
- Neustar does not consider this to be in competition with Scott's draft
- Recognized the need to further ID differences between the two documents
- Comments on XRP
* Uses IP objects for notification of possible intellectual property violations
- Remain discussion centered around the PRESALES query and the fact that it represents 80-90% of all traffic load on a Registry's servers.
* Possibly isolate the presale process into a different protocol
* Discussion of if the presale process belongs in the protocol
- Check commands could be moved to another box (implementation problem)
* A note about making the check command contain optional authentication, which then was noted: optional auth results in optionally robust data
* Discussion about the point of separating the functionality between two protocols
* Discussion about using BEEP (for short time to market considerations)
- It was decided that a separate protocol is not yet necessary and that this protocol should try to make the presales lookup as lightweight as possible in the current protocol.
* Assuming that the check domain functionality is actually a check object.
Design Teams
- expected outcome of design teams
* an in-depth study as to what needs to be included in the protocol spec.
* Concentrates on part of the draft -or- design protocol while evaluating candidate protocols
- Noted the need for multiple design teams
* 1st team looking at the base protocol
* 2nd team looking at the transport mechanisms/issues
* 3rd team looking at security
- recognition of the need for multiple transport mechanisms because of email
- Note that April is still the deadline for the initial requirements spec
- Design teams work all through March
- Deadline - end of week (Feb 23) for design team formation (5-7 people)
- Note to make the next IETF meeting the deadline for the first deliverable:
* 1st deliverable: Issues and trade-offs w/ possible strategy suggestions from each team.
Email addresses used as unique identifier
- decided that it was not a good thing for now
- Discussion moved to mailing list
Discussion : Security - transport security vs. information security
- Security Design team should:
* List threats
* Suggest how to handle them
* Perhaps categorize the threats and determine which of the two other teams should address the threat.
Discussion of IETF RFC creation process
Discussion of an Implementors Group to discuss design/protocol implementation issues
Discussion of time-to-market for new registries
Discussion of group collusion issues/problems
Discussion of consummating the collution effort
- Having a "commercial Implmentors consortium
- Interoperability testing
- Load testing
- Rich Shockey volunteered to start Implementors group
* Email to rich.shockey@neustar.com to join mailing list
The list is at pri@ar.com, PRI stands from ProvReg Implementors.
Alot of folks have already subscribed. To subscribe send a message with the word "Subscribe" (without the quotes) to pri-request@ar.com
Scott said he will submit a new provreg 00 soon.
Attendees: Jaap Akkerhuis, Dave Crocker, Richaerd Shockey, Jorg Bauer, Sheer El-Showk, Ayesha Damaraju, Ning Zhang, David Taylor, Michael J. O'Neill, Ginny Listman, Cathy Murphy, Jasdip Singh, Andrew Newton, Francisco Arias, Cristobal Chapital, Bruce Miner, Rick Wesson, Christopher Ambler, Groerge Belotsky, Jordyn A. Buchanan, Scott Hollenbeck, Paul George, Chris Bason, Eric Brunner-Williams, Ross Wm. Rader, Ed Lewis (in order on the blue sheet).
Protocol Design Team Report
Initial Report of Transport Design Team