ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>CHRIS DISSPAIN: ...of the ccNSO. Short day today. Today we have got basically technical -- a technical update on -- sorry. I will start again. An update on the ccNSO Technical Working Group from Eberhard, followed by our usual session with the IANA crowd. Then we will break and we will have our council meeting, to which you are welcome to come if you would like to.

And then that's it.

This afternoon, for those of you who are around, two things.

There is a meeting to discuss meetings. Susan Crawford has put out a paper on the structure of ICANN meetings and there is a discussion about that this afternoon. There is also an IDN meeting this afternoon.

So for those of you following on from our discussions on IDN.IDN yesterday, if you can possibly go to that, that's probably going to be very worthwhile.

But for now, ladies and gentlemen, Eberhard Lisse.

>>EBERHARD LISSE: Good morning. This is the second report of our little Technical Working Group, which ICANN management seems to think of a best practice workshop, which we are not.

We are the technical information gathering and sharing working group of the country code name supporting organization.

Following from a council resolution in Wellington, this was set up to basically gather practices that work, policies that work, policies that don't work, a bit of software, and then come up with a handbook which is nonbinding.

I couldn't make it to Marrakech, but Dave Archbold very ably presented there. I listened to the audio. I was very impressed. And so we carry on from there.

In August, we basically went on leave.

Highlight of the month was that Olivier had the baby.

[ Applause ]

>>EBERHARD LISSE: And in September, a few demand on leave.

It has come to my attention, and from a purely professional perspective, that Kevin Brown had a baby in September

[ Applause ]

>>EBERHARD LISSE: And Bart, I think, also, but I don't know whether it was in August or --

(Laughter.)

>>EBERHARD LISSE: So no official member had a baby?

At least not to my knowledge.

So in October, we started to organize this technical workshop that we are going to have tomorrow. It's an initiative by Bernie Turcotte from CIRA. He came up with the idea, and then Norm Richie, the technical person, started to implement it together with me and Dave Crocker by a few phone calls and a number of e-mails.

Funding for this is basically by CIRA. This only impacts on the food and the booze tomorrow evening.

It is held in connection with our ICANN meeting, we all notice. And in November, our group actually started to work a little bit. We were talking about an outline and we have come up with an idea. We found it -- I personally found it very difficult to find a base of departure, how to start.

It strikes me in the president's report of ICANN he had a similar problem that some people, many find it difficult to start an issue. Where do you start from?

We found something we are very confident we will come up with a table of contents and then we will fill this with information.

The plan at the moment is to concentrate on small ccTLDs and medium-sized ccTLDs. That is quite good for undelegated domains or domains where we don't know who runs it. That might be redelegated of domains that need help, and larger domains that need to implement their automated registry type of thingy. And it might even be helpful to some gTLDs who will start -- which will start up from scratch and business model-wise, it's probably not too clever to source out every part of the operation to commercial companies because it impacts on revenue.

Okay. We had a face-to-face meeting. We basically sat in the bar over there, that side, and we are having this technical workshop, which is tomorrow. And our members are listed here. And just one little issue. This is -- the one in red is the one person I have not met yet. I don't even know if he is a boy or a girl.

Slobodan Markovic is from the dot YU registry, who is now changing over to a dot IS registry, so we feel this is a good showcase to basically keep a diary of what they are doing and to put this in so we can see what impacts on policy, what policy impacts on their technical issues and so on.

And as usual, for the Norwegians the disclaimer. Not just for them; for me as well. I find that some people who are not really involved in the politics here, they say, "Ah, best practices." However, this is a bad buzzword so we try to not mention it.

In the end, it is a best practice thing. It basically describes what has worked, what hasn't worked so you have a handbook where if you start or you scale, you can see what you need to do.

Dot IS is a good example in point. Up to now, they were a registry where they did not charge anything. Free registrations.

You have to charge at least something because otherwise you end up with a lot of domains that are just left and nobody takes care of them, and they occupy servers and make problems. If they don't resolve, lane delegations, et cetera. So you at least want to send them a ten dollar or one Euro invoice to find out whether they answer. And if they don't answer you suspend, and if they don't answer on that, then you can take it away.

But the problem is accounting software. If you have an automated registry, how do you wire this into accounting software. Accounting software packages are galore, but none of them really works on our particular subject.

From my own private practice I use an open source package, SQ Ledger, and that we have put into our semi-automated system, because it's written in Perl and you can drive it from software on API. And that works very well, and we are very confident that whatever EPP-based registry we eventually are going to implement, once I understand how it works, that we will drive the invoicing semi-automatically.

Maybe we still have to do due diligence because of the I.T. implications, but still this is something that at the moment I haven't seen really implemented well in any center.

So that's it. I didn't want to bore you as much as the IANA group is going to, so....

[ Laughter ]

>>CHRIS DISSPAIN: Thank you. Thank you, Eberhard.

>>: Thank you for your consideration.

>>CHRIS DISSPAIN: Does anybody have any questions for Eberhard?

There's one at the back there. I can't see who it is.

>>: Calvin.

>>CHRIS DISSPAIN: Calvin.

>>CALVIN BROWN: Calvin Brown. Just a quick one. How can people assist you and make input into the process?

>>EBERHARD LISSE: The best thing would be to post it to the ccTLD discuss list. You can post it directly. But the mailing list of five, six names is closed.

Anybody who wants to join the mailing list is more than welcome. We have this concept of lurking. I am lurking on the IANA working group.

We are not that formal that we only allow members.

As you know, ICANN and we are an open, transparent, bottom-up organization.

So if anybody is interested in what's going on from a technical, or whatever, perspective, just let us know. We will make a plan.

If there is input, just send it to the ccTLD list or send it -- we have an address. I should have put it on here. I can put it again on the ccTLD lists, what the e-mail address is if you only want to send intellectual property to the group.

>>CHRIS DISSPAIN: And we'll publish, when there's stuff for discussion or you want people's input on them, we will put that out and publish it on the Web site, et cetera.

Hilde.

>>HILDE THUNEM: Okay. Hilde Thunem from Norway. My question has partly been answered but it's a sort of general plea that could we please have an overview of which work groups does exist on the Web site and have sort of what they are working on published --

>>CHRIS DISSPAIN: Yes.

>>HILDE THUNEM: -- when it comes. Because I have been looking around.

