2.1.11 Provisioning Registry Protocol (provreg)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-03

Jaap Akkerhuis <jaap@sidn.nl>
Edward Lewis <edlewis@arin.net>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.com>
Mailing Lists:
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/
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
Done  Decision on whether to drop containers
Done  Second draft of Containers
Done  Second draft of EPP over BEEP
Done  Decision on need for a EPP Guidelines draft
Done  First draft of EPP Extensions Guidelines draft
DEC 02  First draft of EPP over SMTP
JAN 03  Schedule interoperabilty test
  • - draft-ietf-provreg-epp-08.txt
  • - draft-ietf-provreg-epp-contact-06.txt
  • - draft-ietf-provreg-epp-domain-06.txt
  • - draft-ietf-provreg-epp-host-06.txt
  • - draft-ietf-provreg-epp-tcp-06.txt
  • - draft-ietf-provreg-epp-ext-00.txt
  • Request For Comments:
    RFC3375 I Generic Registry-Registrar Protocol Requirements

    Current Meeting Report

    Overhead slides and jabber log for provreg meeting, IETF 56 in San 
    California, US, March 2003.  (Note that these notes were not passed 
    before the group before submission.  Apologies to speakers for 
    misrecording of statements.)
    Provisioning Registry Protocol (provreg)
    0. Scribe: Kim Davies - thanks
       Jabber: Andrew Newton - thanks
    1. Agenda Bashing - few minutes
    2. State of the Group (where the docs are) - few minutes
    3. Privacy "bull" session - until exhaustion
    4. Extensions Document - few minutes
    5. Host Objects - few minutes
    6. Other obstacles to Proposed Standard - few minutes
    Abstract: Group is struggling with one remaining issue.
    When (if) we get resolution, only one document remains in the WG.
    Proposed future - just solve this one problem, get to Prop Std on base 
    specs, and to Informational on remaining document and shutdown this 
    (New group when needed to advance to Draft Std.)
    Core Documents (proposed standard):
      Extensible Provisioning Protocol
      Extensible Provisioning Protocol Contact Mapping
      Extensible Provisioning Protocol Domain Name Mapping
      Extensible Provisioning Protocol Host Mapping
      Extensible Provisioning Protocol Transport Over TCP
    Answers to IESG comments:
    Remaining Document (informational):
      Guidelines for Extending the Extensible Provisioning Protocol
    Other documents:
      Individual submissions exist, not WG candidates now
      Nothing is stopping experimentation
      Why are docs being discouraged?  Track record is that no document has 
    gathered general interest in some time.
    Milestones (mail list, not on charter page):
    MAR 03 Respond to the IESG Comments (for Proposed)
    MAR 03 Submit Guidelines for Extending the EPP to IESG 
    propose ---> APR 03
    APR 03 Decision on Alternate Transports
    Likely to drop these:
    SEP 03 Perform Interoperability Tests
    OCT 03 Submit Interoperability Report to IESG (Informational)
    OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft)
    OCT 03 Submit EPP Contact Mapping to IESG (Draft)
    OCT 03 Submit EPP Domain Name Mapping to IESG (Draft)
    OCT 03 Submit EPP Host Mapping to IESG (Draft)
    OCT 03 Submit EPP Transport Over TCP to IESG (Draft)
    Abstract: DISCUSS a compromise to the problem, PROPOSE this on the list.
         We have a way for registry to tell registrar about privacy for a 
         We don't have a way for a registrar to tell registry about privacy 
    concerns for pieces of data.
         IESG comment:
         > why do domain/contact/.. not have granular information about
         > privacy?
         So - we need to address domain and contact mapping (at least)
    Questions to IESG:
         We don't have the privacy draft from Blaze, et.al., yet - will it hold 
    up our documents?  I.e., should we be rushing if it will stall us 
         Tough question: why engineer to legal requirements?  (Unlike way back 
    when - IPsec.)  (This is a rat hole, but what's the 
    Questions for all:
         What's wrong with "dnd"?  Do Not Disclose to anyone in anyway, other 
    than to sponsoring registrar.  "Existence of domain name?"
         What happens if the registry is legally coerced to disclose anyway?
    no slides
    Abstract: Murmurs in the hall: Folks not happy with host objects.
    Complaint: EPP requires a series of actions by reg'r if reg'y does not 
    maintain hosts.
    Proposal: alter Domain Mapping to let name servers be added instead of 
    Rebuttal: ?
    Abstract: A few issues flare up
    Discussion has not been sustained until closure
    Fine, I can understand frustration w/slow process
    But - now we are potentially to success - last time to speak
    Jabber log of meeting...
    Logs for provreg@conference.ietf.jabber.com
    ed: agenda bashing
    agenda 0 - Scribe Kim Davies Jabber Andrew Newton
    agenda 1 - agenda basing - few minutes
    agenda 2 - state of the group (where the docs are) - few minutes
    agenda 3 - privacy "bull' session - until exhaustion
    agenda 4 - extension document - few minutes
    agenda 5 - host objects - few minutes
    agenda 6 - other obstacles to proposed standard - few minutes
    no objects to the agenda
    ed: state of the group
    ed: group has been stalled since Atlanta. One doc left in WG after this 
    ed: discussing EPP documents
    ed: proposed future - just solve this one problem, get to proposed std on 
    base specs, and to informational on remaining docs and shutdown group
    ed: IESG comments 
    ed: remaining doc is Extensions doc - to be informational
    ed: other docs - individual submissions exist, not WG candidates now.  
    Nothing stops experimentation. Track record is that no doc has gathered 
    ed: onto milestones
    ed: mar 03 - respond to iesg - submit guidelines to extending epp
    ed: apr 03 - decision on alternate transports
    ed: likely to drop other milestones for going to draft standard
    rick: it doesn't seem like we have no interest in doing extensions
    ed: there doesn't seem interest in doing extensions
    rick: there are no milestones for it. you are not allowing those 
    questions to be asked
    ed: yes, the track record so far as not been good
    ed: why would the WG spend time discussing just one person's concerns? (In 
    the sense that only one person cared.)
    jaap: we have no seen drafts too
    scott: my drafts are not of interest to this WG but to other WG's.
    jaap: said something about extensions (i didn't get it)
    rick: you can make us not talk about it
    ed: not trying to squelch extensions, but nothing has come in for us to 
    ed: we will have a better chance of doing our job with we have better 
    ed: we don't have a history of doing this
    rick: only way an ext. gets documented is via individual submission?
    ed: yes
    andy: if it is info, can you just got to the rfc editor
    ed: depends on whether iesg says it needs wg review
    ed: we are not trying to stop experimentation, but we have not had a 
    successful history of handling extensions.
    jk: are you addressing i18n issues or are you assuming idna.
    scott: what are the issues?
    jk: is everything strictly idna and there are no i18n issues, or do you 
    need to know character sets and other standard issues.
    scott: we do the first case now.
    scott: if it can be pointed out that the other cases need to be 
    addressed, they would be candidates for an extension.
    ed: time frame of two months
    now on to privacy
    ted: addressing privacy brought up by randy bush
    ed: pulling up scott's message regarding issues with iesg
    ted: the one remaining issue is the privacy issue raised by randy bush
    scott: #8
    ted: describing registry/registrar/registrant use case
    ted: dcp tells the registrar from registry about privacy
    ted: if registrant has privacy parameters, the registrar checks against the 
    registry and rejects the registration
    ted: in this model, the registrar is handling the intersection between the 
    registrant and registry
    ted: what randy has asked for is a case where the registry handles this.
    ted: in this case, randy wants a mechanism where this is possible.
    ted: mechanism allows registrar to give registrants parameters to 
    ted: randy wants it at the per element granularity on social data
    ted: didn't need to imply the syntax, just semantics (attributes per 
    element vs. blob)
    ted: is that unclear
    richard: everybody wants to do something likes this, but it is too 
    complicated requiring rewrite of contracts between registries and 
    registrars and ICANN.
    richard: this is a protocol burden that may not be legally possible
    ted: if their current agreement doesn't cover this, it does not need to be 
    turned on.
    ted: are you saying that just having this will cause something
    ted: this is not a silly state item, you do one or the other.
    richard: it is about implied contracts
    ted: not dnp and other mechanism
    ed: we are being asked to make the protocol general enough for this
    randy: mandatory to implement, not to use
    ricK: if this were used to today, it would violate our contracts with 
    randy: that is your contract problem
    ricK: it should not be mandatory to use
    richard: we are trying to do the right thing, but there are practical 
    issues here.
    richard: if a registry sends to a registrar these flags and the 
    registry ignores that, it is a problem
    randy: reject the data
    jk: if ICANN changes the rules, you have to change the contracts.
    jk: reject the registration if you don't agree with the flags.
    jk: the important thing is that the protocol can be used when the policy 
    ed: this is the first time I've heard this argument clear enough to 
    understand the issue
    randy: it could be that the registrar/registry support a policy that the 
    registrar doesn't offer.
    jaap: some registrars may say they will not deal with opt-out policies 
    because it is too much work.
    ted: the critical thing is not to get into using both sets 
    ted: either use dcp and not dnp
    randy: there are many points in the protocol where if there is wrong data it 
    gets thrown away.
    rick: are they mutually exclusive
    ted: is dcp mandatory if dnp is not used
    randy: dcp is aggregated dnp
    ted: you are ok with dcp not being mandatory in the presence of dnp
    randy: no problem
    ed: do not publish?
    randy: blob vs attribute tag, doesn't matter
    ed: per session?
    ed: there are three levels of time interaction here.
    rick: i do not like educated the AD's on these topics and then 
    negotiating it in front of us
    rick: i don't like doing this... the implementors and group members 
    should have a say
    rick: i would like dnp per object not per session
    randy: i don't care
    ed: how does this apply to social data or technical data... host 
    mapping, domain mapping
    rick: privacy is about social information
    ed: just getting clarification
    richard: yes, social info or person id info and nothing else
    randy: or organizational
    richard: same thing
    richard: what is not clear about personal id info
    randy: because it says "person"... need to include "org"
    scott: paf says we can't narrow it down to contact info because that is a 
    policy decision
    randy: i don't find that interesting
    randy: is there a gray area
    scott: not that we can see
    rick: this about ted's comments about silly states
    rick: having dnp on hosts should generate errors
    unknown: what level is the purpose for
    rick: there is no purpose
    randy: don't go there
    randy: just a bit, how it applies to whois or whatever is about culture and 
    george: implement the feature and pursue the social policy issue later
    richard: if the feature is implemented, whether it is used implies 
    behavior in contracts
    richard: this is a legal rat hole
    jaap: law is not enforced by protocol
    ed: are we trying to engineer  to legal requirements
    randy: no
    richard: disagrees
    ed: we have been designing protocols for years without legal 
    ed: have process question
    ed: we don't have the smarts to design the protocol with legal 
    richard: disagrees. we need to understand the protocol implications on the 
    legality of the contracts
    richard: lawyers will sue
    ed: we don't know enough about the law in this room
    rick: i agree with richard, but let's talk about the technical issue
    rick: i like these bits/flags. would like to see proposal
    rick: would like it on a per object basis
    ted: you do not have to wait for the privacy draft from Blaze
    ted: all other issues have been dealt with in the current doc
    ed: was worrying if the blaze draft would have implications about this work
    ted: no
    george: the feeling of the group is that if we don't do this, then the IESG 
    will not pass it on
    richard: if it is mandatory to implement, the lawyers will use it
    rick: what richard is saying is that just because it is there, we will be 
    required to use it.
    rick: we will all have to use it
    randy: not all (referring to ccTLDs)
    rick: but we need to suck it up and do this
    ed: i hear one voice against this
    rick: what is this?
    richard: it is a good idea, I just want options
    ed: does anybody else feel we shouldn't go here
    rick: we have been told to go here
    yan: among technical people on privacy, there is not much support for 
    mandatory to implement. i saw support for dcp per session
    unknown: does it have to be core or extension?
    room: core
    jan: there are a lot of marginal cases... i see no problem marginal cases in 
    ed: what we are looking for is a basic of way doing it... extensions can be 
    used for exotic cases
    ed: this is up for proposed standard, if it turns out that nobody uses it, 
    this feature will go away before draft
    jan: implementors may pay lip service to core features, but will always use 
    their own extensions
    ed: our standardization process also for understanding when the 
    features are not used before going to draft standard
    jk: ignore the iesg policy, the likelihood of law against using this 
    feature is near zero. the likelihood of the opposite is pretty high. 
    therefore having them is the pragmatic option
    richard: extensions
    jk: no, you need it for interoperability purposes
    jk: if you are doing business around the world, you will have to do 
    extensions for each jurisdiction
    jk: this is better for interoperability.
    jk: if extensions are not standardized, it hurts everybody
    richard: want standard core set of extensions
    richard: mandatory to implement but optional to use is probably the best we 
    can do. I object to the way the IESG has forced this on us.
    ted: i want to make sure the room has a common understanding of the 
    technical requirement
    ted: do we agree on a mechanism for a registrar to registry do not 
    publish or do not disclose on a per element basis?
    george: we could do it per session
    ted: registrar tell registry on per element basis which elements are 
    dnp... does not mean syntactically on a per element basis
    jan: this sounds like a particular syntax
    ted: no
    jan: i would like to see a requirement
    ed: we are talking just about moving the enforcement point
    jan: the requirement should say that the registrar should define to 
    registry the privacy policy
    jan: i disagree on this definition of privacy
    ed: for this peace of information, you cannot disclose to anybody else
    jan: but that has different meanings
    ed: we don't want to spend time discussing what do not disclose means
    jan: I want to know the real requirement... this is not a 
    requirement, but a solution
    jan: my impression is that a solution is being proposed as a 
    george: but this might not be sufficient granularity
    ed: I think you misinterpreted what I was saying
    rick: we are not agreeing and have different needs, per object vs per 
    session, registry enforced and registrar enforced. all of these options are 
    valid and we need to find a solution that addresses all for of those.
    ted: i am not trying to suggest a solution but a needed semantic, it is 
    just difficult to do without discussing syntax.
    ted: provide the basic binary functionality
    ted: I agree with jk on going down the extensions path
    ted: asks scott to write a mechanism to do this
    scott: one was already proposed?
    ed: I'd like to send to this list what we have discussed today.
    ed: we also want to define something that is simple.
    rick: I want to leave this room with the technical requirement in a few 
    george: it would be a useful exercise on which elements it does not apply to
    george: per elements mean on the set of elements it would apply to
    jan: yes, and certain elements do not make sense based on the update 
    command and the info command
    unknown: we are not convinced that this cannot be achieved with 
    rick: yes
    ed: procedurally it has problems with getting docs published
    rick: we have been told by the IESG not to do extension
    rick: we don't have a concrete problem statement
    george: what you have on the screen can be made into the problem 
    ed: on prob. statement:
                1- granularity
                2-movement of enforcement
                3-mandatory to implement
                4-data unacceptable to registry
                4-setting method a or b is by receiver
                5 - not accepting data
                6- all data vs identifying info
    rick: per session or per object?
    scott: expresses concern that per session and per object could conflict
    george: describes how he thinks about it for addresses
    scott: what do you define a session
    george: your session is my transaction
    rick: are people backing off the per session issue?
    room: silence
    jan: per request not per session
    rick: i think we agree
    george: per element is only on those elements it would make sense to use on, 
    not all elements in the protocol
    rick: only social, not all
    ed: per object/element/data facet
    ed: do we want to try use an older archive proposal?
    rick: can you solve that problem statement?
    scott: looking in the archives
    scott: pulling up message from archive
    scott: describes blob solution
    george: this would permit distinction between technical and abuse 
    scott: yes
    scott: at what level of granularity do we want
    rick: i'm looking for clarification on how this works
    scott: there was a friendly amendment to it... trying to pull it up
    jan: wants disclose yes/no for an update
    rick: this is for updates
    scott: we need an update for this
    scott: should the info command spit back the dnp preferences
    rick: yes
    scott: yes
    unknown: what about getting back which elements you can disclose
    ed: what would the registry refuse to let you change?
    ed: does dcp do this?
    scott: it doesn't have that granularity
    ed: you want a failure code about not being able to set a dnp
    scott & ed: multiple errors could be dealt with out of band
    scott: agrees with this amendment
    ed: we'll document this in one email
    george: costs to implement should be documented
    jan: I have made an argument for a simple syntax
    jan: registry should have flexibility for default values
    ted: dnd flag should be discussed to be yes for everything or no for 
    ed: we have discussed that before
    ted: it should be done to be all uniform for the default
    edmund: are we only talking about contact. what about domain.
    ed: we are talking about domain and contact
    edmund: domain is important across registries
    edmund: they would use the same contact object
    edmund: is there a per domain proposal for on/off on different elements
    ed: I thought we were talking about any kind of object... no wait, just 
    social data
    scott: that would only be contact info
    ed: this goes back to paf's statement. domain mapping?
    ed: we'll make it clear in the list
    ed: we will go to the list with proposal to see if it is agreed it will 
    solve the IESG request
    ed: on to extensions doc
    ed: the ext doc exists to help people to figure out how to write epp 
    extension documents
    scott: new doc soon
    ed: asks room to review the new doc
    ed: on to host objects
    ed: issues are coming up on the list, but we are not coming to closure on 
    any of them.
    ed: want to know epp is requiring host objects is causing issues with 
    doing registrations?
    ed: asks to see if anybody wants to volunteer info about this 
    suzanne: we will implement what registries want
    ed: I've heard this complaint from openReg. Would like the list of open 
    frederico: what is the real reason for a host object?
    frederico: is it because we need a way to change host names
    scott: it was there originally for historical reason, but some do it 
    scott: there are bulk operations where the object based models makes the 
    process much more efficient... like address and name changes.
    frederico: when you are talking about strictly needed for glue records
    frederico: it could be handled in other parts of the protocol. host 
    object only there for host name changes
    frederico: has some security implications for registries with 
    different models
    frederico: how do you know that the people putting this info in you 
    database are authoritative for it
    frederico: enforcing this in the protocol is keeping a model that causes 
    scott: the issue of authority is addressed in either object or 
    attribute models
    frederico: but we have another mechanism for doing host checks
    scott: why can't you use it?
    scott: accepting the registration has nothing to do of whether it is an 
    object or an attribute
    frederico: it makes more sense to be attributes of the domain
    joeng: we've had this discussion many times. the epp basic protocol and 
    some kind of mappings
    joeng: epp defines an environment to setup new mappings
    joeng: a lot of ccTLD do not fit in the standard mappings and use 
    joeng: you can define your own domain objects
    rick: we made a decision on this.
    rick: there is an issue where a domain can be deleted because of a host 
    underneath it.
    rick: there may be ways to get it to work if we go down this road
    rick: there are trade-offs with both ways
    rick: I think looking at this is reasonable and in scope for the group
    rick: we made a choice, but we are now discovering a number of use cases 
    where it causes issues
    ed: we are now getting a wider range of review, and this is probably why we 
    are seeing this issue now.
    scott: that very proposal was discussed in the past
    rick: but that proposal was either or
    scott: no, it wasn't and the proposal was shot down
    unknown: there has been a move to a uniform model since epp. we use to do 
    non object method, but are now doing it.
    frederico: has anguish over writing extensions for basic operations
    ed: on to other flare up issues
    ed: anyone here want to speak about roid or other issues.
    ed: what about last verified? where did rick go?
    rick: you said it was consensus, but only person said they wanted it that 
    way (last verified as ext.)
    ed: do you have anything to make us change our mind?
    rick: no
    ed: any other topics?
    room: silence
    ed: we are done
    rick: what are the action items?
    ed: take privacy problem to list.
    scott: what is the mechanism to do that?
    ed: I'll send out a summary
    rick: can you simply state the problem in 3/4 sentences so that it sticks 
    ed: showing early discussion point on the projector
    rick: I can help you word-smith it
    ed: the problem and the approach are different things
    ted: you sending both in the same message?
    ed: separate messages.
    ted: it is up to you, but the room seems to want the approach might help gel 
    ed: ok, that would provide more context
    ed: action item 2: look at the old approach and ask if it is 
    ed: action item 3: send it to the IESG
    ed: action item 4: ted buys us beer
    ed: this will go out early next week
    ed: a period of month... well before Vienna.
    scott: what should I do with the 09 version of the core protocol.
    rick: there are registries preparing to come out with 
    implementations of the latest drafts.
    scott: would rather hold of on real -9
    ed: let's talk about that on the list
    scott: but we know it doesn't answer the problems the IESG has
    ed: let's ask it on the list
    rick: I think we know now it will not meet that requirement, so we can say 
    that now.
    ed: you are right.
    ted: you might want to hold off.
    ed: are we done?
    room: leaving


    None received.