Last Modified: 2003-02-03
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 | |
| 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 |
| RFC | Status | Title |
|---|---|---|
| RFC3375 | I | Generic Registry-Registrar Protocol Requirements |
Overhead slides and jabber log for provreg meeting, IETF 56 in San Francisco, 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 group. (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: http://www.cafax.se/ietf-provreg/mailli st/2003-03/msg00067.html 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 (Informational) 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. Problem: We have a way for registry to tell registrar about privacy for a session 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 anyway? Tough question: why engineer to legal requirements? (Unlike way back when - IPsec.) (This is a rat hole, but what's the justification?) 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 reference. 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 stall. 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 http:/www.cafax.se/ietf-provreg /maillist/2003-03/msg00067.html 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 interest. 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 handle. ed: we will have a better chance of doing our job with we have better focus 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 registry 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 ICANN 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 changes 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 (mechanisms). 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 contact 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 guidelines ed: have process question ed: we don't have the smarts to design the protocol with legal knowledge 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 extensions 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 requirement 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 sentences 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 extension 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 statement 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 contacts 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 everything 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 discussion suzanne: we will implement what registries want ed: I've heard this complaint from openReg. Would like the list of open steps. 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 differently. 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 problems 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 extensions 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 out. 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 consensus. ed: ok, that would provide more context ed: action item 2: look at the old approach and ask if it is acceptable 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 |