ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>STEVE CROCKER: Is this live? It is live. Thank you, all, for coming. I apologize for starting a few minutes late. I thought by ending the last session a couple minutes early I would be on time but here we are.

This is the public meeting of the security and stability Advisory Committee. We hold these meetings -- we try it to hold these meetings at each ICANN meeting to present results of the committee's work and to present what the committee is, at least briefly, and to provide a feedback mechanism so that anyone is welcome to interact, ask questions, see what's going on.

We have only a handful -- well, maybe two handfuls of people in the room. But that's fine. We have a number of people, I know, on the Webcast. Do we have any feedback mechanism available? Who am I asking that question of? Do you know whether or not it is possible to ask questions on the Web? I will find out if some question comes in. Steve Conte?

>>STEVE CONTE: I think there is a chatroom on the ICANN.org Web site. I am double-checking that.

>>STEVE CROCKER: As long as you are there, if you would monitor that, that would be helpful.

>>STEVE CONTE: I will be watching the SSAC lounge, too.

>>STEVE CROCKER: That would be great.

The agenda today is that we're going to have a presentation from Suzanne Woolf on accommodating IPv6 resource records in the root of the domain name system. This is a report on a very substantial piece of work that we've done over the last -- much longer than I had expected. Months and months and months.

In addition to the technical results which are actually very positive, there is a procedural result which is also very positive. This work was done very specifically as a joint effort with the Root Server Advisory Committee and represents the output of both groups quite equally. The root server advisory group represents all of the root server operators and they are the core group of expertise. There is a certain amount of overlap between the two committees, and in particular Suzanne, for example, is a root server operator and also a key member of SSAC.

But we had not in the past engaged in any specific joint effort, although we have been open to that and I am very pleased that this has worked out very well.

We also make it a point to invite Lyman Chapin who chairs the Registry Services Technical Evaluation Panel process. I think his report today will be short, and let him say the rest of that.

And then we will very briefly, very briefly say something about a WHOIS study that we're kicking off with. I guess we kicked it off. An IDN study that we're starting, and I will say a word or two about RegisterFly because everybody has to say something about RegisterFly. But I won't say very much.

And then we will have time for questions and answers. Even though we started late, my intention is to stop promptly at 7:15, if not sooner.

A brief introduction about who we are for people who don't know. We are an external Advisory Committee. By "external" I mean this is not ICANN staff. We are part of what's referred to as one of the Advisory Committees. You will see the term SOs and ACs, Supporting Organizations and Advisory Committees. We are one of those Advisory Committees.

We are unlike some of the other groups in that we don't have a natural constituency. We don't have any territory that we control.

So one odd thing is that there isn't any place that we naturally all congregate. Sometimes some of us come to ICANN meetings. IETF meetings is another place where some of our members tend to show up. Unless we actually imported the people for the purpose, there isn't a single place that we sort of show up for other reasons.

We give advice. We give advice to the board. We are formally constituted as an Advisory Committee to the board. We give advice to the staff. We give advice to Supporting Organizations, other Advisory Committees and to the community at large, and we are jealous of our independence. One of the ground rules when we set up that our initial members insisted on, they were perfectly happy to be helpful. They wanted to try to avoid some of the political cross-currents and be able to address technical issues, speak their mind and then get out of the way in a sense.

So this is a two-sided bargain. We get to say what we think is right, and nobody has to listen to us. And both of those things happen from time to time.

Here is the set of members and supporting people. It looks very small on my screen but it is big enough there. I have been the chair for -- since the inception for five years and we are without any formal mechanism for getting rid of me except I serve at the pleasure of the board.

The other mechanism which is likely to work even better, I may get tired of this or think that I am not doing any good. Ray Plzak who is president and C.E.O. of ARIN is vice chair. Who else in the room is related to SSAC? Probably not so many people. Suzanne. Is that it? Is that it? It is.

>>SUZANNE WOOLF: Ram is here.

>>STEVE CROCKER: Yep. Ram Mohan is a very active member. He is so active, he is in another room talking about IDNs in another setting right now. Sometimes some others come. But that gives you an idea how spread out we are.

These people, if you recognize them, are experts in various aspects of the domain name system and security. Some work for registries. Some work for registrars. Some work for address registries like Ray and a number of people have quite a strong security background.

That is the end of my introduction, and so let me go back and turn things over to Suzanne and the floor is yours. And the screen will be momentarily.

