WEIRDS BoF 2012-03-27 Paris, France Chairs: Murray Kucherawy, Andrew Sullivan Minutes: Kim Davies Summary of Issue ================ - WHOIS isn't good enough any more, various problems that haven't been addressed for a long time. People want change, hasn't happened so far. CRISP working group developed IRIS, but has had sparse adoption. - Recently, ARIN and RIPE NCC deliver content over RESTful web services, payloads in text, HTML, XML, JSON that can use UTF-8. Has numerous advantages, open source, robust, extensible, authentication, etc. - Almost all RIRs have deployed prototype services. - First BoF held in Taipei, skepticism from those in the room - who will use it, why will it work when CRISP didn't, will ICANN make anyone use it. Name registries/registrars have little incentive to provide the service (cost, privacy concerns) - Several big name registrars have stepped forward since Taipei, charter has been revised. - Four questions: 1. Is there still consensus that there's a problem to be solved? 2. Is there still consensus that we have stated the problem clearly and correctly? 3. Given the number and size of the name registered that have signed up to help work on the protocol, are people still concerned about the ordering? 4. Are there any unaddressed concerns with the charter? Is there still consensus there is a problem to be solved? ========================================================= - No-one raised any objections. Is there still consensus that we have stated the problem clearly and correctly? =============================================================================== - No-one raised any objections. Is there still concerns about the ordering? =========================================== - John Levine: The work on the numbers side is quite far advanced, the remaining issues are minor technical issues. On the domain side, there is no prototype, no consensus on the more complicated data model and privacy issues. Would be great to move forward with the numbers work, allow the names work to work in parallel. Example is contacts, RIRs mostly agree on what attributes a contact object has, but for domains it is less clear. Want both to go ahead, but numbers work shouldn't wait on domains work. - Peter Koch: Agree with much of John's comments. Numbers of actors on numbers side is a handful. Have doubts about deployability of a solution for the names part. Lots of discussion of XML vs JSON, and discussion about why IRIS failed - but don't buy the reasons. There were policy disincentives, lack of policy incentives and business incentives, that led to failure of IRIS. Not sure the change of technology will address the policy issues. Those who support this work are appreciated, but haven't seen much commitment to deploy it. Don't normally ask commitments to deploy before protocol is developed, but in this particular case we have a precedent with IRIS. The precedent suggests the be careful about the non-technical issues. - Andrew: Is there a difference between BEEP, which didn't have any significant deployments, and REST, which has widespread deployment? - Peter: Probably. BEEP was probably a "political" choice, the technology du jour; that's different for REST. - Jim Galvin: Work for a operator for 17 TLDs. Agree with John. Regarding ordering, the charter should put numbers and names on an even basis. Then it becomes a management problem as to which order they are done and how the work progresses. Don't mind if the numbers progresses faster. But don't want names, by definition, to be set aside. Regarding Peter's comment, we are going to do something regarding directory service for name registries. Look at internationalisation, at a base line that means you need to do something, and do something soon. With a bunch of new TLDs to be launched next year, something needs to happen. Will this be the technology that will win? It is the best game in town. It is important to separate policy and technology issues. Privacy is a policy issue. With the questions on who implements this, if this is the best option available, we will see. This group won't solve the policy issues, they will be solved in other places. - Pete Resnick: Regarding second class citizen issue: Would you have objection to charter being explicit about this? Is it problematic that names and numbers are explicitly unlinked? - Jim: No, WGs do it all the time. They have a list of tasks to implement, and the change priorities all the time. - Pete: What I'm hearing though is that they need to be the same solution, the same protocol, therefore they have to be the same thing. Need to find a way to make the separable if management decides that is what needs to happen. - Jim: Don't think they need to be the same, but there is an opportunity to be the same. If they separate down the road, that's fine. - Murray: Some of that is the WHOIS protocol shared port 43 for the two different purposes. - Steve Sheng: Agreed with what Jim said. It is important to separate technical and policy, so when protocol is designed it should enable policy and not dictate policy. In response to Peter, one of the big pushes from our perspective, in 2009 started the Internationalised Registration Data Working Group. In that WG, a consensus is emerging that the WHOIS protocol doesn't support it. That is an important driver. - Warren Kumari: Lots of sensitivity on the deployment side, folks are unwilling to state they will deploy it. I don't currently represent a name registry, and we are fully planning to support this work in the future when we are a name registry. - John Klensin: I think there is a problem. The problem is clearly enough stated for charter purposes. Some name registrars want work done, but have seen organisations tell the IETF to work on it, and not do anything, ... Agree with John and Peter. Don't have an adequate case for doing names now. - Jim: John meant registries? - Andrew: For the ICANN model, it is both right? For COM and NET you need registries and registrars. - Ed Lewis: Used to work for an RIR, and now work for a name registry. I dont see the difference between names and numbers. They are the same thing, objects that describe who owns a "thing". The job is to explain who owns what. Don't see a problem. Regarding IRIS; stop comparing it to that. It's gone. Its good we built IRIS as it will help us not develop that again. Privacy issues: law enforcement versus zip code availability for IP addresses. - Jeff Hodges: Need names and numbers for our anti-abuse efforts (at Paypal), need it all, and need it bad. - Scott Hollenbeck: Answering Pete's question. Like Jim, would like to see bits of this done in the same way. Some level of infrastructure makes sense it be done the same way. HTTP error codes for example. Don't want to see a policy debate, or non-technical debate, drag the whole effort to a complete standstill. Happy to support separability, if required, in the charter. Regarding commitments to deployment, some of us work in a contractual model that prohibits the deployment of new "registry services" without going through a lengthy authorisation services. However, willing to commit to developing prototypes. - Frederico Neves: Been on names and numbers side, and there is no difference. The social data is the same. Pretty easy to deploy servers and clients for REST. In the CRISP era we found it difficult to deploy as there were not clients at that time. You had to make a full implementation of the transport, and that was really difficult. Also had the option of LDAP at that time, and was put on the side by the WG, and we picked the BEEP transport. In the end, developed another transport protocol, XPC. As Ed said, that's history - already gone. We wrote extensions to EPP to provision numbers, which shows they are the same. Both databases, despite their different backend infrastructures, can have information protocols based on a single technology like EPP or WEIRDS. - Wendy Selzer: Welcome technical work that can leave hooks for the policy process, but not engage in the policy debate. Don't say whether fields need to be filled, but provide them. - Byron Ellacott: Have worked on names and numbers. There is no real difference between the two. - Andrew: SSAC at ICANN published a report, that one of the problems with WHOIS is the protocol sucks. There is now a roadmap up for public comment, and part of the roadmap was "replace the protocol". For people who object that ICANN can't do this because of the problems, does that change your view on this? If it does, that may change the way you feel about names. - John Levine: They [names and numbers] are not the same. Part of the goal here is to retrieve data of a particular type with a known schema, so I can find the fields I'm looking for. With my 2500 line WHOIS scraper that gets me a quarter of the registrars. The current lack of standardisation is egregious. A great deal of the work is in defining a schema that the relevant servers and clients are interoperable. Maybe that needs to go in the charter if that is not obvious. - Shane Kerr: I worked on CRISP, RIR space. Agree with Peter, earlier attempts have failed because the economic interests are not aligned. Those that gain value from the data aren't those that publish it. If the incentives get fixed due to political will at ICANN, then it would be nice to have a protocol in our pocket for when that happens. We'll never really fix the problem because there are a few hundred ccTLDs that may or may not implement this. Some TLDs also delegate responsibility to registrars to share this data. Don't object to going forward with a WHOIS replacement protocol, but it won't solve anything unless the political will occurs. - Francisco Arias: Expanding on what is happening on the policy side. There is a roadmap. The way the process is envisioned is it will be ready to action by end of June. It was started by the security and stability committee, a technical committee within ICANN. The roadmap proposes 3 ways to do it. For the contracted parties (gTLD registries/registrars), once there is a renewal for them, we will negotiate with them to have this included. Then there is an all-inclusive approach, a policy requirement for universal deployment. Thirdly, to work on promoting adoption, which is the only option available for ccTLDs. For gTLDs, we think there is a contractual option that will be a tool to make this happen and could be available as early as June. - John Klensin: Both registrars and registries have stood up in ICANN "would love to do this, but can't do it as an additional service, but it would put us at a competitive disadvantage unless ICANN mandated it. It isn't wise that the IETF develop another service on the wish it go forward. IRIS: the various options in IRIS is one of the reasons it failed. ICANN responded with paralysis." - Peter Koch: I can agree that names and numbers are kinda the same thing at a 50,000ft level. These communities are distinctly different, have heard of WHOIS failure. Never really heard of this in the RIR community. Their policies are developed distinctly from ICANN policies. In response to Scott, there is a Registry Services Evaluation Process (at ICANN), that may or may not be mandatory for adding these services. Some registries have labs. Some registries aren't subject to ICANN's contractual requirements, and they aren't deploying IRIS either. So contracts may have been a hurdle, but it is not the dominant obstacle. - Andrew: For IRIS, you needed a client. What do you think the difference is in this case by using HTTP, because everyone has a client? - Peter: Don't think it will make a differences, because there will be gateways that do rate limiting, captcha etc. that sits in the middle. - Andrew: Presumably it is the larger consumers that use Port 43. - Peter: We've had discussions about who is the target audience of this in the past, and failed. In RFC 3737 (requirements doc for IRIS), may not choose BEEP this time and use REST. Maybe we adopt the data model from 3737, and just change the transport to HTTP. Will that work? I need to understand where the confidence comes from that the same set of requirements will result in a completely different result. - Pete: Is the severability clause enough to allay concerns? - Peter: I would say yes, if it is Andrew's draft language. - Jeff: The registrars already maintain the data, its about publishing the data. We need to get the data model. - Murray: With ccTLDs, they dont need to do this at all. It is companies like yours and ours that may compel ccTLDs to deploy it. - Jeff: People are lobbying in ICANN to get a mandate for the gTLDs. - Warren: In the ICANN Applicant Guidebook, "After requirements are developed, applicants will be required to deploy internationalised WHOIS" - Andy Newton: Surprised to hear too many knobs is the issue, some are asking for more knobs. In IRIS, you need to parse the IRIS URI scheme, do a DDDS query, and only then do a XPC/BEEP query. There was complexity. At ARIN, the REST service didn't involve a single client. People started using it straight away. - Shane Kerr: All that argues is "if you build it, they will come". I'd argue the opposite, if registries provided the data in any structured way, IRIS or whatever, people would use it. It doesn't have to be RESTful. - Francisco Arias: There are some ccTLDs here. For new gTLDs, there is a specific note in the Applicant Guidebook, "Applicant's can offer RESTful WHOIS ... " There is already a possible way for new gTLD applicants to offer RESTful WHOIS at this time. - Warren: And I will be doing that. - Jaap Akkerhuis: Haven't learned lessons. IRIS separated data from protocol. SSAC reports say stop mixing data and protocol. We're still at square one. Why don't we just give up? Proposed Charters ================= * http://www.ietf.org/mail-archive/web/weirds/current/msg00476.html (Summary of proposals) * http://www.ietf.org/mail-archive/web/weirds/current/msg00833.html (Andy Newton's draft) - Andrew: Is there anyone who objects to Andy's most recent text? - Pete: From my perspective, would look specific reference to severability in the charter. Can allow it to be a management issue, but inclined to make it explicit. [Some questions from the AD:] - Does Andy's text need more text for severability? [A few hands] - ... The first proposal has too much of that? [More hands] - ... Too little of that in the first? [None] - (... Maybe we can split the difference somewhere. Severability of the data model is not an issue at all. In the Jabber room there is concerns about the severability of the base REST protocol. My feeling is it wouldn't ever be splittable.) - ... Does anyone thing it is doomed? [A couple.] - Ray Bellis: Are those people who think this is dead in the water producers or consumers? - Warren: We wouldn't want to publish it in a RESTful way. Whether or not that work can be accomplished in a WG, that remains to be seen. - Pete: I hear another charter revision. Suggest taking the last charter and adding to it; one of the BOF chairs should solicit text on the list. - Andrei Robachevsky: On separability, maybe don't need an elaborate text, but in the charter there could be a milestone for a requirements document. If the requirements call for the same thing, they can be done together. - Andy: Don't like that idea, because if you have two requirements documents then you are starting down the path of having two protocols. - Pete: Would be OK if the design of a requirements document to have separate requirements for the two domains, rather than having two documents that are developed in parallel. - Andrew: Also suggests both groups have to wait for both requirements documents. - John Levine: It seems to me what names and numbers have in common is not much beyond what REST already provides. Since we seem to assume REST is where we want to go, don't see much more commonality being relevant. - Pete: From the Jabber room [no name called out], in writing the requirements is where we learn if there are separate requirements. - Andy: The current requirements do not have anything wouldn't apply to names and not to numbers. Current trajectory of the document, there isn't a split between what the names and numbers people want. We don't want the operational stuff in a protocol requirements document. - Murray: Sounds like its worth the exercise, equal parts of people saying its the same, and those saying developing requirements will identify if they are the same. - Andrew: Is this the only thing standing in our way of chartering this WG? This is our second BOF, and the last kick of the can if we can't come to agreement. - Barry Leiba: Chartering the work and getting it done are two different things. For chartering, we are close. - Pete: Havent heard issues in the IESG suggesting this would be a problem if the charter is clean. Meeting concluded.