>>CHRIS DISSPAIN: We try to keep it as secret as humanly possible. It's one of the things we are going to fixing within the next -- After Christmas we will fix the Web site so it is actually useful and provides information, which it currently doesn't.

>>HILDE THUNEM: Thank you. That would be very good.

>>EBERHARD LISSE: I must say I never thought I would defend ICANN in this regard, but we didn't really have anything to publish this time.

>>: (Inaudible.)

>>EBERHARD LISSE: The agenda is more or less posted on our Web site, on the ICANN meeting Web site.

In the morning, in the morning there will be a few showcases, some ccTLDs represent their technical setup. And in the afternoon we will have a DNSsec issue and Dave Crocker will do some live demonstrations. I understand that, for everybody who hasn't seen it, it's very interesting. Once you have seen it once or twice, it's probably not as interesting anymore. But I understand it's quite interesting to see this, and in the afternoon we want to discuss some issues, they are listed, of a technical nature. For example, Norm Richie brought up the idea of having a collaborative secondary to make redelegations, for example, much easier.

There is currently still some domain names delegated to the DEC servers, D-E-C, from Digital Equipment Corporation. And there are some issues with the technical side because they allow zone transfers so you have to redelegate them. So one idea could be to have a secondary name that is then anycasted to as many secondaries as you want. So if you use that as a secondary, you don't basically have to attend to this matter again.

That's what we want to discuss, whether it's a good idea, for example.

>>CHRIS DISSPAIN: Thanks. Peter.

>>PETER DENGATE THRUSH: Peter Dengate Thrush, dot NZ.

I'm interested in outputs. Are you going to be producing outputs on a topic-by-topic basis or are you going to wait until you've got some assembled list of things? And when might the first of those be?

>>EBERHARD LISSE: We are going to put very nice keynote or PowerPoint reports for every ICANN meeting. We haven't really discussed it. If we find we have a chapter that is more or less final we can post a draft to the Web site that people can read it and provide input so we make it up as we go along.

>>CHRIS DISSPAIN: I think that that's probably right. I think provided that the topic that the chapter is on can stand alone to be looked at, then it gets posted bit by bit rather than waiting for the whole thing to be completed.

Okay.

Thank you, Eberhard. Thank you very much.

Can I get Kim and David and Olivier to come up and start boring us on IANA, please.

Olivier. Oh, you are coming. Good.

Just the technical -- tomorrow's technical workshop, the agenda is on the icann.org/meetings/saopaulo. There aren't any actual times of when the sessions are but the actual names of the sessions are there.

>>: This is set up to only work on mine so Kim cannot sabotage.

>>: Absolutely.

>>CHRIS DISSPAIN: Okay, thanks everybody. We are going to start with a presentation from Kim Davies, presumably on IANA updates.

>>KIM DAVIES: Hi, everyone. Okay.

So, good morning.

I'm here to give the routine IANA update. I will try to get through this quicker than I normally would simply because Olivier has asked to take half of my time slot. So without further ado, I am just going to briefly remind you that the IANA contract is being renewed, tell you about development work we have been doing both on our systems and processes as well as on our policy, and then just give some other brief updates on our staff and other things we have been doing internally.

The IANA contract was renewed for one to five years on October 1st. So we're now in a new contract period with the U.S. Department of Commerce. That contract now runs from October 1st, 2006 through September 30, 2007, extendible by one year increments up to 2011.

It contains basically exactly the same obligations. However, we foresee, as we evolve IANA, introduce things like eIANA that there will be amendments to that contract through the life of it.

So while the language hasn't changed, it certainly doesn't mean we are bound to stick with exactly what it says for the next five years.

There is also the new joint project agreement between ICANN and the U.S. government as well. Whilst that doesn't really directly affect IANA, it is certainly another notable event in the history of ICANN. And I'm sure those of you that are interested can probably sit through other meetings that will go into that in great depth. But suffice to say that JPA lasts for three years with an add-in month review period.

So on to our development work.

Statistics remain steady. I'm not going to show you the graph but it's available -- the latest graphs are now available on our Web site so you can go have a look if you like. Those of you who have been to a few of my presentations will remember it's basically a steep decline and then it's basically holding steady for the last six to 12 months. But what I am going to talk about now is an improved statistical method that ware working on and we should be soon accomplishing for root zone management as well as all of the other IANA functions that we undertake.

So just to illustrate the current statistical method that we have.

It's really relatively crude. At the moment, and just to take a hypothetical request that is sent to IANA, one that arrives on September 3rd and October 10th, we simply measure the average duration of transactions from beginning to end.

As you would probably know, those that deal with IANA, interactions with IANA are a bit more complicated than that. But for the moment, that's really what we show in our statistics. So that shows the total time of, say, 39.8 days.

But through the life of the history, you send a ticket to IANA, IANA might tell you that their form is filled out incorrectly. We send it back. You reply, you send it back to us. We send confirmations to the administrative and technical contacts. The administrative contact responds. It turns out the technical contact is on holiday that week, he responds the next week. One of the name servers isn't responding correctly. We speak with technical people, get that fixed. I mean, there's a whole bunch of things that happen in the life of a ticket.

At the moment, that all counts as IANA's time. So what we would like to do is move to a new model whereby we account for all the different state that a ticket is in through the life of the request.

So you'll have data on how much time did it actually sit in IANA staff hands, how much time did it sit in the requester's hands and all the other involved parties.

The aim is to make it much more transparent for us as well as all the other parties so criticism or applause can be pointed in the right direction. And I think it would be better for you to judge us on how we do our job. Once you know exactly how much time we take, we can no longer hide behind our stats. At the same time, we can be honest about why it takes a certain amount of time.

So we would add up the total sum of all the different color-coded parts on this graph and we would see, for example, IANA took 13 days, request is 16 days, D.O.C., Verisign. The board is only involved in redelegations, but sometimes it sits with the board as well.

So the next improvement I want to talk about is software development. We have been working on the work-flow automation based on the eIANA software. We have been working on improving our interface with VeriSign.

We have been working on procedure developments. In essence, trying to review our procedures, work out where they can be improved with a particular mind towards improving efficiency.

We started with technical checks, and I will also talk about authentication mechanisms in a moment.