>>SUZANNE WOOLF: I may even have a microphone. Steve, I can't be sure anymore I will be able to promise to get us out of here because the transcriptionists reminded me to slow down. They have a terrible time with my normal speaking voice. But we will do our best. There should have been a little bit of a laugh there.

>>STEVE CROCKER: Hee-hee.

>>SUZANNE WOOLF: Ever the reliable chairman.

[ Laughter ]

Thank you for that very fine introduction, Steve. Let me move the microphone a little bit so it is not coming and going.

Good afternoon. I guess it is still here because it is not nearly dinner time. Thanks for being here. This is a heavily technical topic ,and I will try not to linger on technical detail but there is a certain amount we can't get away from. Mainly, I think the committees who worked on this report regard it as both a step forward for the future of the Internet and an illustration of how hard it is and how careful we have to be when we try to change the infrastructure that's used by many millions of users.

I would like to start by thanking both committees, SSAC and RSSAC and Dave Piscitello, the SSAC fellow who is not here -- that rhymes -- who is not here today but who worked on these slides with me. You who were in Sao Paulo and heard the update on this work in progress have seen some of the early slides before.

They were so good, I kept them. Thank you, Dave.

So what are we talking about? IPv6 is designed to make more addresses available in an interoperable way. There are definite transition steps with accompanying difficulties to having IPv6 replace IPv4 in the public Internet. Why does it matter? Well, there is first a technical need to extend Internet Protocols including DNS, to allow for advancing technology, new capabilities, new services that ISPs and users haven't thought of before.

There is a practical need to make sure such advances are made carefully. The appropriate focus -- it says here, appropriate focus on consequences and great care to preserve the security and stability of the Internet.

We went into this process both with the practical problem to solve and in hopes of demonstrating a case study for how we do this sort of thing without getting so paralyzed in analysis that we don't get anything done but also with being able to move forward.

Now, where we are today. All the pieces are understood. They just need to be assembled. The DNS standards accommodate IPv6. There is a new resource record referred to as AAA because the old record for an IPv4 address is referred to as an A record. DNS support for IPv6 is available today in many top-level domains, many second-level domains, several of the root name servers have IPv6 addresses and transport available to them.

But IPv6 name resolution is not available at the root of the DNS. You can't ask a root name server the IPv6 address of a root name server. This is a stumbling block to moving away from IPv4.

There is a dependency there that has to be resolved.

So why not? What are the impediments? What are the concerns? There are technical issues strictly in terms of the protocol and implementations we know are out there. DNS response packet sizes increase when V6 addresses are present. V6 addresses are larger so data packets that include them are going to be larger. There is a novelty factor of AAAA records. Modern resolvers know how to handle records they don't recognize but there is a tremendous installed base and not all of it is populated by software that knows what to do with something unfamiliar.

There is also the non-technical issue of doing it safely. There is some new territory. There is analytic complexity because the public Internet is not a loud system, as much as a few of us miss those days. It has been a while. So there is protocol analysis.

So we know what the bits are going to do, but there is also the problem of making sure we really understood it by testing empirically. It is holding us back. This is getting into the technical part.

I will try to emphasize the take-away points. And the details are here for those who want them. There is a lot more detail in the SSAC report which I will give the URL to at the end.

One of the initial limitations -- DNS has a historic limit on the size of a DNS response, including IPv6 data, means the response is going to be bigger and in terms of the original protocol, sometimes too big. There is a way in the DNS protocol for handling larger responses. It is a protocol extension that has been through the IETF. It is well-known, and it is well-tested. But not every DNS implementation in the world supports it, so there is the need to verify that the critical data for reaching the root still fits in the older packet. The additional set of concerns, every resolver needs to know the address of at least one root name server when it starts up. There is a boot-strapping problem of where does a DNS client learn to find the root.

The root servers themselves tell it how to find everyone else. But any resolver has to start with the ability to find one of the root servers. This is a configuration issue for operating systems and system administrators. The verification of initial data is called the priming exchange. Not all resolvers do it, but this is an operational factor in how the DNS functions for an enormous installed base. The configuration information is called the hints file. There is lots of ways it gets into the system. IANA maintains it.

And for those resolvers that need it, they need to have it present and they need to be able to understand what's in it or they don't ever get off the ground as far as being DNS resolvers.

