Int'l Registration Info (WHOIS Data) Wednesday, 28 October 2009 ICANN Meeting Seoul, Korea >>DAVE PISCITELLO: I think it's about time that we can get started. The music fades. My name is Dave Piscitello. I'm the senior security technologist at ICANN, and this session is on display and usage of internationalized registration data. The session will actually have two parts. The first part is on my shoulders, and I'm going to set the stage for the working group that we are proposing to convene here today, and to continue to convene through the normal teleconference and e-mail participation, so that we can accommodate people from all over the globe in our process. Once I've finished my presentation, Bruce Tonkin is going to moderate a question-and-answer session where we really do want to get some of your input, some of your ideas, and some insight into how we might shape and move forward with the task at hand. All right. Let's begin. I have stated this problem space many times before. I'll try to do so again. Increasingly people who use the Internet are becoming accustomed to using their -- the characters from their local languages and scripts as a way to not only input but display Web pages, electronic mail, and any other applications that they are becoming accustomed to using on the Internet. WHOIS is an Internet application. Therefore, WHOIS must accommodate that same global audience, or at least the global audience that uses WHOIS on a regular basis. I want to make certain, at the outset, that people understand that the issue that we're talking about here today is distinct from IDN TLDs. In particular, registration data are distinct from internationalized domain names. The IDN standards and guidelines define how domains are composed and displayed. WHOIS developers application and Web developers apply this for the submission and display of the names. Beyond the domain names, when you look at WHOIS, there's a considerable amount of information that one can obtain. One can obtain the sponsoring registrar, the contact information for the technical administrative contacts of the person who -- or the organization who has registered the domain name. These are the data that we're talking about. The user experience in the field, when using WHOIS, is slowly changing. Whereas 15 years ago the average access to WHOIS would probably return entirely U.S. ASCII 7 responses and submission using most client applications would have been using characters from the ASCII 7 set, today people are beginning to use more and more local languages and scripts. So in the context of domain names, one of the things we'll see is that there is an evolution from people not only submitting ASCII labels, but also submitting Unicode labels to query the WHOIS. And they're doing so over Port 43, which is the port for command line WHOIS applications, as well as input to Web-based WHOIS applications. You'll find that many operators might display the domain names and labels either in the A-label encoding or in characters from the local script used by the registrant. This is -- actually it is somewhat hard to read, but the purpose of putting this display up is to illustrate an example from JPRS where, by manipulating a flag in the WHOIS client application, you can see the U-label encoding of the domain name as well as the IDN encoding of the domain name. Here's yet another example. And we've just covered mostly the information relating to a domain name. Now let's think about the information relating to the contact information or the sponsoring registrar or the domain name server names that one might use, and those are the bits of information that we're referring to when we say "registration data." Here again, just as in the case of going to a Web page, the recognizable display of that data is application-dependent. So the display is going to be affected by a number of things, including the character sets available to the WHOIS clients and browsers. The character sets that are installed in the font sets on the particular computer system -- laptop or desktop -- that you are using when you use a WHOIS application. Moreover, the display may be influenced by the registrars or third party WHOIS operator who will choose the encoding that perhaps best represents registration data to its local set of users. Here in Korea, it may be very popular to have Web sites displayed in characters from the Korean scripts, and languages. In the United States, we're very comfortable with ASCII 7. In other countries, there are other scripts and languages that would be appropriate. So registrars may, in fact, have more than one way to display information, and this is not uncommon in Web pages and it may not be uncommon in the future for WHOIS applications. An example of a registry that provides WHOIS service and uses a character set other than ASCII 7 is DENIC and the DE registry used the enhanced Latin character set, and so for those of you who can't read this microscopic screen, there are umlauts and other -- you know, other characters that are beyond the characters that can be represented in ASCII 7 in the registration information that's displayed here. All this background sets us up for trying to understand the kinds of questions that we must consider when we approach the problem of internationalizing WHOIS registration data. They fall into three sets. One is a set of user experience issues. Certainly what we want to do is accommodate users. If we want to accommodate users, we need to stop to think for a moment about what features will benefit the Internet users. We also want to think about how we might minimalize what is called a Babel effect. Babel effect comes from the story from the Christian Bible where everyone wanted to build a tower to reach the God, and God was not particularly happy about, you know, the fact that they were trying to do this, and so what he did was he made everyone speak different languages and not understand each other. So we don't want that in WHOIS. We want people to be able to use the WHOIS data, no matter where they are, and we want some bases on which the data becomes not only usable by humans but also by machines. And this leads us to the second point here, which is: Data reliability, accuracy, and operational issues. Many people today will access WHOIS information and apply automation or applications that try to take the WHOIS data and use it to do monitoring, to do analysis, to identify, you know, registrants or domains that are either being used as a malicious domain in an attack or they're doing so for business purposes to collect information about owners and do some analytics over the span of WHOIS data. And obviously I'm talking very specifically about gTLD WHOIS and the WHOIS that's accessible under the current RAA guidelines which makes it publicly accessible. In many countries, that may not necessarily be the case, but for an initial discussion, I think it's worthwhile to talk about the publicly accessible case. One of the things that we have to be very sensitive to, and is becoming increasingly problematic is, if we create a Babel effect on the data, we potentially hamstring law enforcement, brand protection, intellectual property rights protection, and other analysts of WHOIS information who are attempting to reduce malicious conduct. There are business impacts as well. There are also some issues related to security and standardization that are concomitant with the issues I just discussed. Where are we now? We're at a point where SSAC has produced a document -- SAC037 -- which described the problems base I've just summarized. One of the recommendations that SSAC made was to the board of directors, and the board of directors responded and tasked the GNSO, ALAC, the ccNSO, the GAC, and SSAC, to form a working group to study the issues I've just discussed. ICANN staff, including Liz Gasster and Steven Sheng who is not here, and a number of others, worked to prepare a working group charter and implementation plan, and that charter and plan are published, and available for download. I don't have the URL but I can get it for you. The staff also was working jointly with members of SSAC to examine current practices among ccTLD registries. This is a very, very important aspect of the work that we're going to progress, and my personal opinion is that input from the ccTLD registries who have been dealing with this problem already is essential for us to find a solution that would be appropriate for perhaps adoption as a best practice globally. We want to find out whether there are some requirements for standard functionality that exist today or whether there are standards for functionality that you, the participants, believe are necessary. We also want to consider whether there are conventions and standards from other communications media -- for example, the Postal Service -- where you have service that has already had to deal with multilingual communications. Letters go out each day from every country to every other country. There are conventions. They're used. Perhaps those will conventions that we can use, or at least use as a paradigm for what we might want to accomplish with WHOIS. I'm going to talk a little bit now about some of the work that staff and SSAC members have done, and I'll begin by articulating the questions that we asked ourselves and then try to give you a little bit of insight into some of the initial analyses that we've conducted. None of these are recommendations. These are just straw men for consideration by you, the working group members and participants, and they're certainly not cast in concrete and they're certainly not an indicator of, you know, policy recommendations that the staff are proposing. So the first question is: Should the maintenance and display of certain registration data be required in U.S. ASCII, to ensure a common denominator for core information display? To consider this question, staff asked a second question, which is: What do current WHOIS practices tell us? In order to answer that question, we reached out to ccTLDs and members of the ccNSO who were willing to offer us anecdotal responses to these four questions. The four questions are: Does your registry allow users to register domains using characters from local scripts? Does your registry collect and store registration data in U.S. ASCII 7 in addition to characters from local scripts? Can users of the Web interface choose the display language? What languages does your Web interface support? Does your registry provide access to registration information via WHOIS Port 43, and can users choose the display language? Of the 16 ccTLDs who provided us with an initial set of anecdotal data, 10 of the 16 ccTLD registries allow users to register domain names using characters from local scripts. 10 of the 16 ccTLDs supported English or U.S. ASCII 7, and a local language script including Arabic, Chinese, German, Japanese, Lithuanian, Portuguese, Spanish and Swedish. All the ccTLDs supported WHOIS Port 43 and then of the ccTLDs reported that character set dependencies affected WHOIS client dependencies, and -- in respect to submission and display. So in some circumstances, the client application had to be able to support UTF-8 or UTF-16 or ISO-8859 in order for the WHOIS user to actually be able to display the information returned by the registry in a WHOIS response. A second question that staff asked was: Are there any general principles that registry operators and registrars could adopt to minimalize the Babel effect on registration data query services and to ensure some uniformity of information display? One of the conventions that we took a look at was the convention established by the Universal Postal Union for international address formatting. These are quotes from the IAP -- IAF, International Address Formatting standard. "The addressee's address shall be written legibly in Roman letters and Arabic numerals." That establishes a character set. "if other letters and figures are used in the country of destination, it shall be recommended that the address be given also in these letters and numerals." This established the concept -- I'm sorry. This establishes a context for the recipient address or the destination of the parcel or the letter. A corollary to this might be interpreted as, you know -- you know, for WHOIS, is WHOIS must support U.S. ASCII 7 and may also support a local script. And the question that staff will ask today, and we hope to discuss is: Is this appropriate for registration data? There are some other conventions and standards in that same UPU standard spec that describe how one actually does labeling of a letter, and I'm not going to go into the detail and try to read all this, because quite frankly I'm 57 years old and that's way too tiny, but if you look at the top part of this picture, what you see is an address of the addressee, the recipient of the mail on the left-hand side is in essentially ASCII 7 letters and Roman numerals -- I'm sorry, Roman letters and Arabic numerals? I'm confused now. But on the right-hand side, you'll see that there is a -- there is actually an Arabic script that -- you know, that is on the same parcel, to assist the post office in the destination country to further deliver the package to the recipient in that country. And the text below that simply identifies what the recommendations are. Another question staff asked was: What information and in what languages and scripts should be permitted when collecting and displaying registration data for a set of domain names? We get to a point with WHOIS where one of the considerations that SSAC wanted to raise attention to ICANN was perhaps it's time to stop thinking only in terms of WHOIS registration data in U.S. ASCII in unstructured, unformatted text, and start to consider a successor that might allow us to develop more rich data schema that would have tagged and typed data objects that would allow us to perhaps improve the accuracy and availability of the domain registration data. IRIS and CRISP are standards for an Internet directory service, and these are standards that SSAC has recommended that staff and the community consider as a possible successor to the current WHOIS environment, so one of the things that SSAC has recommended, and that staff has taken under consideration and that is actually a part of a study question that the GNSO has tasked staff to pursue is to enumerate service requirements for WHOIS, and part the enumeration is to, you know, take stock of the data that we collect today in WHOIS, to help understand what data we need to add to support additional and future services. Clearly, one of those possible services is the ability to not only provide a record of registration data in one language and one character set, but in more than one. The reference document that I'm talking about is SSAC037, "Display and Usage of Internationalized Registration Data," and the URL is on the presentation and slide. It's worth reading. It sets the stage and provides essentially the same context that I've provided today. At that point I'm going to turn this over to Bruce and allow him to drive the questions. I'm happy to answer any questions related to the presentation or to the report, and it's now in your hands. >>BRUCE TONKIN: Thank you. Okay. Are there any questions from the audience for Dave and his presentation? Any question or clarification at all? Let's I have a couple questions just -- I suppose one in terms of a larger survey you could potentially do. So you've covered ccTLDs. You didn't cover gTLD registrars or even gTLD registries, which also have quite significant amount of IDN data in them in terms of both the names of -- domain names because dot com, for example, supports IDN labels at the second level. And also a number of registrars within the gTLD space may well record and display registrant data in terms of names and address using different characters. Have you analyzed the g space at all? >>DAVE PISCITELLO: We haven't done that yet. Part of -- you know, part of exploring this question was -- you know, was to foster engagement with the community. And the gTLD community was somewhat engaged. And I was reaching out, in my particular anecdotal study, to participants who were in the ccTLD space because I wanted to encourage participation. My personal view is that we would benefit from having a very formal, more thorough collection of what current practices are, not simply from a handful that I speak with, but from as many ccTLD and gTLD registries and registrars as possible. >>BRUCE TONKIN: There's also another layer to that, which is also resellers. A lot of the -- with respect to what I'll refer to as the g space, if you look at the list of registrars, you might find a majority of them in are North American. And, certainly, a large number of them are in developed countries. But those registrars also have resellers that are in different countries. So the actual availability, if you like, of websites where you can submit registration data is quite diverse. So you almost look at different parts of the world and see how the local providers, which may or may not be registrars, are collecting and displaying data. So that's one thing. Go ahead, please. >>ANDREY KOLESNIKOV: It might be an interim solution just for a short time. We're launching dot rf, which is IDN for Russia. And we've decided that, when we start, the WHOIS data will be displayed in Latin script. We entered one field in the WHOIS output called the IDN, which will be in the Unicode. The domain will be in, you know, XN standard. And we have decided to wait until the, you know, general methodology of adapting the WHOIS output data will be, you know, accepted by the majority of the players, at least maybe at next ICANN meeting. That was just a little note. Maybe it will help. >>DAVE PISCITELLO: So, to summarize, your registration data is still in Latin characters in the current set. But the full IDN, essentially, the U-label of the domain name will be represented as well as the XN dash dash or the A-label. >>ANDREY KOLESNIKOV: Yes. >>DAVE PISCITELLO: Okay. A number of registries actually do that. And I think that that's, actually, very useful. One interesting application that derives from just looking at that particular piece of data is that, if you have the XN dash dash, the A- label, applications that today look for the domain label and parse it in ASCII, can still parse it in ASCII, because it's still a letter digit hyphen label. And that means that we aren't disrupting applications that assume that the domain name is going to be ASCII. So the way that you're doing it is you're saying, you know, you're going to still have ASCII. But you'll add -- >>ANDREY KOLESNIKOV: We'll just add another field. >>DAVE PISCITELLO: -- Russian. So one question to ask back would be: Do you think it would be appropriate in the future to require ASCII for your registration data and then also allow Russian registrants to submit their data in Cyrillic characters? >>ANDREY KOLESNIKOV: Yes, that's the future. It's just, you know, extension of the number of fields in the databases. We have another problem we should -- maybe I should share. Starting January 1st, there will be a new law in place in Russia. It's a personal protection -- personal data protection law. So, everything which you see now through WHOIS and dot ru zone, you can see now the contact number, the name of the person. That all will be enclosed. So I don't know if it's good or bad. >>DAVE PISCITELLO: Well, you know, we want to separate the issue of privacy laws and what information actually gets publicly displayed from a -- >>ANDREY KOLESNOKIV: From information. >>DAVE PISCITELLO: Whether or not the information would still be usable by law enforcement or other groups that, you know, a sovereign nation might agree has access to that data. And I think that -- that's a very, very important baseline. >>ANDREY KOLESNIKOV: That's another topic, I agree. Thank you. >>DAVE PISCITELLO: Sure. >>BRUCE TONKIN: Any other questions? Just one sort of observation, I noticed you were using the postal information, which is, essentially, routing data. And one of the things there is, as long as you can route it to the right country and the right general region, you're assuring people in that region know how to decode the rest of the address. Probably another thing that you might want to have a look at is phone directory information, which should probably be a closer analogy, because a phone numbers associated with a user and an address, typically. And many nations have an ability to look up a person's phone number based on their name, in some cases, their address. And, more commonly, I guess those are online applications as opposed to pieces of paper floating around. So you might have a look at how different countries, both collect information on the user of a phone number and also how they display information relating to a person in terms of telephone lookup services. >>DAVE PISCITELLO: The small experience that I've had with White Pages services internationally is that they're very country specific. That some countries, build their White Pages exclusively in their -- in the character set that is the national -- you know, the characters from the national language or languages. And so I guess one of the interesting questions would be what a White Pages directory service would look like under in the European Union. So, if the European Union posts a White Pages directory for European Union members, what does that look like? In theory, everything that's printed and published by the European Union must be printed and published in every language that is -- you know, that is represented in the Union. So that, actually, would be an interesting issue to -- yeah, to investigate. >>BRUCE TONKIN: What's your plans with respect to what you see the next steps are? So, to my mind, you could have almost an IETF-type approach that looks at some of the data formats. I notice that data format can be a little bit separated from protocol, too. So you could still define a data format that would work with Port 43 WHOIS, as an example, as just a data overlay for protocol for send and receive. >>DAVE PISCITELLO: Right. >>BRUCE TONKIN: You're not necessarily tied to CRISP as a protocol. Obviously, there's benefits there. Whereas, the data formatting information could be used by existing Port 43 services as well. >>DAVE PISCITELLO: I think it's important for us to continue to separate the data schema from the protocol. And one of the things that -- hey! One of the things that we've considered and we talked about earlier today during the GNSO Council session was the need to have data schema that's extensible that is protocol agnostic and that allows us to accommodate not only one, but multiple -- in this case, multiple languages. So, you know, if I were to be designing this on the fly, I could envision an XML data schema that would accommodate, you know, an entire registration record in US ASCII7 and some flag that said there is an associated record that is in another language and there's an indication of what that other language is and what the encoding is. And then there might be a complementary set. The -- yeah, the value of having the two, especially if one is established as the baseline, is that automation can use the baseline and rely on that as being present no matter where you were able to pull the WHOIS data from. And I think that that would be a very, very useful way to go. But that's putting on my technology hat and saying, "Let me make automation simple, and let me make it as flexible as possible." There is a certain overhead to that. And maybe Mr. Kosters could interject. >>BRUCE TONKIN: It's interesting, too. Seeing Mr. Kosters there -- and we're looking at it from an RIR point of view. But, really, registration data cuts across gTLDs, ccTLDs, and also Internet registries, yeah. Go ahead, Mark. >>MARK KOSTERS: So I have just a couple comments. I'm Mark Kosters, CTO of ARIN. Is that better? >>BRUCE TONKIN: Yes. >>MARK KOSTERS: Sorry. I'm Mark Kosters, CTO of Arin. I've worked on the Irish protocol for years and years and years. And it's very flexible, but it's very heavy weight. And one of the things that we're learning from this is there's not a lot of uptake that's going on here. So one of the things we've been looking at recently at Arin is, actually, putting WHOIS information in a restful interface, which everybody has a client, too, because everybody has a web browser and everybody can understand that. It has natural sort of extensions of internationalization and so on that's, actually, just naturally in your browser. And most servers can support UTF-8, if you were to build something like that. But, again, it really comes down to, you can create a protocol for almost everything. We tried with IRIS. And whether or not -- maybe that was too hard, and maybe we need to go back and create something more simple like just using a restful interface instead. >>BRUCE TONKIN: Can you just say that a little bit -- using a what interface? >>MARK KOSTERS: A restful interface. It's, basically, using regular XML over HTTP to -- you ask for a well-formed query, and you get back a well-formed result. And the result is in XML. >>DAVE PISCITELLO: And I think we are very much -- at least you and I are very much in agreement that that actually has several benefits. If people are uncertain or, you know, are wary of taking on the full load of IRIS and CRISP as their protocol and architectural paradigm, by having a data set that we can experiment with and establish over HTTP, that might easily migrate to IRIS and CRISP, we cut the problem into two separable pieces. And my personal feeling is that, if you get the data right first, and you make it protocol agnostic, you have a cleaner migration path than if you try to do this sort of blunt wedge approach with the data and the protocol and then they're inseparable. >>BRUCE TONKIN: I think that's useful advice, Mark. That's certainly the trend. A lot of the people in industry do use Web- based interfaces for people to access information. And you assure things like IRIS can allow more advanced computer-to-computer interactions. But, in many cases, you're just, basically, allowing people access to data that's in a database using a web browser and then using XML and things like that for the data formats. >>DAVE PISCITELLO: So, Mark, I actually have a question for you. I don't want to you feel like you need to answer on behalf of all the RIRs. But the fact that you are here and the fact that you are interesting something that is relatively similar to what we're doing, it seems to me there would be a benefit from having some participation from the RIRs in the work that we're doing. >>MARK KOSTERS: Certainly true. I'm part of SSAC, so that makes sense there. This is something that's very new. We just announced it last week. There's, obviously, a lot of standardization work that needs to occur in this area, if it is successful. But it does go beyond, okay, I have this protocol, IRIS. I need a specific client that understands IRIS to make this work. And this has deployment all around the world now, since everybody has a web browser. So it -- it reduces that hurdle. >>BRUCE TONKIN: So it sounds like, from that comment and also the comment I was making, that, if the focus is initially on data formats rather than protocol -- and Dave was just saying being agnostic to protocol -- I think that's a good way of getting the discussion going. And then that -- if you have a proposed data format or schema and you can share it with the RIR community and the GNSO registrars and registries and sort of get some input around that, then the question is what status does that format then have? You know, does it go through some sort of standardization process? Is it simply a best practice document that we have on the ICANN website? How do we get that? If you have some thoughts on that. >>DAVE PISCITELLO: Haven't taken it that far. But I think this is, actually, a good opportunity to see if we can get a poll from people who are from, you know, from registries that are not gTLD registries. You know, are people here interested in going through an IETF standard root for defining this data set? Are you interested in having ICANN publish -- you know, publish this as, you know, as a best practice? Would you want to see this eventually find its way into the RAA as an obligation for registrars? And then the ccTLDs can adopt, as they see fit. I mean, there's a lot of different paths we can take here. And, certainly, staff would love to get some feedback. >>BRUCE TONKIN: Well, I guess you get a benefit in the g world of standardizing some of these things and making it -- doesn't matter whether it's IETF or ICANN, because they both can be best practice. But you could -- that might actually help its adoption if it's -- at least one part of the community is required to use it. But before you got to that point, I think you'd want to know that the data format is pretty bedded down and has been through a few iterations. >>JAY DALEY: Thanks. Jay Daley. If there is some standardization, I'd ask that attempt to make -- not to make the same -- not to introduce the same problems that EPP had where it's standardized a set of data which different people don't adhere to. And so there are a number of organizations going through big changes to change their data in order to do that. What's necessary is really the presentation there, not the actual data definition there, in this case. And we already have one element of standardization in WHOIS, which we know about from the RIRs, which is RPSL. So we have something there to start from looking at how WHOIS data might be put forward in a way. >>BRUCE TONKIN: Ray? >>RAY PLZAK: Ray Plzak, ICANN board. From the standpoint of somebody to do this work, you know, RPSL is a good example, for that matter. It was developed someplace else, and eventually gets kept sort of memorialized through the IETF process in an RFC. Starting out the lightweight way for this to be would be some sort of an informational RFC. I would have more strength if you can find a working group that would adopt it so you can work inside that working group, as opposed to being one coming in from the cold which the RFC editor would publish anyway. But it would seem to me that that would be the best way. Being an RFC, it carries the weight of being an RFC, which actually makes it easier to discuss. And you could even reference it in the RAA, you know, say, "If you want to do this, here's someplace to think about." There's a number of ways that it can be done. But I think there's a lot that lends itself to figuring out a way of doing this inside the IETF. >>BRUCE TONKIN: So your recommendation is an informational RFC as a starting place -- >>RAY PLZAK: Yes. I would run a standard -- >>BRUCE TONKIN: It's not really a standard. >>RAY PLZAK: You're going to be there forever. Informational RFCs can take time to do anyway. And, well, Mark's been through this as well as I have. But it is a way of doing it. You know, if you don't do it that way, then you're -- somehow or another, you still end up having to certify or credit or whatever you want to say, whatever it is you picked up -- whatever term you want to pick -- this as a way to go. There's a certain discipline inside of doing it through an RFC. >>BRUCE TONKIN: Yeah. There's a degree of quality control in that process, I guess, yeah. Mark? >>MARK KOSTERS: I'm going to reference something that was put out, like, 15 years ago. It's a protocol called RWHOIS. ARIN is one of the only organizations that said, "Hey, look. You can either give us your data, or you can run a RWHOIS server locally." RWHOIS is a distributed form of WHOIS. And it allowed ISPs, actually, to run and maintain their own data. It's, actually, very popular within the ARIN region to run their own RWHOIS server. Because they had the opportunity to do so, and they found it much easier to do that than, actually, give ARIN its customer database. So it -- there's kind of a carrot-and-stick approach is what I'm saying as we go forward with this to say, "Okay, you have this really crafty WHOIS protocol that doesn't work with internationalization or any other sort of access control. And we really need to replace it, and here's how we can do it." And you have various protocols that have been thought of already that are much superior to WHOIS. But yet there has to be some sort of carrot to get people to actually follow that. And I think that's the part that's been missing through all this over the last couple years is some sort of carrot to make that go. >>RAY PLZAK: Full disclosure, Mark. You're an author of that RFC. >>MARK KOSTERS: Thank you. >>BRUCE TONKIN: That's separating the issues, too, Mark. You're talking about access control and the use of different protocols to help access control. And really what we're trying to talk about here is have some commonality on the data formats. They are different topics, but I agree. Port 43 can't handle different forms of access control, but it can handle different data formats as per the HTML approach as well. >>JAY DALEY: I agree entirely. Please don't do access control at the same time. It guarantees it's not going to work. You'll die. One of the things that's used by a lot of ccTLDs are parameters being passed to WHOIS. There's a mechanism for doing it that works quite nicely, and some people use it quite happily. It has no standardization whatsoever, but it's another way that you can do it lightweight within WHOIS to try to achieve what we want out of this. I personally would not recommend CRISP or IRIS either, because outside of the RIRs nobody's using it at all. I had an RSF written five years ago and didn't even bother to deploy it because there was so little interest in it. It's really -- I'm sure it would have been a good piece of technology, but it was trying to fix too many things all at once. So something that's simpler, possibly such as parameters on WHOIS, has a chance of actually succeeding. >>BRUCE TONKIN: Okay. Any other questions or comments? Okay. I think I might try and finish the session early then in that case, unless, Dave, you've got any final words you'd like to add. >>DAVE PISCITELLO: Well, actually, just a show of hands of how many people here would be interested in participating in the working group. You know, volunteers are desperately needed. There's only so many cycles staff can put on these. And, certainly, we would -- we value some of the input from people who are -- you know, have some experience in this. So I see Jay -- you don't have to actually show hands. But -- >>BRUCE TONKIN: I think there was a show of hand over here as well. >>DAVE PISCITELLO: Oh, good. We have one, two, three. Edmon, Kim -- get them on tape. We have Mark Kosters. We have Edmon Chung. >>BRUCE TONKIN: It's good to have people that use scripts other than Latin script as well. I'm pleased to see -- >>DAVE PISCITELLO: Please, someone other than someone who uses a Latin script or other than an extended Latin script join us. I'm very pleased with some of the topics we discussed. I think this is valuable. >>BRUCE TONKIN: Good. Okay. Well, thank you, everybody. And see you all at whatever the next session is. [Applause]