On to root zone automation. A substantial amount of the front-end work for the Web, the eIANA software has been completed. It's a wizard-based interface that hopes to guide you through the process. In effect, people use IANA once or twice a year at most, if not once or twice a decade. And whilst people that attend ICANN meetings are intimately familiar with how we do our job because there has been so much analysis of how we do our jobs in the last couple of years, the majority of ccTLDs don't really know the processes, don't understand some aspects of it, and really the aim of it is to make it intuitive enough that if you don't follow ICANN affairs, if you are a ccTLD manager that hasn't updated your details for eight years, then it should be relatively simple to do.

Another deliverable is you ought to be able to see the status of your request. While the request is in progress, go to the Web site you and see what the delay is and work out what's happening.

We are working with NASK, the developer of the eIANA sample software. As I mentioned before, eIANA is the base software for the project, so the aim is to leverage off of that and the whole system will be based on that code and have things added to it.

So I'm going to give a brief demonstration now of the interface to eIANA as it stands.

So I will just switch windows.

So I will try to make it fit.

So this is the log in screen. Our log in. It's not very exciting.

And I'll just note that the wireless here is delaying it somewhat, so my apologies if it's not zipping around.

Okay. So this is kind of a sample account. It's not -- It's actually real data that we pulled out of the database several months ago. But it's just for demonstration purposes. Obviously, presumably one account won't be able to edit every single domain.

You will get access to your own domains. If you operate more than one ccTLD in your registry, you will get access to all the domains for which you are responsible.

But if I do a sample edit of a domain, I will show you basically the process of logging a change request.

>>CHRIS DISSPAIN: Just leave Australia alone, please. Don't -- You don't have the right to touch Australia. Get out of there at once. Get out!

[ Laughter ]

>>KIM DAVIES: If I stop and choose something else, we waste more time.

(Poor audio.)

>>KIM DAVIES: Until you are satisfied you have captured all the changes. So you can make changes to different fields, all in the same ticket, without lodging multiple ticket.

So let's go, say, we want to change some name servers at the same time. So we can scroll down. Go to the name server list, go to edit.

So here we have a list of name servers, and let's just do a couple of changes.

Let's remove University of Melbourne. So we just hit the delete button. That will disappear.

And let's say we wanted to add a new name server as well. So let's say we added NS dash AU dot RIPE dot net. 103001. Hit change -- hit (inaudible), sorry.

This will give you more space to add more name servers if you need it.

Let's say that's it for now so let's just hit save changes.

Now it's not showing very well on the projector, but it's showing very well on my screen. The change -- If you scroll down the list, the actual elements that you have changed are highlighted. So this part here is highlighted to show that the address you changed is different. And if we scroll down a little further, it actually shows you what you have removed and what you have added in different colors.

So you can visually see what exactly am I changing before you submit the request. I think it's an improvement on what we do today. It gives you a sense about what you are about to launch and once you are happy with it -- firstly, if you are not happy with it, you can completely back out by hitting cancel. But let's say we are happy with what I have done so we hit complete.

So it comes up, too, with a screen, describes exactly the changes you want to make. Saying that I want to alter the address, I want to change the e-mail, phone and name. It says I want to remove name server from University of Melbourne and I want to add a name server for RIPE.

And if I am not happy, I can go back and change it some more. If I am happy, I can proceed.

Now the current policy means that some changes take longer than others. So we have introduced a check, and if the system thinks that there is likely to be a longer time for parts of change than others, it will actually wish you do you wish to split this into two separate requests. So it explains why, gives you the opportunity.

So let's say yes. The name server change is going to be longer than the address change. I want to do both but I want the address change to be quicker. So I can go yes and hit proceed.

I should note that there's technical checks involved here as well, but that part is not yet developed. So ideally, when you lodge this request, it would now be checking those name servers, making sure they are authoritative. It will come back you and list areas. So basically the idea is you remedy any technical areas with your application before IANA even sees it.

At the moment when you send in a request, we do checks manually. We send you an e-mail back explaining what errors, and it takes a bit of time back and forth.

This system will tell you what the errors are immediately, you can immediately fix them, and it doesn't waste any unnecessary time getting them fixed.

But anyway, this is what happens. Two change requests being logged -- lodged. You are given reference numbers. As you can see it split it up the requests into the name server request and the administrative contact request, and that's basically it.

Now, if I can scroll -- There should probably be a button at the bottom, I think, saying go back to the menu but I will just hit it up here.

So if we scroll right down, it's going to take a while again, but you will be able to see your ticket is in progress. It will show you the status of the ticket. You will be able to come back in a few days and see what's happening with your request.

Our aim is to automate as much as possible the elements that at the moment are manual.

There are still parts of IANA that are manually processed but this should reduce as much time as possible for the evaluation of a request within IANA.

This is all a bit slow, so I'll just leave it at that.

If anyone is interested in more details, feel free to come up to me.

It's still a work in progress. We are working with NASK. We have our own Java developers as well working on it and we are hoping to have this ready for public consumption soon.

Okay. So -- sorry?

>>: (Inaudible.)

>>KIM DAVIES: So I will move on to the other things. Check the time.

Improving root zone efficiency. Obviously the system is one key part of it.

Another part that we have identified that can be improved in efficiency is the way we communicate root zone changes to VeriSign.

VeriSign at the moment is the implementer of actually editing the physical root zone file and distributing it to the root name server network.

At the moment, it's done via a PTP signed e-mail transaction that involves both the D.O.C. and VeriSign.

We are working to a model where IANA will actually conduct an EPP transaction with VeriSign.

At the moment, we're developing schemers, extensions for EPP that communicate all the required data for a root zone change, and we're working productively with VeriSign on getting that working as well.

So hopefully this will shave a couple of days off almost every name server change request.

So coming back to my little graph from earlier. And I'll just file through this.

These are all the areas that I think, in terms of a general transaction, that both software and policy will help reduce the times on. So software will help shrink some of the green delay, which is IANA staff time. It will also -- Changes in policy, which I will discuss in a moment, will reduce some of the other evaluation times as well.

Okay. So next topic is our 24/7 support service. I think I mentioned we're just about to launch it in the last meeting in Marrakech. It's a mechanism for ccTLD operators to contact IANA at any time. It's only for emergency use only. Hopefully, you won't call that just because you want to have a chat, but if there's something that requires IANA attention that is urgent and immediate, then that's what this service is for.

It's basically for problems that a root zone change will help fix. Obviously there's other issues that we can't really help you with, but if it involves a root zone change, it needs to be done urgently, this is what this service is designed for.