So the bottom line there is that we need to know that the priming query and other attempts to query the root will be successful, even for clients that don't understand IPv6, don't understand larger DNS answers, especially given that clients are not always just what's in your work station. Clients can be applications, can be enterprise resolvers like your resolvers run by your ISP or middleboxes like firewalls.

Backwards compatibility is not optional. A situation that would strand any significant fraction of the installed base is not acceptable.

The hints file itself, if anybody is curious, is a text file of names and IP addresses of root name servers. That part is not the hard part.

The diagrams here in the next couple of pages are in the archive but the point is that today the reply to the initial priming query, the "hi, are you the root query from a resolver" fits into the size originally specified for DNS packets so that even the oldest DNS software can handle it.

For IPv6, the bottom line, another aspect that V6 addresses affect the size of the priming response. It may not fit into what an older resolver is expecting. There is an additional set of technical systems considerations. The intermediate systems between a work station and a root name server like firewalls and nat boxes, these are widespread. They are everywhere. They are all slightly different and not all of them understand just like not all older resolver software understands what to do with an IPv6 address, what to do with a larger DNS answer.

So a significant effort, as Steve described, was undertaken to study this set of issues and quantify the risks. The report is about 40 pages, including the details of the test methodology and the results. And I will summarize the recommendations here.

The take-away point is just it is kind of messy out there, and we had to make sure we were not causing less functionality for some users and operators in the course of trying to evolve the Internet towards the future.

So the findings, people do care about this. The constituency for V6 availability all the way from the root is significant and growing. Adding V6 addresses at the root does affect the root hints file and the priming exchange.

We also know that it affects the root -- there are edits that have to be done to the root zone itself, but that's not a particular concern. There have been TLDs with AAAAs in the root for some time now. DNS implementations in use by all the root name servers fully support IPv6 records and EDNS0 which is the extension that allows for larger replies. The servers are ready to serve this data. The questions are about the resolvers in the world being ready to handle it and accept it and use it.

We found there is no reason to change the existing procedures for publishing IANA's root hints. It may be helpful for there to be two versions for a while so that administrators who don't want AAAAs in the hints file don't have to remove them before installing them for their users.

In addition specifically about the priming exchange, adding IPv6 addresses adds a resource record that many DNS implementations have never seen in the priming response. We had to find out if that was a problem. More than two AAAAs in the response will cause it to exceed the original 512 byte message size limit from the original DNS specification.

Have to see if that's going to cause a problem.

And a priming response that includes both IPv4 and V6 records, because, of course, the V4 records are not going away, for all the root servers will be large enough that a resolver that can't handle the full response may not get all the AAAA records.

So there is a few things to look closely at there.

So, again, according to the methodology described in the paper, actually several papers -- there were a couple public postings of calls for participation in the testing. This was actually a very wide effort to involve whoever was interested in the public Internet. There were postings to some of the operations mailing lists. There was a wide effort to get people who wouldn't otherwise be necessarily involved in this effort to test their stuff, to say does this work for you, real people out there.

So among the findings, we have empirical test results. We found resolvers commonly used in production networks today are able to process AAAA records returned as name server addresses without a problem.

They don't always know what to do with them ,but it is not a problem for them to receive them. They ignore them if they don't want them.

Intermediate systems commonly used in production networks today allow DNS messages with V6 addresses to pass without incident. Commonly used resolvers are EDNS0 capable and a majority can easily handle the larger responses, up to a response that would include all 13 root name servers, both V4 and V6 addresses.

The only issue in our findings that requires a little more care maybe, that some intermediate systems -- that's firewalls and nat boxes. And which ones are looked at are in the report -- block DNS messages longer than 512 gigabytes by default. It is it is configuration option. Typically, it is turned on to avoid DOS attacks as part of a firewall policy that filters out anything that you are not expecting.

It can be tuned.

So recommendations. Since the object of this exercise was to have recommendation -- specific recommendations for IANA. IANA should provide advanced public notice of a date on which priming responses from the root name servers will include, in addition to the data that's already there today, AAAA records for root name servers that have been assigned IPv6 addresses and transport by their operators. In addition, ICANN should continue to host a public space -- the one that was set up for the test, for the -- sorry, for the report, the testing and analysis phase -- should continue to host a public space where technical experts from IANA and the community can assist anyone having difficulty with these changes, and maintain a list that records how widely deployed resolver and firewall and NAT implementations behave when they receive the larger priming response. So the encouragement there is to go ahead and keep an archive of the collective experience with those.

