Last Modifield: 07/08/2002
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 EPP over BEEP|
|Done||Second draft of Containers|
|JUL 02||First draft of EPP over SMTP|
|JUL 02||Decision on need for a EPP Guidelines draft|
|NOV 02||Schedule interoperabilty test|
Action Items: 1. Respond to the IESG comments. Most of the comments are easily addressed. A few need further discussion (and are listed as separate action items). 2. Come to a final understanding of UDP and EPP. There have been some words posted to the "outlawing" of UDP, one response was to require stream based protocols. 3. Clarify the adoption of P3P concepts. P3P was written for website environments, not a business to business situation. This is reflected in some of our examples and needs to be cleaned up. Rick Wesson volunteered to summarize a discussion on privacy issues. It might be up to us to forge new ground here as we are one of the few protocols that gathers personal information (for registration information). 4. Whether or not we adopt a work item for the SOAP 'as transport' draft. A thread has been started on the list, but the results are luke warm for now. 5. An SMTP mapping is all but dead in the water. Unless someone objects on the mail list, we're dropping all milestones relating to SMTP. 6. Continue to progress on Guidelines. No sense of urgency, at least not until we get #1 above done. Two other action items... 7. Clean up the milestones. After the meeting we talked and decided that the milestones on the web page aren't sufficiently descriptive. Before fixing them, #4 and #5 need answers. 8. Discuss 'lastVerified' - mandatory, extension or optional 9. Discuss handling of external hosts Details on meeting discussion: IETF provreg Working Group ========================== 9.00-11.30 Slot, IETF 55, 19 November 2002 Chairs: Ed Lewis and Jaap Akkerhuis Author: Kim Davies IESG Comments on EPP Drafts --------------------------- Comments by Ed Lewis (EL)/Scott Hollenbeck (SH): 1. Do we place mailing list names and URLs in RFCs? A: Removing that section. 2. Would like a stronger Security Considerations section, Wants it to say that that EPP "MUST NOT be used over a transport mechanism that does not provide confidentiality", or "All transport mappings for EPP..." A: Incorporated. Clear text passwords are used, so privacy is required. 3. What is "authorization token"? A: Changed to "authorization information" to be consistent with rest of document. 4. Does EPP need the login/pass command if it is using TLS authentication? A: Yes, TLS is using machine to machine authentication. user-level authentication gives greater granularity. Some greater explanation is needed. Scott Bradner: 1. More strict about congestion control protocols require an IETF standards track congestion control such as TCP or SCTP. A: Will address this later in response to another comment. Bert: 1. example.tld is not an approved example. A: Was not aware of the convention for example TLDs. They will be changed appropriately. What should be used for IPv6 examples? Patrick Faltstrom: Will ask the IESG for guidance. Randy: 1. Why is there no granular privacy options for domain/contact mappings. A: Raised some discussion. Extensions allow policy to be codified on a case-by-case basis. Needs to be discussed by the WG. Allison: 1. <replacement text for managing congestion> A: <will discuss later> 2. Define "marketing" add a more neutral definition. More explanatory material will be added (from P3P website or similar) 3. How does IESG and the community check XML (as opposed to ABNF or MIB checking) A: Available checkers from W3C etc. PF: IESG may more thoroughly define this in the future, only just implemented requirements on ABNF grammars. 4. Suggest that limiting the number of TCP connections is not a good thing for net services. change MAY establish to SHOULD NOT. A server MAY limit becomes SHOULD limit. 5. Missing TCP reference needs to be added Discussion ---------- SH: Any problems with the suggested replacement text (from Allison Q4) that clients should not establish multiple tcp connections, and the server should limit connections. Rick Wesson (RW): Ignores practices in common place Jon Peterson (JP): ... EL: This is used to address server load, not network load. This also has considerations for both. JP: We might want to recast the sentence to consider that. RW: It would be nice to have the actual language rather than the substitutions. The wording as suggested on screen: An EPP client streams EPP commands to an EPP server on an established TCP connection. A client MAY but SHOULD NOT establish multiple TCP connections to create multiple command exchange channels. A server SHOULD limit a client to a maximum number of TCP connections based on server capabilities and operational load. RW: Seems we are touching up language that ignores that operationally this happens (multiple connections) normally. EL: SHOULD NOT helps convey that it is discouraged, and that implementations shouldn't make this default behaviour. Patrik Falstrom (PF): The definition for SHOULD NOT does not forbid it if there is a justification. RW: It is good to encourage clients not to do it. JP: It contains a provision for clients and servers. If the server limits the number of concurrent connections it will persuade the clients not to. PF: The client should not just open multiple connections without justification. The server can still reject the connections. The important reason for including the wording is that those claiming to the conformant to this RFC will only implement software with concurrent connections only when it is really needed. I.e., Clients should reuse open TCP connections rather than open new connections wherever possible. <no more comments> Transport Comments (congestion and reliability, Allison-1) -------------------------------------------------- EL: This is the suggested wording from Allison. "The transport mapping MUST be onto a transport such as [..] and so forth". The last part is a concern that SMTP runs over TCP, that the SMTP store-and-forward may drop transactions. The first part is that the Layer 4 connections don't impact the network. PF: Also note, the second part, talks about SMTP/BEEP doesn't include any MUST or SHOULDs. This is a reminder for transport mapping authors, that they need to think about these issues and contain some wording on these matters. EL: Any comments on the proposed text? SH: Not advocating this position, but Eric B-W's comment was that his work on UDP transport would be affected by this. PF: I suggest that because Eric brings up this issue, that the WG summarizes the issue that Eric has and pass it back to Allison. You could get Eric to do this. I don't think that the WG should declare rough consensus and ignore Eric's comments without consulting with Allison. RW: When did Eric make this comment? EL: In recent weeks, and I think it was alluded to in the SMTP draft. SH: I think it was right after the IESG comments were sent to the list. Simon ??: Many UDP protocols handle this like RPC implementations that do retries, back-offs etc. It should be in the transport mapping. We shouldn't expect anything more from the transport ADs. JP: I'm surprised by this. Is there some reason for using UDP? Seems to be this is a real long-shot, and needn't go to Allison unless people think it is credible. PF: My feeling in IESG discussions, is that the experience from the Transport ADs, that messages with one round trip (from SIP etc.) but as the protocol grows you implement retransmissions and back-off algorithms, so over and over again people who use UDP fails. RW: I don't feel it is appropriate to do this over UDP. I think that without a draft on this we should just move on. anon: Don't make it completely illegal though, some of the stuff I am doing is very lightweight, where if a connection fails it can just be retried. Other people are doing things with UDP that are illegal. RW: More specific? anon: says discussion is not on-topic for WG EL: BEEP mapping failed because no-one wants to work on it as a group. We have new mappings coming in - do we want to work on those in this group? Does the doc go out prohibiting UDP or just not mentioning UDP? We could just ignore datagram protocols, say something. I don't want to specify how to do this over a datagram. I'm not sure how to approach this - leave it unmentioned? I'll talk with Patrick about that. PF: Summarize the issue. See if people don't want it prohibited to do this kind of mapping, and then start a dialogue with Allison. I don't hear a clear consensus that doing UDP is completely stupid. EL: I think we're done with this item. SH: Are you going to take the action to coordinate this with Allison. EL: Yes, it will go on in the minutes. PF: Try to talk with her here. (see the very end of the minutes for a comment from Allison as relayed by Patrick.) Privacy comments ---------------- EL: The last of the major talking points in the IESG comments involves privacy. Allison had this specific comment regarding marketing purposes. And then Randy's comments on privacy meta-data on a more granular level, down to objects and aspects and so on, rather than the whole session. Where do we want to go with this? SH: Lets begin with a little explanation on how we got here. Since the beginning, the topic of privacy came up 1-2 years ago, and a few folks proposed a strawman proposal on granular privacy tagging - but it never came forward, so we went around in circles. Instead, we punted to the extension mechanism in the protocol now - so specific privacy policies can be implemented with the extension mechanism. So if email addresses are private, an extension could tag the element for this purpose. There isn't a lot of text describing privacy and using extensions to implement this, and we could do this if necessary - but the IESG did not ask for this, it asked for more specific privacy. JP: In a P3P sense, it is clear cut how it is used. But in this B2B context, what does this mean for contacting for marketing purposes? What does it mean? RW: In the context for the P3P sense, it only appears to be applicable for web pages. There doesn't seem to be any way to do this, it is an immature way to address the privacy issue. I don't know if what we have is extensible. I like that approach. Different registries can develop policies. But putting a tag on each and every element seems like a simple way to solve a problem - but as we don't have any operational or policy sense on this, we have no way of knowing if it will work. Rich Shockey (RS): I want to concur with Rick on this. The idea that privacy is associated with objects is a good idea. We dont have a standard to apply to the EPP objects at this stage. Last week in Dulles, VA, the W3C had a workshop on P3P on its applicability outside web pages. They do not have a work plan, or anything associated to present. We could go down this road, but int he absence of any other technology (and I would assume the W3C will take years), as much as I'd like to see something implemented, I don't see how we could practically do it. RW: Privacy is good. Some way of enhancing a registrants, or expressing that privacy, is good. I just want a mechanism that is more flexible and tested. RS: I am in total agreement. This could delay the work by orders of magnitude. EL: There are two types of granularity... Per-item and per-purpose. SH: I was asked if I had any opinions. Personally, I think the protocol addresses this requirement. It allows us to move forward without putting restrictions on how it is defined in the future. The protocol still depends on the extension mechanism to define what private means. The document implies that you must use the extension mechanism. EL: One suggestion was that, and if you see Randy's comment, that the contact details are the ones needed privacy and maybe we only define it for those objects. RW: If we have something that worked for all situations, we would appreciate it if we could just take something and use someone else's work. We may not be qualified to do this kind of work. JP: This is a common refrain, we had the same thoughts in geopriv. We have nothing there, and we don't have anywhere to go. RS: That's funny, because we are looking to geopriv. RW: It doesn't exist - are we the right people to develop it? Should it be in the context of another group? EL: Maybe we are the right place because we are one of the only places dealing with these matters. RS: My personal suggestion would be the WG chairs ask the IESG for clarifications, with the comments we have no technical basis or competency to tackle the issue. EL: I want in the minutes that the P3P, where the documents come from, is a good document, but we're not sure is applicable. RS: I am happy to post the results from the Dulles, Virginia, workshop, they are working on this and cognizant of the limitations it has. There are companies that are looking to do clever things with this. But is there a body of work to apply to provreg and EPP? No. When could we see one? God knows. JP: IESG's comments suggestion seems to only be some tweaks - and that we are on the right track. Maybe we are doing a good job, and we shouldn't decide to change focus and do something else entirely. EL: ... RW: We have not just the registrar-registry model, but we have reseller chains that must express this information and how it applies. It might be somewhat clear in the simple R-R model. I believe there is a whole lot of work to be looked at here. RS: This is a question on how the policy can be passed to 3rd and 4th parties in a chain of trust. To make it perfectly clear, if there was a way to do this in a reasonable or rational way - we need a few proposals on how this could be done without complicating the process too much. I think the extensions proposals are the most reasonable way to do this. EL: I do want to .. I'm not sure if we have to worry about. Right now we are looking at the EPP protocol for R-R. Do we need to look at the EPP protocol from registrar to registrant? Does it need to be addressed now? RW: If you are not talking about privacy, I agree we don't need to address it. EL: Why is it special for privacy? RW: It is the entity that is making the registration, so if you have reseller chains, in a privacy context, there is a lot of liability - countries, laws etc. and it is not at all clear to me how it will work. EL: I think we are done with the IESG comments. We have to discuss UDP, Privacy, etc. so we can't just rubber stamp it. But we have addressed most comments apart from these few things. SH: A request for clarification. Is there going to be a WG response to take back to the IESG? If we ask the IESG for clarification, then we have to rediscuss it here. EL: I think we can have a mailing list discussion over the next 2-4 weeks. SH: I would like to see some kind of position. EL: Some new issues have come up. Passing information up and down. We could sit down and consider types of privacy. RW: I would suggest we enumerate the kinds of things we have looked at. We shouldn't go down the road of defining privacy as it is too much work. EL: Another comments is this doesn't apply as this is B2B. SH: I think the P3P discussion, and privacy, are somewhat separate. EL: I think based on the fact we have these small comments that we only need to make small changes. SH: There is no indication we have got this completely wrong. Who is going to make that happen? Our chairs? EL: Our chairs. RW: I volunteer.. EL: We have two things to think about - UDP and privacy. 2.5 other issues with the base 10m Last-Verified and External Hosts (Presentation attached.) RW: Several weeks ago, a number of groups have an issue with WHOIS. -quality assurance In the context of registrant data.. one being the postal element, on how it can change - not in the db, but in the real world. Such as change of a zip code or reassignment of a street address. PSTN elements change over time too - phone numbers get remapped. It is happening in India at the moment, where the length of numbers are getting changed. In the US, Area codes changes. If we had a registration 10yrs ago in the LA area, and the area code would be remapped and would change. Then the data in our systems isn't being remapped or changed. I advocate a position where we identify the time since a contact acknowledged that they have accurate and correct information. The proposal is for a last-verified-date, since the registrant ack'd the data is accurate. It would be optional in EPP for the contact. Comments? <none> EL: OK. On the mailing list, the last message on this talked about this being optional. Not everyone agreed that all registries. So this is the question i am most interested in. Should it be optional? RW: From the comments i have received it makes the most sense. JP: It doesn't seem to make any sense to make it mandatory. There are all kinds of bad things about it. SH: I agree, it seems appropriate. The last comment was more strong that it should not be in the base, but i agree with RW on this. RS: Ditto. EL: We have documents in from of the IESG and I am not sure if we want to make a change at this stage. RW: The IESG knows about this. External Hosts EL: The other item is the external host, external objects. SH: OK, here is another can of worms that was discussed in great details 1-2 years ago. TO set the stage. We have an issue with repositories being authoritative for objects in other repositories. i.e. Hosts being used as nameservers, being renumbered etc. This causes management issues if the entity that owns the host doesn't sponsor the object in the registry. An alternative proposal was that each client sponsored its own copy of these objects, allowing each client to manage their own. Hopefully there was no restrictions on this, prevents hi-jacking. It allows for bulk updates, you change one objects and it percolates through all objects that are associated. This is something we need to resolve before we move forward. JP: I am not sure about this issue. I can't speak for Hong. SH: Hong's objections were this per-client copy, but instead these sorts of objects are managed by the server. I don't like the owner word, I forget what the arguments against what that were - it seems rational. If we assume no objects belong in the registry if they are not authoritative, we can throw out these objects and make nameservers attributes of the domain objects. This has problems with bulk updates. EL: The fear is that using the same nameserver for a lot of zones, that would mean a lot of changes if I change nameservers. RW: We have to do it one way or the other, and each has consequences. I think we have made a decision and it is a good choice. We have a significant amount of operational experience about this choice. I have not heard significant comment about this apart from Hong. EL: Any other comments on the base specification, outside the IESG and our current discussions? EL: Next on our agenda is a transport mapping on SOAP. Hong is not here so Jon Peterson will present on that. EPP/SOAP -------- (presentation attached) JP: My slide is what i believe are the issues with the draft. Why would you want to implement this? SOAP is more widely deployed, so it may be easier to use a SOAP envelope to talk EPP. You need to define a small amount of persistent session data inside the SOAP header. It is relatively straight forward. There are some issues that were discussed on the list that are unyet resolved. These are error codes, do we want to construct actual transport protocols used by soap, and how does this draft fit with existing deliverables of the provreg charter. Is this charter work? Does the initial charter of provreg consider this appropriate. Is SOAP perceived to be valuable? RW: Is soap an actual transport? It is a layer of indirection. There are a number of bindings defined to another protocols but it is not an L4 transport. Andrew Newton (AN): One of the motivations of using SOAP is that abstracts you from the transport, and you can use any number - but are there any non-TCP transports? JP: I'd be surprised if there isn't. AN: No there isn't one. RW: What is the status of the draft? Informational or Standards Track? If Info. I think this is great. I am a SOAP implementor and I think it sucks. But that is just the state of affairs today. EL: Hong has written this and he would like it as a WG item. That would mean the WG takes over. If we think this is just a cool idea for Hong to work on, that is fine. The charter does say we should look at transport mappings. It is perfectly OK for the group to say yes we love this idea - we could do that - and it could be standards track. I'm not saying that we have 4 people who would love to do this. AN: SOAP is not a transport. Some people see this as a magic answer that would solve all their problems. This has happened with other RPC protocols. Leslie Daigle: If you want to discuss using SOAP, you should come up with architectural reasons for going there. EL: Yes that is an important question.. "Why?" Why are we doing this? JP: Given how minimal the mechanism is, this is something I am here to ask what the WG thinks. EL: We have already thrown out BEEP mapping because no-one else wanted to work on it. There was nothing wrong with the proposal - it was not mature - but its proponents didn't pursue it any further. The problem is we had not consensus there. RW: To answer some of Leslie's question. This is exactly why BEEP didn't work. We didn't have the tools or constituency. Right now, the fastest way to deploy the service (as long as you don't want too many people to use it) is to use SOAP. EL: If we are talking about EPP, we are going to layer requirements on the transport. With SOAP being this general, how can the document address all the transport layers. RW: We should have a set of requirements that the SOAP transport must use. Just like the TLS over TCP. JP: I think Rick is correct with the SOAP approach. We would rely on profiling on constraining you to particular transports. EL: Does this have promise? Might this be an interesting thing? Do we want this in the charter? (yes) EL: Who would implement this? PF: Including specific requirements all the way down the stack to IP - i.e. not just using HTTP. RW: There has been no analysis. EL: If we invite this into the WG we will start working on it. I want to make sure before we do this. Before we do this, I want to see sufficient well-spread interest in this. If only 1 person wants to do this, they can experiment all they want without WG involvement. PF: I agree with your concerns concerning new bindings. Regarding whether the transport binding is part of the charter. I will require a review by the WG or mailing list if the WG doesn't exist. The mailing list can not go away if the WG dies. I hope the WG winds up within 6 months. You will still do the review, it doesn't need to be in the charter. Milestones/Deliverables need to change. RS: The document can independently proceed, and the IESG reviews it? PF: Exactly. It wont be stopped by the WG if it is not in the deliverables. The WG/ML will still need to review it. EL: The IETF will not get in the way of this. I'm not saying that we are going to kill this by not putting it in the WG. What I am after is how many people are willing to commit time and resources that would indicate it should be a WG item? RW: If you're looking for low hanging fruit for a second transport implementation, this is it. For me to implement this would take all of a day. It is just not a big deal. JP: Just one thing about that - i think it is a reasonable barrier to entry to insist on finding a few implementors to make it a WG item. I think this is the wrong forum to ask this question. EL: This will go to the mailing list. PF: One thing, BTW, I take the constraint of transport protocols as an action item. JP: I definitely think it should not be characterized as a L4 protocol. EL: The other item on the agenda, is the SMTP draft. This is an case of why my (as chair) skepticism towards new documents has been rising over the years. People have said they are all for an SMTP transport, with 3-4 volunteers. Finally someone wrote a document. Further discussion has not happened as the author is unavailable at this time. SMTP is something people have liked over time. Are there people who would like to implement SMTP transport? OK, No hands showing here. This will go back to the ML, but it could be we don't pursue this. Anyone think this is a great loss? No. Ok. We may ask to remove a milestone. We only have that and one other milestone. EL: Next item on the agenda is the only other WG document we have, that Scott has, the guidelines for extending EPP. I would like to see this document mature very quickly. (Side note: We also need to discuss the milestones, some have been done and subsequently dropped.) SH: This doc was first published a few months ago, as a result of some screwy ways of extending the protocol in some independent documents. The only comments I have received is from Ed, there has been very little discussion otherwise. I wanted some WG discussion before implementing those comments. RW: This is the part where we talk about other docs? EL: I'd like to talk about the guidelines first? EL: The intent here is to give people a leg-up on extending EPP. The idea came up about a year ago. How many people are implementors in this room? OK, so it is the minority here. So in this case it is best discussed on this list. EL: Ok, other documents. RW: I wanted to find out if there was interest in writing a BCP for domain registries over EPP. Is this a good idea? It would be an individual submission. It doesn't have to be a WG item. ... Sounds like a resounding no. EL: Yeah I think it is not a WG item, but that doesn't stop you. EL: Next item is discussion on the future of the WG. It seems to me there are some things still to work on. The IESG comments will require a little bit of work, the SOAP is a consideration with more than 1 implementor in the room will want to take a look at, and we'll ask for input from the ML. That could wind up as another item. It sounds like SMTP will be tabled indefinitely or killed, not for the lack of interest but no need to implement/interoperate. So, the extensions guidelines draft which shouldn't be controversial, the IESG comments, and the SOAP draft - and I think that is pretty much it. If there isn't anything else, we can close the meeting. I would like to get copies of the slides. PF: Wait - I was just looking for Allison. I asked her about UDP. Her experience has shown those using UDP do broken thing, so they want to ban UDP. So that is the message back from Allison. So you need to make some kind of statement and engage in discussion with the transport. EL: I might make a post to the ML that we will outlaw UDP, and see what kind of flames we get. PF: I think we will also have a discussion within the IESG, if this kind of requirement exists there needs to be some kind of statement. EL: OK, so I think we're done. Meeting Ends