When you call the number it actually goes to a call center which is based in the UK. They will take your name, number and details. They will contact a roster of IANA staff until they find someone that is available. They have a list of -- I think it's like ten people and goes all the way up to Paul Twomey's mobile phone. So if no one is available, it kind of escalates right through the company.

So you could be relatively sure that someone will get back to you.

There's no guarantee that we can give you a 24/7 fix, though. I should make it clear. Because we're not the sole party responsible for editing the root zone, we are relying on the D.O.C, we are relying on VeriSign, we are relying on root server operators, we can't promise you that if you call at 3:00 a.m. that by 4:00 a.m. your change will be made. But we will do our best to get our part done as quickly as possible. We'll try and contact all the responsible parties to get a change request expedited, but we can't give any kind of guarantee.

So for those that don't have the number already, that's the number. That will go to our call center, and please keep that as a reference available for you to call. Again, just for root zone emergency changes.

We have had this available since the 15th of July. Apart from routine testing we do internally to make sure the system is working, we haven't had a single request yet.

As a note, the IANA office will be closed from the 24th of December to the 2nd of January. Because we all love the Internet so much, I'm sure that we will be checking root zone requests every day.

That being said, unless it's really urgent, it's unlikely we are going to be sitting there and doing all the usual work that we do.

If we notice there is some emergency aspect to it, we will do it, but if it's a real emergency we suggest you call that number to make sure that someone realizes it's very high priority.

So policy reviews. As I mentioned earlier, technical solutions are only part of improving the speed and service of IANA.

The other part is identifying deficient -- perhaps deficient is a strong word, but policies that can be improved that will help make things go quicker, make processes more clearer. And in line with this we have launched a few policy reviews.

We launched one a couple of months ago, the technical check policy. We have actually launched two yesterday.

The technical check policy, the aim is to create an unambiguous operational procedure on what technical checks IANA will perform.

The aim is to make them as objective as possible, so once they are decided, we can implement that part in the eIANA software so that all the technical checks are done as you submit your application.

We released a discussion paper in mid-August 2006. We got quite a number of very constructive comments. We are currently in the process of absorbing and filtering those and creating a draft new procedure.

We actually had sort of a workshop session at the CENTR technical workshop in Amsterdam, and there we spent a couple of hours discussing the pros and cons of various approaches, and I found it very useful.

So we'll create a new draft procedure. There will be another opportunity to comment, and then hopefully we will introduce those out as our operating procedure.

Just quickly, the aim is to make the mandatory warnings at the moment, implement it in such a way that you will immediately get feedback during the process that you can't submit an application with such bad errors.

If it's just a warning, which is the kind of error which it is good to fix but they don't hold up a request. Instead of resulting in a back and forth of e-mails between IANA and the requester, the Web site will simply say what the error is, why it's important. And if the requester believes that it's okay to proceed, they can still force through a change.

Finally, and I haven't explained it in detail but there is some disparities between technical checks VeriSign does and technical checks that IANA does.

At the moment, that can cause some delay. The aim with this policy is to make sure that no such disparities exist so there is no possibility for delay at the very last stages.

The most interesting thing I think that I am going to announce today are two policy reviews that were placed on our Web site just last night. Firstly we are revising the root zone blue policy.

At the moment, if you have a name server that is shared between, let's say, 36 different ccTLDs, we require basically 72 people to agree to a change because every change to the IP address in the name server requires every single affected administrative and technical contact to be notified and to agree to a change.

In practice, this has meant that changes can take weeks, months, even over a year to be implemented because not every ccTLD operator is responsive to IANA.

We want to fix this. We think that that's probably the number one impact on our overall average processing time simply because you certainly have requests that last months affecting 36 different ccTLDs, and it really kind of affects our averages, so to speak.

But more than that, it's just -- it's bad for the requester, it's bad for the name server operator. They want to update their name server to a new IP address. They shouldn't have to wait a year.

So we're putting this out there for discussion. Your contributions are very welcome. There's a discussion paper that explains the issue in more detail, and invites feedback on what an appropriate policy would be.

On the 26th of September, 2006, two new ccTLDs were born, following in on the birthing theme.

The ISO 3166 maintenance agency created ME for Montenegro and RS for Serbia in this standard. We introduced them into the IANA database as reserve.

At the moment there are no operators and they are basically now free for eligible operators to approach IANA with delegation.

>>: (Inaudible.)

>>KIM DAVIES: There's no request to IANA, and IANA hasn't performed any evaluations on possible operators.

The interesting question is we're transitioning from a domain that serves basically two countries now to two domains that serve two countries. And one of the interesting questions will be how those two countries manage the transition to those two different codes.

And that leads me into my next policy review, which is the ccTLD sunset review.

I mentioned this in Marrakech, but there's a lot of -- not a lot, but there's some long-retired ISO 3166 codes still in the root. What we need is a predictable method for removing those ccTLDs from the root, bearing in mind that there are stability issues, transition issues. The users of the old domains need to move to the relevant new domains.

Current, there are two or four domains that are affected by this. Most immediately, there are two. Dot SU, the Soviet Union, has existed for quite a few years after the dissolution of the Soviet Union. And East Timor has moved from dot TP to dot TL, but they still use both domains.

Dot YU is still the active domain for the affected country, so whilst this will ultimately be affected by whatever policy we have for this, it's not an immediate concern.

And similarly, and perhaps uniquely, dot GB is in the ISO list but dot UK is being used by that country, so it might be appropriate that this policy be address that specific issue as well.

Again, this issue is talked about in more depth in a discussion paper on our Web site. We very much welcome contributions.

Both of these discussion periods will be open until the 31st of January. After the conclusion of those comment periods, we will be writing staff papers, exploring the comments, discussing what an appropriate draft policy would be, and there will likely be -- there should be a second round of comments on that draft procedure.

Future procedure reviews. Most of you will know our plan is to introduce what are called RSA, secure ID keys. They are hardware tokens. It will be an optional service but ideally we would like every ccTLD to use them to increase the security of interacting with IANA.

But along with that we need a security policy on how we give them out, how long are they valid, key management principles. And I believe that that will likely be a procedural review as well.

One thing I don't have listed here but I think next week we will probably announce a review of the dot INT policy. Dot INT is run by IANA for intergovernmental organizations, and we'll be reviewing the eligibility policy for that domain.

And as we identify more areas for review, we will also be putting out discussion papers.

So some other quick updates from IANA. This is the staff overview for the moment.