And that part, I'm actually particularly hoping will set a precedent for future evolutionary steps of this kind.

In addition, on the specified date, IANA should just go ahead and publish the root hints file with AAAAs in it. The original 13A resource records for the IPv4 addresses of the root name servers and the AAAA addresses of root name servers that have v6 transport and just go ahead and do it.

For those who are ready on IANA's chosen date and then to add AAAA records to the root zone and root hints and root servers zone for other root-name servers as they're assigned IPv6 addresses and connectivity, so the eventual goal is that there will be IPv4 addresses and IPv6 addresses live in the system for all the root-name servers.

And that's where we are. We'd have to -- I guess the next step is -- I believe comes from IANA as far as the details of setting the date, and implementing the changes. So we've got a couple of references here. The full-length version of the report and the two calls to the community for testing and the pointers to the archived pages where the results are kept, and there is actually a page of SSAC -- of pointers to SSAC documents you said the SSAC home page at ICANN, and all the pointers can be found there. And I hope the transcriptionists are pleased with me.chocolate.

>>SUZANNE WOOLF: And Bill gets his chocolate for me speaking slowly enough and we can take any questions. Or we can all go to dinner.

>>STEVE CROCKER: Not quite, but almost. Indeed, are there questions on this?

>>LYMAN CHAPIN: One question. Just I'd be interested to know, Suzanne, if you could just give us a quick update on the status of sort of let's call it movement towards support of v6 transport by the other root servers. Those seven that don't currently have v6-capable addresses.

>>SUZANNE WOOLF: I don't actually have a detailed pricing in front of me. It's in everybody's roadmap. Those who don't are in varying stages of their normal life cycles for changes and upgrades, so you would have to look at that case by case.

>>LYMAN CHAPIN: So there isn't any institutionalized or policy reason for it to be only 6 at this point.

>>SUZANNE WOOLF: No.

>>LYMAN CHAPIN: It's just a process that's underway? Okay. That's what I was wondering.

>>SUZANNE WOOLF: No. It's a matter of different cycles and different time lines for different operators.

>>LYMAN CHAPIN: Okay. Good. Thanks.

>>STEVE CROCKER: Let me actually follow up on that. Is there a -- do you have a sense of when they're likely at all to be connected? And a related question: Is the speed at which that is likely to happen being governed at all by the fact that there wasn't any way to put the addresses into the root and -- or sort of the other side of that: When there is a way to put the addresses in the root, is that likely to speed up the process?

>>SUZANNE WOOLF: I suspect it will. To be honest, I lost track of the first part of your question. But I do suspect that having the capability available, having this data out there, that the server operators and IANA can proceed together to deploy this capability.

>>STEVE CROCKER: And the first part was whether or not you had any guesstimate as to when that process might be complete.

>>SUZANNE WOOLF: Well, it could be like DNSsec, six months away.

[Laughter]

>>SUZANNE WOOLF: No. Seriously, I don't know. I do know it's in everybody's roadmap but I don't have the list in front of me.

>>STEVE CROCKER: Fair enough. Any other questions?

Okay. Thank you very much. You're going to post those slides and I'm going to steal them for a keynote talk I'm going to give tomorrow morning on a similar subject.

[Laughter]

>>SUZANNE WOOLF: Sure. No worries. Just give Dave P. credit for his pictures.

>>STEVE CROCKER: I will. And it will be shorter and just a brief mention. Okay. Let me turn the floor over to Lyman Chapin.

>>LYMAN CHAPIN: Okay. Thank you, Steve. As Steve mentioned during the introductions, I chair the registry services technology -- registry services technology evaluation panel. It still doesn't roll off the tongue the way it should. RSTEP. That's easier.

And our job, and the reason that my report is going to be much shorter, our job is to review new gTLD registry service requests for any possible implications on security and stability when we are asked to do so by the ICANN staff that are responsible for maintaining liaison with the gTLD registries. And what that means is that we only become involved in any of these issues when there's a specific registry service request on the table, and the ICANN staff has determined that a thorough review with respect to security and stability is necessary in order for them to make a decision about the service that the registry wants to offer.

So to give you an example of the way in which that works, since the process was begun mid-2006, towards the end of the summer last year, seven registry service proposals have been sent through the -- through the funnel from dot travel, dot biz, dot org, dot name, dot cat, dot jobs and the most recent ones is combined for dot com and dot net. And of those, only two -- well, of those five have been approved. One was not approved. One of them was just submitted on March 22nd and so hasn't -- is still in the works. But only two of those seven were considered to be sufficiently -- sufficiently technically questionable or -- you know, to have issues surrounding security and stability that they triggered an RSTEP review. And both of those reviews were conducted last year. So there's been no RSTEP review since the last opportunity that I had to report at the Sao Paulo meeting.

So essentially all I can tell you is that the panel stands ready to put together review teams, when called upon to do so. The panel has 24 members now. Six of the panel members are also members of the SSAC, and we work very closely with the SSAC to ensure that pretty much everything they know, we know, and everything we know they know, so that there are no surprises.

And I'll add something that I feel very strongly about, which is that, of course, this whole process of ensuring that registry services, especially new registry services proposed by the gTLDs do not cause security or stability programs for the -- problems for the Internet. Is the lines of communication that are open between the registry folks and the ICANN folks. The better those lines of communication and the more frequently the ICANN folks -- in particular, I'll point out the person who is most responsible for this, Patrick Jones, who is on the ICANN staff, is right over here in the corner. The more frequently, he gets to talk to the people at the registries about what their plans are and the more forthcoming the registry folks are in exploring those plans well ahead of time with ICANN, the smoother this whole process goes.

In a perfect world, you wouldn't need the panel that I chair, and that would be fine with me. Thank you, Steve. That's all I have to say. But I'd be happy to take questions.

>>STEVE CROCKER: Thank you very much, Lyman. Please do take questions while I --

>>LYMAN CHAPIN: Sure.

>>STEVE CROCKER: Let's see. I need this, the screen.

>>SUZANNE WOOLF: I actually have a question.

>>LYMAN CHAPIN: Okay.

>>SUZANNE WOOLF: I see my colleague, Steve Conte out there. The ICANN staff responsible more or less for the root server that ICANN operates, and was hoping you could address do you have a v6 prefix, do you have v6 transport for "L" root and talk a little bit about the time line and upgrade path.

>>STEVE CONTE: Absolutely. Speaking for "L" root, we -- actually, Steve, it goes hand in hand with the DNSsec deployment. I think a lot of what is driving us and we're by far not a leader in upgrading our root server. A lot of other root servers are much further than we are. A lot of what has been driving our upgrades lately has been preparing for the DNSsec deployment, but at the same time as we upgraded our equipment, then we're able to handle v6. We do have a prefix. We're not answer -- we're not responding to it yet. We'll be putting that into our routers and switchers very soon. Probably well under six months. And I think that's been the driving force for -- I don't want to speak for any other root server but I think that's been the driving force for some of the other ones who have been going through the upgrading process over the last year of their equipment.

>>SUZANNE WOOLF: Yeah. And one of the key points is actually that being ready for DNSsec in terms of software deployment and deployment capabilities is very close and very closely related to v6, and a number of other advanced features.

>>STEVE CONTE: Absolutely. And it also -- you know, it's -- it's the one upgrade is a big driving force, too. If we're going to do it, let's do it right, let's get it done all at once and not do, you know, baby steps to get it done.

>>SUZANNE WOOLF: Thanks, Steve.

>>STEVE CROCKER: Bill?

>>BILL MANNING: Are you interested in other points of view.

>>SUZANNE WOOLF: I thought I'd pick on ICANN especially, being at the ICANN meeting, but if you wish to speak...

>>BILL MANNING: From a different of -- this is Bill Manning. From a different perspective, or in that continuum of v6 readiness, the root server that I touch on, on occasion, has had an IPv6 prefix for five years? It was in the routing system for a while, we tested transport reachability, and we removed it to prevent -- we removed it from the routing system to prevent problems until this report concluded. We expect to re-enable it by the end of this month, and put it back into play. We were waiting for this report.

>>STEVE CROCKER: This is March 28th. Did you actually mean the end of March?

>>BILL MANNING: That is correct.

>>STEVE CROCKER: The day after the end of March is April Fool's Day.

>>BILL MANNING: That is a traditional National Science Foundation award date.

[Laughter]

>>STEVE CROCKER: Fair enough. All right. Any other -- any other questions in this area? All right. Let me move on.

I want to talk about two studies that are in their initial phases, so I don't have any conclusions or findings to present. More a question of sharing with you where we're headed in the near future.