Michelle Cotton who is the longest serving IANA staff member, she has been promoted to the role of protocols liaison. That involves basically dealing as our interface with the IETF.

We also welcome this week Leo Vegoda. He previously worked at the RIPENCC, and he is now working with us as our numbers liaison which involves IANA's relationship with the RIRs. On top of that we also have the regular staff, and our administrative assistant position has been filled more permanently by Amanda Baber, who previously was working with us in a temporary capacity.

Above and beyond our permanent staff, we also have a number of expert reviewers. These help us with very specific technical questions. Primarily relating to the IETF.

So we have to deal with all the gamut of protocols that are available in our IETF role, and these expert reviewers who are part time specialize in different fields and give us great technical insight into what's necessary for that role.

Regional liaisons. I wanted to point out we now have a regional liaison for the Pacific. He was at the most recent APTLD meeting, and those of you in the Pacific are very welcome to get to know him. His name is Save, and I can certainly introduce any of you to him who are from that area. And obviously Giovanni Seppia from Europe, Baher from the Middle East, Anne-Rachel from Africa, Jacob Canada and the Caribbean, and Pablo from Latin America are basically local contacts within your region who aim to be more familiar with local matters to you, as opposed to IANA which has a very broad view of the world.

IDN test in the root. I just wanted to point out that IANA is involved in this procedure. Primarily we need to develop -- we are going to insert test labels in the root. IANA will have procedures for that, and of particular note, there will be a new policy on emergency revocation.

What this means is there will be some procedures that will allow almost immediate removal of domains from the root. If they are a test domain and they are causing some kind of technical damage, it's basically a safeguard in case something really bad happens. We are not here to put in the root. We need a mechanism by which we can take them out very quickly without the usual write a board report, wait for board approval, get a vote, all that kind of thing. So it will be a very compressed emergency revocation procedure. It won't affect the ccTLD, but it will be a new IANA procedure.

I just wanted to talk briefly about the registry services evaluation procedure. More specifically, the dot name.

Many of you were contacted about your two-letter country code being available for registration under dot name. There was a technical review of that -- of what the technical implications of that are.

A report was released just about 30 minutes ago while Eberhard was talking. It's available now.

Its conclusion is there is effectively no technical problem with having those in the root.

There might be non-technical issues, but their evaluation was whilst there is a fraction of a percent that are affected, it's not significant at all.

And that report is quite extensive. I encourage you to read it, if you find flaws in the methodology then there is a public comment forum and we welcome contributions on that.

Just one thing, in terms of internal processes at IANA and ICANN, we have been working a lot on project management. The summer period in the northern hemisphere, which was winter down here, was spent largely training staff on more formal project management procedures. So we have project managers, sponsors, risk analyses and so forth.

I think once it's fully integrated into the company it should make all our myriad of projects much more easier to handle internally.

And I think the end result will be ICANN will be more efficient, and a lot of the things we are required by the community to do, there will be less slipped deadlines, there will be more understanding about what our obligations are and when we need to do them.

IPv6, we launched a whole bunch of IPv6 addresses under the new global policy. We handed out a whole bunch of allocations to the RIRs on October 1st.

For those not familiar with IPv6, these are really large allocations.

The aim is to help spur IPv6 adoption around the world.

And finally, we're doing some additional work that might be of interest to the technical people here.

(Poor audio.)

>>KIM DAVIES: And that's it for me, pretty much. Any questions?

(Poor audio.)

>>: Now ccTLD managers should be written down as ccTLD manager, registrant, ccTLD manager org. I don't care what you actually do put, but when you call it sponsoring organization, it has real implications.

(Poor audio.)

>>: The choice of secure IP tokens seems to be the most awkward one you could have done.

At any one time I can have one of eight people on call who might need to do something so they are all going to need a secure ID token, they are going to need it with them, and yesterday everybody here -- everybody, I'm sure, here, deals with public key cryptography on a daily basis. We can quite easily cope with strong security that doesn't require a hardware token. So why go for that particular method?

>>KIM DAVIES: I think that generally the model has been that the administrative and technical contact is a single person. So we haven't factored in that a whole company would be eligible to approve change requests.

I mean, whilst change requests can be submitted by anyone, we need confirmation from specifically the administrative and technical contact. So I'm not sure -- If there's a requirement within a specific ccTLD for something vastly different, we can implement that.

I will also note it is not the only security mechanism available. I think that we can introduce other alternate security options as well, and we will retain the current method as well.

>>: Okay. So is there a chance we can have PTP signatures?

>>KIM DAVIES: I think so.

>>CHRIS DISSPAIN: Anyone else? Slobodan.

>>SLOBODAN MARKOVIC: Kim, if you could please give us some background details on this discussion paper on retiring Country Code Top Level Domains.

I see it was published yesterday. So I wonder, is there some wider story behind it?

It says in it that IANA has not aggressively pursued the affected operators conclude the commissioning process. So does it mean that IANA is now trying to move more aggressively?

>>KIM DAVIES: Well, I mean, that's the question posed.

The challenge is that IANA has devolved decisions on what constitutes a valid ccTLD to the ISO maintenance agency. So they decide what's a valid code and what's not.

Throughout history, they have removed codes and said that these can no longer be used. But we have inconsistently applied that. As soon as one is added, we make it available, but as soon as one is removed, if I can be general, we have done nothing.

We have advised, whenever asked, the operator they must shut it down. Specifically I know that dot SU was told that they should shut it down by 2004, I think. But we haven't sort of told them -- gone up to them and said here is the date, it's going to go off now. And what we are looking for is a procedure that's appropriate.

And we certainly don't want to cut off anyone inappropriately, but at the same token -- well, by the same token, I mean if you look at CS, it was actually used by Czechoslovakia. It was withdrawn. Let's say hypothetically that YU had used to CS. What happens if Czechoslovakia was still using it?

So there is a risk of conflict and there are also other questions that are posed by the discussion paper. We are not prescribing a particular view, but it seems to me that it doesn't seem consistent to allow ccTLDs to not follow ISO 3166 when ISO 3166 says they must be turned off.

>>: (Inaudible.)

>>KIM DAVIES: No. That's what we are asking for. We want to develop a policy that will have a time line. That's why we are looking for suggestions.

>>CHRIS DISSPAIN: Olivier, you had a question?