Ram Mohan is critically involved in both of these, and is, at this moment, I think, double-booked over in another session where he's deeply enmeshed in some IDN activities, so we're backfilling here.

IDNs, as everyone knows, are a major objective for inclusion in the domain name system. There is tremendous visibility, attention, concern. I have to confess quite a lot of personal embarrassment in that it was evident to me a while ago -- probably measured on the order of two years or three years -- that it would have been appropriate for our committee to get involved and take a close look at the security and stability issues, if there are any, or at least find out if there are any.

We took a shot at it. We tried to have some discussions and discovered that we didn't actually have the right mix of people. That although we have a very strong group, a cross-section of a lot of different expertise, in this particular area we weren't very well matched. And what happened is I -- I kind of let it go. Last fall, it became evident and was sort of brought back to my attention that that's not an adequate position, and I agreed, as I say, with a certain amount of embarrassment and like I should have reached that conclusion myself. And refocused on how to move forward.

And the change in plan was to get some help from outside the committee, a very natural sort of thing. And to get some support. So we actually are in the process of formulating a kind of separate study committee that will have a mixture of a few people from inside the existing committee and then some experts from outside, and some additional support. Ram Mohan is one of the people, actually, who -- one of the few inside the committee who has expertise in this area, and he's agreed to chair the study. I should also say that I -- though I'm not an IDN expert, I'm semi-knowledgeable and positively tuned to the problem in the sense of wanting to learn more, so I expect to learn -- to use this as a kind of active learning experience.

Another thing that has also been evident to me, for sure, when I've been trying to read, is how dense and complicated the subject is, and that in trying to assemble the material to come up to speed, it's not an easy challenge. There's a lot that's been written, but you have to know almost everything before you can read almost anything.

So we've set as one of the objectives for this study is to leave behind an easier set of materials to navigate through. Don't intend to duplicate work that other people have done but to assemble it, fill in some of the blanks, provide some navigation and so forth. Let's see.

So I've covered some of this. The goal, it says, is to determine whether the introduction of IDNs at the top level has any impact on security and stability of the Internet. And of course if so, to identify what those questions are.

There may not be any, although I'm -- I suspect that it's not quite that good. But at the very least, we're going to know what the -- what those issues are, even if we don't have solutions to them all.

We use a relatively small team of people. This is not intended to be a politically correct representation from every quarter. This is much more of a technical experts group and its output, as is the nature of what we do, is advice to the people who make policies and they can do with it what they will.

Our goal is to provide very clear guidance as to the consequences or, if you like, safe areas -- stay within these areas -- and then whatever choices you make reflect the values and business issues and so forth. Step outside of these, and here's some of the things that can go wrong.

Cary Karp is signed up to be a very strong supporter, writer. We have a very substantial fraction of his time. And several other people are in the process of being signed up and we expect to kick this off rapidly. We're sort of halfway there.

So the time line says gather the team in this month, inventory the questions over the next couple of months, review the progress. I expect there will be visible -- externally visible reporting in there. A draft outcomes report and a final output in October, including what we're calling a primer for IDNs. This is leaving behind the easier-to-read material.

There is actually -- it's not just a "nice to have." There is actually a very strong linkage between clarity and the security issues, in that we're finding people cannot engage in even relevant policy issues and take the security issues into account unless there is a fair amount of clarity on the technical aspects.

So here's the key goals again. A common glossary, identification of the issues, a level of completeness of identification effort, candidate solutions where they exist, and a range of available spaces for policy-making, including boundaries for areas not to go into.

And this slide covers more or less the things that I've said there. Let's see. And that goes back into the -- to actually -- let me take a pause there. Anybody want to ask a question about the SSAC IDN study? Two, three, four...

Great!