>>OLIVIER GUILLARD: Three quick questions. So it would be possible for the ccTLD to see where the ticket is when you send a request exactly in the process flow?

>>KIM DAVIES: It will show the state. So this will have a state waiting for technical confirmation, waiting for D.O.C, failed technical check, whatever it may be. So you will see ticket number, date lodged, current state and so forth.

>>OLIVIER GUILLARD: Other question. You mentioned that you had -- you were using NASK software. Can you say a few words about the arrangements you have with NASK? Is it (inaudible) the software?

>>KIM DAVIES: The software will be available open source. We coordinate the development but NASK is a contractor to us so we have a contracting arrangement.

>>OLIVIER GUILLARD: Okay. And just last point.

(Poor audio.)

>>KIM DAVIES: That was what was suggested by VeriSign as being their preference. Our key interest is making it go as fast as possible. If that's what is best for them, that's best for us.

>>CHRIS DISSPAIN: Just before we move on, thank you, Kim. I think Nigel might have another question but we will get to that in a second, if you don't mind, Nigel.

Susan Crawford, ICANN board member, has asked if she can tell us about her meeting about meetings.

>>SUSAN CRAWFORD: Thank you very much, and thank you for letting me join your meeting for just a few seconds here. My name is Susan Crawford and I am one of the ICANN board members.

I am trying to make sure that we get a lot of information from you about how these meetings are for you.

Many of you come many, many miles, many airplanes to come to these meetings, and there are lots of meeting-related topics that we should discuss. How are these accommodations? How are the participation remotely for people who can't be here? How can we improve how these meetings are scheduled, where they are held? Lots of things to talk about.

This afternoon, at 3:00, I will be facilitating a meeting on meetings here, and I hope that as many of you as possible can come if you are at all interested in improving the manner in which these meetings are held and how constructive they are for you.

Thank you.

>>CHRIS DISSPAIN: Thanks, Susan.

Nigel, did you have another question?

>>NIGEL ROBERTS: Thank you. It wasn't a question. It was a point of information to follow-up on the question of retiring ccTLDs.

Something I picked up from Willie Black around about the time that CS was allocated in (inaudible). Willie and I believe Elisabeth are both members of the -- Willie from the (inaudible) side and Elisabeth from the French side on the ISO committee. The ISOs themselves have a problem with this because they say that a code will be blocked for five years after it is retired from the ISO list.

But libraries, for example, use the ISO code to refer to documents created within the lifetime of that country or territory.

So CS, for example, will live forever as Czechoslovakia. The books, for example, that were written when that country existed.

So that's one thing. And because we, the community and the IANA, rely on the ISO 3166 list, it is something that we have sort of imposed on us because of our decision to use the ISO list.

Another very quick point of information. Some of you probably already know this, but there was an update to the ISO list in March of this year, and GB which you referred to as being a non-used ISO code was redefined. It no longer includes the Channel Islands and the Isle of Mann, and the Channel Islands and the Isle of Mann now have their own codes in the ISO list.

I think this is probably the first case of the two-letter codes moving from the IANA database to the ISO list.

>>: Actually, the ISO committee on the 3166 is only a photography of the current state of the world. Which means if you want stability, long-term stability, for instance, for identifiers like for books or for things like that, for URLs, you need to build the stability on the top of ISO 3166. Which means that you cannot rely on the ISO standard alone. It has already been done, for instance, by the IETF for the language codes, RFC 4646.

There is an IANA-based registry which is inspired by ISO standards, but does not follow them blindly because it can't. So because they cannot be used as a long-term reference.

So my opinion is that it's the same for the country code. We cannot rely on ISO stability or lack of stability alone because, as you said, we use identifiers, which starts from ISO identifiers, but have a very long term -- very long life.

>>CHRIS DISSPAIN: Thanks. Okay, Olivier, do you want to make your presentation now?

>>OLIVIER GUILLARD: Okay. Hear me? That's not the PowerPoint.

Okay. Just before starting, I confirm that I had a baby.

I would like to add that Eberhard didn't catch it, so it didn't mix business with my baby.

Okay. Right.

I try to give a short report about what the progress that has been done through the IANA working group. Try to give you some information about the group.

So if you want and if you are connected, you can go and have a look to the -- at the same time to the Web site of the working group, the IANA working group, at ccnso.org.

There are ten CCs, which a number are not of the ccNSO participating in the working group and the IANA staff is participating (inaudible) dedicated on country points.

Exchange in work is done through mailing lists. We have teleconference. We had, the first month, one teleconference every month, which is organized by the IANA staff.

Minutes, paper, ongoing projects are recorded in the Wiki, so in the Web sites I just give you the URL. And part of the documentation on which we are working on is visible particularly on this Web site.

If you go to the Web site on the home page, you will see that the -- and it's also in the ccNSO Web page. You will see that the scope of the working group is defined in the charter of the working group.

And there is also a list of CC concerns that were identified after the meeting in Luxembourg, I think, where we tried to identify the concern that had, at this time, the community, the CCs, and we recorded them and we trade to address them one by one.

So if you look -- If you go and pick up the document CC0000, it's precisely this list of concerns.

So for the rest of the report, I will base my report on the scope of the charter -- sorry. On the scope of the working group, which is defined in the charter. And try to pick up the different things we have done with regard to those different issues, objectives.

So review of IANA procedure for ccTLD zone file chain excluding redelegation and recommendation to IANA of improvement of IANA procedure for ccTLD rules.

That's better.

For ccTLD zone file change. So if you go to the -- still on the Web site, you have the IANA high-level process flow which is described, so you can see the process, but it was even more described now. So we will be able to update this paper.

You have the process flow that's a demand follow when you send the request to IANA.

The ticketing system has been discussed and reviewed by the working group, and there is a paper describing the discussion we had in the working group about it.

Technical requirement for CC zone and CCNS published in the root-zone file has been quite discussed in the working group, and you have seen probably the consultation that IANA launched about it, for which the ccNSO responded.

To address those issues which are described in this code, they are on-track matters that had been identified but that are still not addressed in the work group, but Kim assured that those had progressed recently. So identification mechanism is something that CCs had asked for and wants to have more information about.

Automatization procedure. We had no information in the working group about it. And access to internal ticket status, we are just seeing that it is progressing also.

Next one. I have put four topics in the same block. Of the report, review of the mechanism for interaction between ccTLDs and IANA, recommendation to IANA with improvement to the mechanism for interaction between ccTLDs and IANA. As well as review of the documentation provided by IANA to CCs and recommendation to IANA of improvement to the documentation provided by IANA to the CCs.

Still, if you go to the IANA working group Web site, you have some related document information. You have a (inaudible) list for CCs which is the list of documents that could be useful for CCs that want to know more about relations with IANA and also CC management, by the way.

You have the organization chart.

In the group, we encourage and support IANA consultation and try to assist and provide also input when the consultation are CC related.

We have reviewed the new IANA Web site, for example. And we have also strong involvement in the discussion related to CC technical requirements.

Those papers that I am mentioning here are publicly visible on the Web site.

Some issues we have in the group to work and to move forward sometime is just to share with you. On this particular topic, we are not always informed of the schedules that -- and priorities of IANA, especially for automatization procedure. We know we have the main objective, we know it's moving forward, but we don't have information about the schedule. We don't always have information about the schedule.

Discussion related to authentication mechanism are still ongoing.

And (inaudible) real-time -- access to real-time information about internal stages of (inaudible) request is also moving forward.

That is still something ongoing in the group.

This is it.

Next one.

Review of the metric used to monitor IANA service performance.

(Poor audio.)

>>OLIVIER GUILLARD: To monitor IANA performance.

>>: Hello.

>>STEPHANE BORTZMEYER: Okay. This is a short presentation of something we do under the umbrella of the (inaudible) project, for now a bit more than three years. As far as I know, no publication of all the IANA data. So what we try to do is to gather IANA published data, and to publish it for people to be able to know what's going on, what (inaudible) and so on.

So what we do, we retrieve automatically the zone file, which is publicly available. And also the WHOIS information for every TLD. It is retrieved every day and archived on the virtual system CVS.

With CVS you get all the history travel function. You can go back in past, you can know what FR information looked like one year ago (inaudible), and also you can very easily check when there is something new.

The zone file is signed, not with DNSsec but is signed with PTP so you can check that it is, indeed, authentic. Retrieve it once a day. It's a very small load on the servers.

All of the data that we use are public data, so there are no privacy problems.

So with that, you can know what's going on. You can be informed, because the software which does it, when there is something new, mailer it's maintainer, so you can know redelegation, when a name server change, when you manage a secondary, which is used for many TLD, it's always useful to know what's going on.

You can see also new trends in TLD management. For instance, a rise of name server compression which is used more and more. I believe that the (inaudible) started to do it a few weeks ago.

And you can also after that read the history and see when a change take place. It's not a complete monitoring of the IANA function because with public data, you see only one part of what's going on. You see the result of IANA work. You do not see the requests, which are not public data.

So it is not sufficient to measure the (inaudible) time of IANA, thing like that, but it is already a good start.

That's how I was about to see this morning that our Czech colleagues changed the name of their organization from CZ dash NIC to CZ dot NIC, and the change was reflected yesterday in the IANA database.

So we started three years ago, so we have already a good deal of information.

Before that, there was similar projects, such as one managed by Elisabeth Porteneuve in WW TLD that gathered for a few years before stopping.

At the present time, the data is not public but the intent is to make it public. Remember that (inaudible) data, origin data was public. So there are no problems to make it public on any input from the ccNSO or other stakeholder about how we should distribute it, in what form, et cetera. Every input is welcome.

Thank you for your attention.

I'm sorry for my accent.

[ Laughter ]

>>: It could be worse.

>>OLIVIER GUILLARD: So as Stephane say, it's not -- Just to give you an idea of what can be done with public information. But as Stephane says, it gives half of the issue of the performance.

When you look at the public information, you don't know when the initial request has been issued. So you don't know how long it takes for every individual issues.

But it starts to give you an idea of what can be done from the outside, review a bit the IANA performance.

Okay. Future of the working group. And now I will give some personal feeling. Just personal, share personal experience, and see where we are now.

So to conclude this report, I believe that IANA working group produces an outcome that is well appreciated by the community. As some people like statistics, the IANA home page is now viewed about 150 times every month. And because of this meeting, I am going to explode the statistic this month, I think.

It appears quite clearly that the IANA management is not perceived as an issue that needs to be addressed by the group, and I would say anymore. In a way. When you remind the story of the setup of this group.

The community seems quite confident in the capacity of the IANA team to manage, appropriately, issues. We have not heard any recent complaint from CC about the IANA management.

And this was also -- This has been explicitly confined within the working group, so there was launch a couple of weeks ago, and it was clear from the members of the group that the IANA management was not an issue that we needed to explicitly address in the group.

However, there are pending issues. There are things that we have not yet addressed and that were planned to be.

Although there is a lot of things to do, I think the IANA working group is a good kernel to address those issue. But I have to see that participants in the group have their day-to-day activities and it's sometimes difficult to ask for move involvement to address all the issue and produce consistent -- a more consistent outcome. We stay in a best effort.

Even if it's quite structured, we have a Web site, we have a mailing list, we have regular audio conference. People have other things to do, also. So we can't address all the issues.

I have to report also that IANA has asked the working group for guidance on certain issues such as redelegation. It's not explicitly in the scope but IANA asked us for guidance on this one.

Also they asked us for guidance on the issue of consistency between ISO 3166 and ccTLD list.

They even have proposed paper to the group, but we have not been able to date to provide to them any input on those issues.

Last thing I would like to -- I would like to highlight is that there is a clear -- It seemed that there is a clear and strong demand from the community to have more readability with regard to the IANA service. That's why monitoring, I think, could help in providing such -- such a need. In contributing, at least, to produce something for that.

And there is also a demand, from what I heard, for having more interaction, clear interaction between CCs and IANA.

So at this stage I see three main needs that would need to be addressed and that have -- that are perceived as having been asked by the community to provide an efficient identified channel, allowing the community to watch an exchange about an IANA manner for CC issues. To provide a clear mechanism to relay formally and efficiently to IANA CC concerns and expectations with regard to the IANA service we receive. And also to support and assist maybe more efficiently IANA in dealing with CC management issue they are facing.

So, for example, providing guidance to IANA on specific issues. Also, we need to check as a community that IANA has the appropriate means to fulfill their work. And assist them for that.

So that's a bit of my report, actually. I have nothing more to add. If there are any questions, they are welcome.

>>CHRIS DISSPAIN: Any -- Okay. Hilde and then Roelof.