Totally separate: We have heard over a long period of time, particularly in connection with WHOIS policy issues, that registering a domain name and putting your name into the WHOIS database triggers spam. We have also heard people who claim to be knowledgeable about how spam is generated, that that actually isn't where spam comes from these days, and that that's irrelevant. We have not seen any hard data that definitively answers that question or even answers it in some context, so we have begun to do some testing in the usual way. Registering a name, putting it in and doing nothing with it other than having that be and then see how much spam comes. And in an attempt to do it in a reasonably careful, controlled fashion, not just anecdotally, but with some measurements and time frames and so forth. So that's the -- the basic methodology. We want to prove or disprove that publication of WHOIS data results in more spam than when the WHOIS data is not published. Whether or not various protection mechanisms in WHOIS mitigates spam. And whether or not registrar or domain name are significant variables. So does that matter, for one reason or another. One could imagine, for example -- and I don't know whether this is -- has any validity -- that when you register your name through registrar X, that those names get turned over actively, perhaps, to spammers, whereas if you register through registrar Y, you just get put into the WHOIS and you get much less spam. So that's a possible hypothesis. I don't know whether that has any validity or not but that's the kind of thing that I'm referring to here, when we talk about whether the registrar matters.

And then with respect to whether the domain name matters is, if you register, say, a com, does that give you more exposure or less exposure than, say, if you register dot info or dot pro or something like that. Or any of the country code names.

Here's a matrix of some of the other variables. Whether it's a proxy or not a proxy service, whether it's protected or non-protected WHOIS, and to check on that.

So that's the -- the broad picture for the WHOIS study, and those are the things. We have a number of other topics that are in even earlier stage of discussion. We had a quite good interaction with the ICANN staff Monday evening, sort of opening up broader lines of communication between the committee and staff. Staff has grown and there's a lot of people who have not had contact with SSAC, and as the ICANN staff is growing and trying to iron out its procedures and build smooth operations, we're trying to provide a good opportunity for them to choose to interact with SSAC when it makes sense and understand what we can and can't do for them.

Anything that I can answer for you? Any questions that you want to bring up? I was expecting, actually, a hard question on IDNs. It went away? Where did it go? Let's see. I can even remember -- I thought -- I wanted it on the record, actually. Daniel Kalchev from Bulgaria was here in the previous section and wanted to understand what the process would be for being able to test whether IDNs could be operated in the top-level domain, so, for example, Bulgaria, just to pick on him because he asked, uses Cyrillic and they would like to have dot BG in Cyrillic as a separate domain. The Greeks presumably would like to have dot GAMMA RHO, I would imagine, and have that set up and then test whether or not that has any traction. Veni Markovski.

>>VENI MARKOVSKI: Actually, because I was at the discussion on the IDNs that we had with Tina Dam and Daniel was there and Vaggelis, the Greek ccTLD was there, the problem with the Greek ccTLD is even more difficult because they don't want to have GR. They want to have the name of Greece in Greek, which is a letter, so they wanted to have any -- to have it two different ways, capital letters and small letters, because these are different letters. So that was their question that they put to Tina, and one of the concerns was for the SSAC will say for that, because with the Cyrillic, it's kind of a little bit easier because obviously the country codes could be like RF in Cyrillic for Russian federation or BG in Cyrillic again for Bulgaria. So the question which they had and which obviously Daniel asked in the previous session is whether it's possible to have a test for the text, say, three years in some of those top-level -- country code top-level domains and whether these IDNs could be implemented in the root servers, because what we hear was that -- what we heard was that -- what they were told was that at least six of the root servers said that they cannot do that.

>>STEVE CROCKER: Really?

>>VENI MARKOVSKI: With -- at least with the Greeks.

>>STEVE CROCKER: Bill?

>>BILL MANNING: Actually, your panelist will take that one.

[Laughter]

>>SUZANNE WOOLF: Wow! Redirect! Except I was raising my hand.

I think I know what Veni is talking about, and it's actually one of the really interesting underlying issues about IDN. I'm sort of going to do a little bit of a deflection because RSSAC is working on a consensus statement to go to the board and the public, and I don't quite yet have permission to deliver that.

But what I think you're referring to is there was a specific discussion in the context of DNAME as a specific mechanism for deploying IDNs. What has since been discussed and how that has since evolved is that's not specifically under discussion at this time, which leaves the only specific mechanism we've been asked about is supporting standard delegations NS records, which is no problem.

As the community goes forward and looks at what do they want, if it turns out that there is a requirement for which DNAME is the answer, at the time the question was asked, not all of the root servers were running software that would properly manage DNAME, but as -- I think it was before you came in, we were talking about v6 deployment and DNSsec and a bunch of basically modern DNS extensions that go together in the software bases that the root name servers are all now running.

So should the community decide that's needed, I'm sure the need can be met, but as I understand the current situation, there has not yet been a decision, there has not been a requirement made that that's needed. And my colleague looks like he wants to add something to that.