>>HILDE THUNEM: Just a quick question. I have actually been to the IANA working group. Like Gordon, I think it's brilliant because it gives an idea of what's going on in the working group. But I still want to ask the question of how do the rest of us participate in this? How do we participate in bringing these issues forward, come with input as a community? Because currently, there's a working group of eight members or something, regionally defined. And I might start to be serious about the Scandinavian region if I have to sort of go by region to be able to give input.

>>OLIVIER GUILLARD: I hear that. First thing, if you go to the IANA working group Web site there is e-mail that is published and that can be used to send, to contact the working group on particular issues.

But as you -- I hear that. Initially, the working group was set up in Luxembourg, I think, with ten members, and we -- ten people. The basic idea was to set up a working group not too big, because if you are -- Everybody wanted to participate. If you have a too-big working group, you don't produce outcome easily. It's more difficult to organize -- to organize the logistic, to have, for example, audio conference and things like that. And if it's too little, it gives the impression that you can't participate.

So I hear that. We are going to review a protocol for the working group to renew member. But maybe we could start --

>>HILDE THUNEM: I certainly see the point of not -- or the logistics problem, and I wouldn't necessarily have a big problem with a kernel of dedicated people trying to work on the issue, but I seriously want to stress that it should be open to everyone to come with input, and to be able to do that, we need to know what you are working on at any current time so that we could send out input as a member without being a member of the working group.

>>CHRIS DISSPAIN: I agree with that. I think isn't that the purpose of your Wiki?

>>OLIVIER GUILLARD: Yeah.

>>CHRIS DISSPAIN: I think, Hilde, I think that's absolutely right and I think we are going to, in the council meeting when we convene it, we are going to look at a proposal about membership and how it works for the IANA working group. But I also think we can be better at making sure people are aware of what's going on, and we will work on that.

Roelof, you had a question.

Excuse me, microphone, please. Thank you.

>>ROELOF MEIJER: I think I missed a bit of the presentation on the collection of WHOIS data of IANA because I am left with the impression that you collect public data and convert it into confidential data.

But what is the purpose of collecting this data? What do you intend to do with it?

>>OLIVIER GUILLARD: You mean the monitoring issue?

>>ROELOF MEIJER: Yes.

>>OLIVIER GUILLARD: Okay, Stephane, do you want to --

>>STEPHANE BORTZMEYER: I believe I explained the purpose of what's going on, to change the zone file or the TLD information. We do not turn it into confidential data because the notification message are sent to anyone who ask. Several TLD already use it.

And the CVS itself currently is not available but it could be that the idea of making it available. Until now, there have not been interest -- interest which was manifested to have it. But remember that anyone can do it. It's a very simple script.

The only value is in the long-term data. The three years that we collected. And this certainly should be made available publicly, but until now we didn't make it public because we don't know under what form of people would be interested in, and that's why we requested input on that.

Is that the reply you are expecting?

>>ROELOF MEIJER: I am just struggling with the answer to the question. Why would you want to know what's going on in this? I mean, if it's about another registry, why would you be interested in knowing that they have changed the name of the name server, for example?

>>CHRIS DISSPAIN: It's about monitoring IANA's performance, isn't it?

>>: Because it was clear you can't.

>>OLIVIER GUILLARD: I come back to the general idea. As I said, the monitor- -- There is a feeling that the IANA management, the current IANA management is good; okay? That's the -- okay.

It has been clearly said by people.

But I think it would help to concretely measure IANA performance to communicate about it also with concrete data. Okay?

So issue of monitoring performance is also a means to -- As Kim has mentioned, you need to have a clear view of what's going on so that concerns or with clear vision of what's going on.

It's not clear for you? You don't see why IANA performance was -- why monitoring performance is important? You just rely on --

>>: I mean, I think if were you to track the changes over a period of time you could do some academic study on how many changes happen, what kind of changes happen. You might not be interested in the specific details, but having the data available gives you the opportunity to do that kind of study.

>>OLIVIER GUILLARD: I don't think it's only that.

>>CHRIS DISSPAIN: We are in danger of tying ourselves up in circles here unnecessarily and we are running out of time.

Nigel.

>>NIGEL ROBERTS: Roelof, there is another very important purpose to this, which I think if Elisabeth was here she would quite clearly tell you. Somebody said this to me a long time ago. Sometime in 10 or 20 or 30 years' time somebody will be doing the Ph.D. on what we're doing here, on the process. This is our history and this is the raw data that people will be able to look in the future as to what went on, why, and draw perhaps erroneous conclusions, but that's part of it.

>>CHRIS DISSPAIN: Thank you.

>>OLIVIER GUILLARD: What is the question, Nigel?

>>CHRIS DISSPAIN: It wasn't a question.

>>OLIVIER GUILLARD: Sorry. Thank you.

>>CHRIS DISSPAIN: It was a statement. A rare thing from Nigel.

I think that's -- I think that brings us to the end, doesn't it? Yeah.

>>OLIVIER GUILLARD: That's it.

>>CHRIS DISSPAIN: Peter, yes.

>>PETER DENGATE THRUSH: Just a piece of information. There is now, at last, an ICANN board committee on IANA. And I don't know what the charter is, and I'm not quite sure until Friday what the population of that is. I'm sure it's intended to be much higher level focus than this detail, but perhaps some collaboration between that committee and this working group.

So if I can help with that, perhaps you and I can sort that out, Chris.

>>CHRIS DISSPAIN: That would be excellent. Thank you.

Okay. We're going to -- sorry.

>>: Just last one. The IANA performance monitoring is in the scope, also. That's also why --

>>CHRIS DISSPAIN: Yes.

>>: -- we have to address it.

>>CHRIS DISSPAIN: It is in the scope.

Okay. We're going to take a break until 11:00 -- what time is it now?

Okay. I can't read my watch, my eyesight is so bad.

We are going to break for 20 minutes. The council will convene its council meeting at 20 past 11:00 in this room.

There are items on the agenda that basically follow from the meeting we have had over the last day and a half, things like constituting the regional working group and so on.

For those of you who -- You are very welcome to stay in the room, you are very welcome to watch the council at work.

I would like to -- Because I know most of you won't, I would like to say thank you very much, indeed, to everybody who has attended. I think we have covered an extraordinary amount of ground the last day and a half, and I hope that our meeting in Lisbon in March is as useful as this one.

Thanks very much, indeed, everybody.

[ Applause ]