>>BILL MANNING: The answer to the question -- do you need this?

>>STEVE CONTE: The Webcasters do, those watching on the Webcast.

>>BILL MANNING: Okay. So all of my Web audience...

The answer to the question is that the -- all of the root name servers are running software which supports DNAME without trouble today. If we were asked to support DNAME for whatever reason, that would not be an issue.

>>DAVID CONRAD:.

[Speaker is off microphone]

>>BILL MANNING: I'm sorry. Would you use the microphone?

>>DAVID CONRAD: It's not worth it.

>>BILL MANNING: Okay. The IANA general manager asked the question: You mean NSD supports DNAME, and he's referring to a specific DNS software implementation. The answer is: We have been told yes.

>>SUZANNE WOOLF: Yeah, but I think the take-away point is that the requirement would need to come from the community and such a requirement, should it come from the community, I'm sure can be met.

>>STEVE CROCKER: Good. Any other questions on this or other topics for the SSAC. In the back there.

>>HANSANG LEE: I'm not sure this might be relevant to this, but I think it should be. Did you have a study of putting in Unicode or UTF-8 into the root zone?

>>STEVE CROCKER: I'm not sure I completely under -- did we or do we plan to study putting in UTF-8 into the root zone? Is that the question?

>>HANSANG LEE: Yes. If you have, I would like to know, or if you didn't, if you have a plan in the future.

>>STEVE CROCKER: So my understanding of the way things are arranged is that UTF-8 is a way of representing IDNs, but the -- the ground rules for the root zone and for most of the DNS zones is restricted to letters, digits, and hyphens, and, say, the bridge between that is to transliterate or translate Unicode into letters, digits and hyphens. That translation results in a subset called Punycode. I'm on the learning curve here, so I want to -- I want to check to see whether or not what I just spoke is accurate. Have at it. I'm here.

>>SUZANNE WOOLF: No. I think it -- no, I think you're right. I think what's being looked at for the root zone is Punycode that is a translation of whatever representation is determined to be most adequate for the community's needs, but not changing the standard for what is allowed in the root zone. You know, legal host names under the DNS protocol. Frankly for reasons of backwards compatibility with the global installed base. And I'm seeing Thomas standing up in the back and wondering if he has something to add.

>>THOMAS NARTEN: Yes. This is Thomas Narten here. I guess I don't quite understand the question, because the direction for IDN -- I mean, for IDNs is to use the IDNA protocol which calls for ASCII in the zone, in the DNS, and no changes to the DNS, so the idea of putting Unicode into the root doesn't make sense from a testing perspective because we're not interested in testing that. That's not the solution that -- you know, the standards-based solution that we've been working on for the last five years.

>>STEVE CROCKER: Yeah. So there's a strong direct answer. Other questions? Good. The -- I mentioned RegisterFly at the very beginning. As I would expect most people have some rough idea of what the situation is, RegisterFly is a registrar that got into an awkward state. A number of registrations lapsed. Quite a lot of complaints. It's become a big area of contention. ICANN has issued a formal notice of loss of accreditation, and there's a process of trying to transfer the registrations to others. SSAC doesn't operate in a time frame where we can actually get involved in the details of all that in any realistic way. What we might be able to do -- and I'm not sure whether or not there aren't already plenty of cooks in this kitchen, but is to take a look at the interaction of the entire system, the set of agreements and technical processes spanning the registries, the registrars, the resellers, the registrants, and ICANN, and ask from a -- sort of from an engineering perspective where the failure modes are and where the recovery processes are. If, for example, it's predictable that there will be a certain number of failures of this kind, just because of the number of players involved, and if we can characterize what kinds of failures those are, so when a domain name goes dark, that has a very big impact on the registrant, for example, and if the only way to fix it is to send in a complaint, take it to court, wait for the complaints to go up to the level where ICANN removes the accreditation, that's not so helpful from a registrant's point of view when he's out of business in 24 hours.

Those are the kind of questions. I don't know, as I say, whether or not there is a need or a utility for us to get involved, but if we did, those would be the kind of questions that we'd be looking at. To try to match the recovery mechanisms and alert mechanisms with the set of issues that actually are in the system and sort of viewed from that perspective.

Okay. We have -- oh, I apologize -- exceeded our 7:15 target here. I think I'm going to bring the session to a close. Thank everybody for coming. We're open for business and we'll see you in Puerto Rico. Thank you.