1







https://conference.apnic.net/39/program#sessions/ianasteward

    shiptransition



>>Craig Ng:  Good afternoon.  Welcome to the IANA

    Stewardship Transition session.  As you know, the

    discussions around ICANN for the last 12 months have

    been focused very heavily on the IANA Stewardship

    Transition.  We are very glad to have this session

    today, to bring you up to date about what's going on and

    to talk to you about what's going forward.

        My name is Craig Ng, I'm general counsel at APNIC

    and also a member of the CRISP Team.  I am going to be

    mentioning a lot of acronyms -- and don't worry, I will

    be explaining one by one if you don't know them.  I see

    in this room we have a lot of good friends from our

    various communities and I think you all know what I'm

    talking about.

        This session today is really about consulting you

    and the consultation from our community.  It's very

    important that we in the RIRs hear your views and we

    very much welcome your input.  This is a great

    opportunity for us to meet face to face, for us to talk

    and for us to hear your concerns or your agreement with

    what we are proposing.
     2





        This is one of the two big gatherings of the Asia

    Pacific Internet Community.  Obviously, the discussions

    today will focus a lot on the numbering community's

    proposal, but we are definitely by no means excluding

    discussions from the names community and the protocols

    parameters.  We have guests here from all the three

    segments of the community, if you like, and we very much

    welcome your voice on this subject.

        There are microphones around and this is really

    intended to be a very interactive session.  You can see

    my four panelists there, and we are there to start

    discussions.  I would really like to hear from you.  If

    at any time you feel comfortable, please go to the

    microphone and state your opinion, your comment.  If you

    feel more comfortable doing it offline, you are very

    much welcome to log in to our 2015.apricot.net site and

    enter the remote room and ask your question in writing

    through the remote text messages.  All those messages

    will be relayed back to me and I will read them out for

    you.

        Let me introduce to you my panel members.  The first

    one here is Izumi Okutami.  Izumi works for JPNIC and is

    also the Chair of our CRISP Team.  Izumi very, very ably

    commandeered Nurani over there -- I can see you

    nodding -- commandeered the various views we have on the
     3





    team, to come up with a very good proposal, I think.

    But it's up to you to tell us whether or not we came up

    with a good proposal.

        To the left of Izumi is Edmon Chung.  Edmon is the

    CEO of DotAsia and also quite involved in the domain

    names community discussions.

        Of course, you know Paul Wilson, who is the

    Director-General at APNIC.  Paul is also a member of the

    ICG, the IANA Stewardship Transition Coordination Group.

        Last but not least, we have Seiichi Kawamura, who is

    a senior network architect and peering consultant at

    BIGLOBE, a large Japanese ISP, and also the steering

    committee Chair of JANOG, the Japan Network Operators

    Group.

        This session is going to be divided into two parts.

    The first part is going to be focused on really just

    background and updates.  Hopefully we will take you to

    where we are currently, we will talk to you about what

    the current status is, and where are the discussions

    happening within the ICANN community.

        Before that, I would like to show you a timeline and

    where we are tracking on that current timeline and also,

    for people who are less familiar with this discussion,

    tracking through the evolution of the US Government's

    role in overseeing the IANA's function role.
     4





        Elise -- I can't see her but she is meant to be

    here -- has done a very detailed job at the Opening

    Plenary, and I learnt quite a lot from that as well.

    The presentation here is a very much shortened and

    simplified version of what Elise has shown, but it shows

    the US Government's role from the start.

        The other half of the segment, which is really the

    more important one in our view, is to talk to you about

    the progress from planning to implementation and to get

    your views and comments about various issues that we

    would like to raise with you and to hear your views in

    relation to those.

        Moving ahead, this is the timeline.  I am going to

    move around, so I can see.  This is the original

    timeline that was published by the ICG.  The ICG, if you

    remember, is the IANA Stewardship Transition

    Coordination Group.  Later in the presentation I will

    show you exactly what their roles are.  This is where we

    are at the moment, right in between February and March.

        On the original timeline, the three communities --

    the names, the numbers and the protocols parameters --

    would have completed the proposals by January.  At the

    moment we are in the green phase, which is where ICG

    will be developing a draft response.  All the blue lines

    you see is where the community input is required.  As
     5





    you can see, where we are is in early March, trying to

    get the community response into the draft ICG response,

    but obviously that has been delayed.

        On this side you can see the extended timeline

    I have projected out, based on what the names community

    say they are doing and the timeframe for their work.

    They are saying at the moment that they expect the work

    to be completed by June.  So that is actually stretching

    the timeline out to June.

        We imagine that will make a lot of workload for ICG

    to try to come up with a draft response, and I'm hoping

    or expecting that it could be done perhaps within

    a month or two, but the community response is now

    extended to around August.  Hopefully we are not

    altering the final deadline, which is the NTIA review,

    which is the 15 September deadline.  We will talk

    a little bit more about that later.  That is really

    where the progress is at the moment.

        Let me go back to the start.  When we talk about the

    US Government's oversight, a lot of people ask me, why

    is it that the US Government has this role of overseeing

    the IANA functions?  I have here a timeline, starting

    from the 1960s.  As Elise mentioned just now -- I should

    have got Elise to come and do this presentation for

    me -- in the 1960s, when the Internet as we know it was
     6





    first invented, if that's the word, the US Government

    funded a lot of the research.  So the original funding

    was to the US Department of Defense, DARPA, the Advanced

    Research Projects Agency, to create ARPANet.  That then

    developed in the 1970s to a more formalized contract

    between the US Department of Defense with Jon Postel, as

    we mentioned before, through the University of

    California.  The contract for development work, that was

    paid for by the US Government, required or contracted

    the University of California UCLA to perform the

    functions, and you can see: to maintain a list of host

    names and addresses, maintain list of RFCs, maintain

    list of assigned Internet numbers and names and publish

    list of technical parameters by protocol testers.  That

    is what we call today IANA, the Internet Assigned

    Numbers Authority.

        There is a lot of misconception in the public -- and

    I certainly thought for a long time -- that IANA is

    a body, an entity, it's a corporation.  But it is not.

    It actually describes a set of functions.  I think, for

    clarity, what we have been trying to do in the community

    is to talk about the IANA functions, because the word

    "authority" suggests that it's a body of some sort.

        When we say IANA, we are talking about a set of

    functions.  This set of functions is really simplified.
     7





    Those are the three sets of function: the names and

    numbers and the protocols.

        If we track around to the 1990s, this is when the US

    Government decided to privatize the IANA function,

    privatize the provision of the IANA services.  A lot of

    that has to do with domain names at the time and the

    dissatisfaction at the time about handling trademark

    disputes and cyber-squatting and things like that.

    ICANN was created as part of that process.  But the

    concept of an agreement between the US Government and

    the body providing the IANA services continued.

        So what we have from the 1990s onward is a form of

    contract, in one form or another, between the US

    Government agency, the National Telecommunications and

    Information Administration, the NTIA, which we talk

    a lot about.  The NTIA is an agency within the US

    Department of Commerce.  We have a contract between NTIA

    and ICANN to provide the services we talked about.

        We are now abbreviating those functions, for

    convenience, for grouping, into those three, talking

    about domain names, Internet numbers, protocols and

    parameters.  In this room, we are most interested in the

    Internet numbers part of this discussion.

        At the moment, these are the contractual

    relationships.  People ask me: what are the sort of
     8





    contracts that the US Government has assigned and what

    is being changed in September 2015?

        This is a diagram of the contractual relationship.

    NTIA has a contract with ICANN to provide the IANA

    functions or services contract, so this contract is due

    to expire at the moment in September 2015.  What has

    happened is that the US Government has announced that

    they are looking at the transition of this agreement,

    the oversight role, to the community.

        On the other hand, we have got this document between

    ICANN and the US Government, through the Department of

    Commerce, called Affirmation of Commitments.  So this

    document, which was signed -- I can't remember what

    year, someone can probably help me, in the 2000s -- in

    2009, right during the start of the Rod Beckstrom term,

    but a lot of the groundwork was done during the Paul

    Twomey term, but this document creates the commitment

    for ICANN to act transparently and accountably and also

    sets out a mutual commitment between ICANN and the US

    Government to the multi-stakeholder private sector-led

    bottom-up policy development model.  So the

    accountability and transparency discussions we have, the

    ATRT, if you have been following ICANN discussions, all

    come from the commitments that are set out in the

    document.  So it is a very important document because it
     9





    lays the groundwork and the foundation for the ICANN

    accountability.

        What I have here is a cross and a question mark,

    because the US Government has announced they will

    perhaps not renew, perhaps transfer -- we don't know the

    way this will be achieved.  But the idea is this

    contract will no longer be in existence between the US

    Government and ICANN.

        I have a question mark here because no one is

    actually talking about what is happening to the AOC, the

    Affirmation of Commitments, but the terms of the AOC is

    that it can be terminated by either party by giving each

    other 60 days notice.  So it is not a long-term thing,

    so anyone can terminate that.  Obviously we don't know

    whether anyone will terminate it, but I have a got

    a question mark.

        The next slide shows you the discussions in ICANN

    and the two streams of discussion.  One is called the

    transition stream, so when we talk about the IANA

    Stewardship Transition, we are mainly talking about this

    stream of discussions because we are transitioning the

    oversight of this document, this contract.  The other

    stream that is being discussed is the accountability

    stream and is trying to address a gap, I suppose, if the

    AOC is terminated.  So there are two streams of
    10





    discussions happening at the moment.

        This is how the discussions are happening at ICANN.

    As I said, there are a lot of acronyms and there are a

    lot of very similar acronyms and it is quite confusing.

    If you go to some of the meetings, I think a lot of the

    members at ICANN actually get that confused as well.

        Let me start on the right-hand, the transition

    stream.  What we have is this thing called ICG, which

    stands for the ICANN Stewardship Transition Coordination

    Group.

        The job of ICG is to take the proposals from the

    three communities, which are the domain names community,

    the numbers community and the protocol parameters

    community, and put it into a single proposal to submit

    to ICANN, who will then submit to NTIA.  So that is the

    transition discussions.  I have here within CRISP, which

    is the numbers community -- CRISP stands for the

    Consolidated Regional Internet Registries IANA

    Stewardship Transition Proposal.  Is that correct?

    That's why we say "CRISP".

        CRISP comprises representatives from the five RIRs.

    Each of the RIRs has three members, two from the

    community and one staff member.  We are in the APNIC

    region, so we can talk about APNIC, who the

    representatives are.  At APNIC, the community
    11





    representatives are Izumi from Japan and Dr Govind from

    India and I am the staff representative to it.  I can

    see we have quite a few CRISP members in the room.

    Maybe I will get you to stand up and identify yourselves

    if you are in the room.

        I can see Nurani, I can see Andrei.

        Thank you very much.

        We are known as CRISPies.  Paul calls me Rice

    CRISPies!

        The domain names community, the discussions happen

    at CWG, which is the Cross Community Working Group on

    transition, CWG.  The protocols community is IANA Plan

    Working Group, WG.  That is the right side.  This is the

    transition.  A lot of what we are talking about today is

    focused on this part of the equation.

        On the left-hand side, which we are keeping

    a watching brief on, but not as involved in the

    discussions, is the CCWG, which is a Cross Community

    Working Group on enhancing ICANN accountability.  You

    can see how confusing it is.  We have a CCWG and a CWG,

    and people get that around the wrong way all the time.

        Within CCWG we are coming up with methods and

    proposals about how to enhance ICANN's accountability to

    the Internet Community.  There are two work streams,

    work stream 1 and work stream 2.  Work stream 1 is
    12





    focused on the important things that must be achieved

    and finalized before transition occurs, before this

    occurs, and work stream 2 is matters of accountability

    that would be good to have but that are not super

    urgent, that can come into place later on.

        You can see all these discussions are taking place

    at ICANN and it is all feeding back into ICANN, to be

    fed back to NTIA.  ICANN has said they will not at this

    point try to alter any of the proposals going to NTIA,

    it will serve as a mailbox to go up.  Is that an

    accurate representation?

        George says yes.  We have three ICANN board members

    here: George Sadowsky, Rinalia and Kuo-Wei Wu.  If you

    have questions, you can ask them.

        These are the discussions.  Just a final slide by

    way of background and introduction.  I have two ticks

    and a little cross, and the reason for that is that both

    the numbers community and the protocols and parameters

    community delivered a proposal to the ICG within the

    timeline and the deadline issued by the ICG, which was

    15 January.  I think we submitted ours at 23.30 UTC on

    15 January.  I think it was actually 16 January

    everywhere else in the world, except for one little bit.

        That is all I want to talk about.

        I would like to invite any questions for
    13





    clarification from you at this point, if there is

    anything here that doesn't make sense.

        I will then invite Izumi to talk a little bit more

    specifically about the CRISP and the numbers proposal,

    so that we are all on the same page when we discuss the

    next phase of things.

        Whilst you are gathering your thoughts, can we have

    the lights turned up a bit.

        Whilst we are collecting our thoughts, I might ask

    Edmon, in terms of running DotAsia and involved in the

    names community, where do you think the names community

    is in terms of its development?

>>Edmon Chung:  Thank you for having me on the panel, first

    of all.

        I guess I would start by saying that I'm actually

    not on any of the CWGs or CCWG, and I guess that's the

    reason why I can speak more freely with some thoughts.

    What I'm going to say is really much more my personal

    observations on things.

        In terms of progress, where we are, I guess this is

    a good question.  There seems to be a lot of activities

    that I guess those looking from outside would see, but

    there also seems to be no particular substantive

    progress in the names community working forward.

        I think one thing we need to understand, at least
    14





    coming from the names community -- and I guess we have

    a little bit more of the numbers community here -- is

    that the nature and the relationship of the policy

    development and the operations is quite different at

    ICANN.  I mean the relationship between the RIRs and

    ICANN versus, for example, the GNSO or the CCNSO with

    ICANN is fundamentally different because the GNSO and

    CCNSO are part of ICANN.  For better or worse, that was

    a decision that ultimately was made 15 or 16 years ago,

    and we are living that.  So the nature of it is quite

    different.

        That addresses one particular issue, which is that

    of separability.  Because the big question is: what if

    ICANN doesn't perform well, how do we separate

    ourselves?  That question is much more complex for the

    names community than the numbers or the protocol

    community because we are one and the same.  How do we

    fire ICANN when we are part of ICANN?  That's one of the

    big questions, and that's why it's taking a little bit

    more time.  It's not as clear-cut in terms of that

    particular issue.

        Once you get into that -- sorry I'm taking up time.

>>Craig Ng:  No, please continue.  But I did want to

    interrupt to say that in relation to the severability,

    it's a question that we like to ask ourselves, so for
    15





    the people in the room, later in the segment we would

    like to discuss that.  So you bring up a very good point

    and it will be interesting to hear our community's

    views, in the room at least, as to what we think about

    the severability question.  We come from different

    angles but we might all have the same problems.

>>Edmon Chung:  That's where I'm going.  Once you think

    about the severability and separability -- there is

    a subtle difference there -- you need to think about

    what criteria, what the appeals process is, what the

    accountability measurements are, how we determine

    whether the ICANN or IANA function is no longer

    accountable, no longer responding.  Those are the areas

    the names community is grappling with.

        There is often a saying at the names community,

    therefore, it's kind of a worry that this is the one

    time that we can do this right, because there's a worry

    that if we do it wrong then there is a big problem.

        My personal opinion on this is that I don't really

    think it's just this one time, to "do it right" because

    I think the whole framework will evolve over time, even

    after a transition happens.  However, we could make

    a serious mistake, and that is really what we are

    talking about.  It's not necessarily one time to do it

    right, but we may really screw it up.  Vint Cerf in one
    16





    of the sessions made a really good point, basically just

    to say, "Don't screw this one up."That was his advice.

    That's the reason why people are taking a little bit

    more time.

        I'll end my remarks here.  I don't know whether you

    want me to talk about the actual progress, because the

    proposal was put out, a first draft was put out, the

    public comments are sought, the team is now reviewing

    those comments, and also a second draft, a skeleton, is

    being created.  Eleven design teams are being tasked now

    to fill out the final proposal and those 11 design teams

    are going to produce the final proposal, hopefully by

    April, around April, and have it in time to be finalized

    at the ICANN meeting in Buenos Aires in June.  That is

    very high level.  I don't we don't need to go into the

    details, unless people want to hear it.

        Through that process, the group is also looking into

    some legal advice.  That has some relationship with what

    I mentioned about the separability, how we could

    structure it in a legal perspective and also under the

    California law, of course, because that's where ICANN

    operates.

        Lots of meetings happening.  The CWG itself meets

    twice a week, and then there are the 11 design teams

    that will start coming into play.  The CCWG meets once
    17





    per week.  You mentioned the work stream, which I think

    is called the working party now.

>>Craig Ng:  We changed the name, just to make it easy!

>>Edmon Chung:  Working parties 1 and 2, and they have

    separate mail lists and work items.  There are lots of

    meetings happening.  We are trying to drive towards

    a draft, a proposal, in April and then finalization in

    June; at least, that is currently the optimistic --

    currently the target timeline.  That summarizes where we

    are.

>>Craig Ng:  Thank you very much, Edmon.

        I would like to highlight the two points that you

    made in particular.  We in the numbers community and the

    people in the protocols community appreciate very much

    that our jobs are a lot easier than people in the names

    community.  The issues we have, I think, are far less

    complicated -- I think -- than the names community.

        We are by no means being critical of the CWG's work,

    they have a lot of work.  We do appreciate they have

    a lot on their plate.

        The other point you mentioned about severability,

    I want to provide some framework as to that, which is

    that both the numbers proposal and the protocols

    parameters proposal both recommend and propose that

    ICANN continues to perform the IANA services, the IANA
    18





    functions.  So no-one is talking about not having ICANN

    perform that role.

        The question we are talking about is in the future

    what would happen if there is a breach or what are the

    circumstances under which we have a separation?  That's

    what we are talking about.  We are certainly not talking

    about something happening tomorrow.

        I might invite Seiichi into this discussion because

    I think Seiichi self-confessedly has followed some of

    the discussions, but not in super detail.  Hearing about

    what we are doing here -- I think you are involved quite

    a lot in your community -- how do you think the

    community feels about the progress of this IANA

    Stewardship Transition?

>>Seiichi Kawamura:  I am Seiichi, from an ISP called

    BIGLOBE.  I guess I know some of you out there and you

    might be thinking, why is this guy up on stage?  He's

    never been to an ICANN meeting before.

        It was really a good opportunity that I got invited

    to the panel and I want to thank everybody here, Paul,

    for inviting me, and Craig, thank you for the good

    introduction about what's going on.

        I have been hearing all these talks about IANA

    transition.  Of course, there are presentations about it

    and I go to NOGs and the technical meetings, carrier
    19





    meetings, capacity meetings, all around the world, but

    I have never been to these ICANN meetings or to these

    Working Groups that have been presented here by Craig.

        So I did take some time to review over some of the

    documents.  I tried to go through all of them, except

    I ended up only reading half of the domain names part.

    I read 50 pages!  It was quite complicated.  But

    I really did think, after reading this, my first

    impression was that, wow, these are documents about the

    Internet and how it's running right now, and there's

    a lot of things on there that I actually did not know,

    to be honest.

        Being an operator and a technical engineering

    architect in an ISP, I had a lot of misconceptions.  You

    already mentioned in the beginning that IANA is not an

    organization or body, it's a function, and that's

    something that I actually learned through reading all

    these documents.

        There's a lot more that I was quite surprised

    about -- the positioning and the IAB and what role it

    has today and what role it's been presented on the IANA

    Plan Working Group documents; and the CRISP Team, how

    it's formed and who's on it and what's being worked on.

    These are all really very interesting topics and the

    contents are really critical to ISPs, content providers,
    20





    Datacentre providers.  Our daily jobs depend on number

    resources especially and protocol numbers.  We really

    don't think about protocol numbers every day, but when

    we try to implement something new in a network, of

    course we look at the headers, what's the protocol

    number.  It's part of our daily lives, but we just treat

    it as is, and someone might be deciding it for us, but

    when you look at who's working on it, I know all these

    people.

        It was really a chance for me to learn a lot about

    the Internet.  At the same time, I was really kind of

    ashamed that I did not know a lot of this stuff.

        The place to learn about all this may be not where

    all the engineers actually go, especially the young

    engineers, they don't really get to travel abroad to

    international meetings, they come to local meetings, of

    course, but the local meetings will not have all the

    information.

        The actual background slides, like you are

    presenting today, I think is really of high value

    because it is really easy to understand, it shows how

    it's being discussed, what's being discussed, and once

    operators have more knowledge of this, I think there

    will be more community efforts for pushing forward in

    a good direction, this is how we want to operate, this
    21





    is how we want to utilize number resources.

        Once we get more people active, I think that leads

    to the critical question that NTIA asks: are the

    proposals open and accessible and is this

    a community-based effort, not just limited to some

    people who have enough travel budget to travel around

    the world?  So it was a really good opportunity -- I'm

    now even more interested in all this.

>>Craig Ng:  Thank you very much.

        We are very grateful that you are participating on

    this panel.  We would really like to hear from our

    community, if there is any way we can better engage our

    community, we would really like to hear how we can go

    about doing that.

        Izumi, you have a point to make?

>>Izumi Okutani:  This is Izumi Okutami.  I think Seiichi

    made two very interesting and good points from my

    perspective.  One point is that the documents we are

    compiling is about explaining how the critical Internet

    resources actually work and we manage, and so obviously

    for the people from within our community it's of some

    value, but we also want to make sure that not just in

    terms of the proposal of the future steps but we want to

    be able to explain that this is how things are working.

    For people who are outside of our community, even within
    22





    the three operational communities, I didn't know too

    much about how the names worked until we started

    discussions about this process, and we obviously need to

    reach out to governments and the civil society people

    who are representing, I don't know, the general Internet

    users.  So that's one point.

        We also want to be able to demonstrate our community

    process as well.  So this is sort of like some people

    are observing how this bottom-up, open inclusive

    process, that some of these Internet Community people

    say that it works, but does it really work?  I think, by

    developing and compiling a proposal and in a concrete

    form, it actually shows in a specific shape that we are

    able to work as a community and develop something that's

    of realistic value.  I think these are the things that

    we want to keep note of.

        That's why I feel that it's really important that we

    actually get this process going and make it smooth, that

    we are able to submit this proposal, hopefully, in the

    targeted time that we have initially set a goal

    ourselves.

        The second point about engagement with the

    community, I think that's an excellent point.  Putting

    on the JPNIC hat, we actually have set up this forum for

    this kind of issue.  We really want to reach out to our
    23





    communities, so including this IANA Stewardship

    Transition update, I think we have given maybe four or

    five updates since this process has started.

        We also have an issue of reaching out to the

    operational communities.  How do we get the operators

    interested?  We have a couple of people coming as

    operators and other groups as well.  So it's not the

    purpose of this session to discuss the details of this,

    but I would certainly be interested to hear from Seiichi

    or any other operators who are in the session or

    listening remotely, I'm very much interested in hearing

    your input.

>>Craig Ng:  Thank you, Izumi.  You have raised a very good

    point.

        This is a demonstration of the bottom-up private

    sector-led consensus-making system working perfectly.

    We have 15 people at least in the CRISP Team from very

    diverse backgrounds and being able to come up with

    a rough consensus.  I think we have pretty strong

    consensus on a single proposal over a six-week period,

    I think demonstrates that the system is working

    remarkably well.

        I might introduce and get Paul to speak about ICG.

    Paul is a member of the ICG, representing the NRO, an

    appointee of the NRO, the Number Resources Organization.
    24





    I might get Paul to talk a little bit about the role of

    the ICG and what's been happening there recently.

>>Paul Wilson:  I'm one of two NRO appointees to the ICG, so

    I'm on that group with about 25 other people who have

    come from all the different communities.  Our role is to

    coordinate the production of the plan, the proposal that

    will go to NTIA in time for them to make their decisions

    for the transition to happen in September.

        It is probably worth pointing out that the ICG has

    not taken on the job of producing or writing or

    inventing the proposal.  The whole basis of what the ICG

    has done -- and that includes the request for proposals

    that was sent out -- the whole basis of that is an

    assumption that the three sets of IANA functions that we

    are all talking about can be dealt with more or less

    independently.

        The fact that all those registries are being run by

    IANA in one place is a historical thing and a convenient

    thing and it works, but the fact is you have three sets

    of registries and functions corresponding to numbers,

    names and protocols and the transitional plan can be

    dealt with separately.

        So the request for proposals went out to the three

    communities or went out to the globe and asked for the

    three communities to produce these three proposals.
    25





    That's in the hope and the assumption on the part of the

    ICG that those proposals really will not overlap too

    much, it will be one set of things required by the names

    community to satisfy them and to take the transition of

    those IANA functions forward, and likewise for numbers

    and protocols.

        The state of things at the moment is that two

    proposals were received by the target timeline in

    January and they have been discussed by the ICG in

    Singapore.  The ICG did its job of checking that those

    proposals are complete and make sense and also that they

    don't tread on each other, they don't overlap in ways

    that are inconsistent.

        There was one element of both proposals that

    potentially did, which had to do with the treatment of

    the iana.org domain name and the trademark, such as it

    is, the intellectual property associated with IANA,

    because the two proposals had different treatment,

    inconsistent treatment.  So the ICG has sought

    clarification on those questions from each of the

    communities.

        That is a good demonstration of how things were

    intended to work.  Of course, the third proposal did not

    come in and the CCWG has announced it will probably take

    until June to produce that.
    26





        That seems to put a big spanner in the works in

    terms of the timeline the ICG originally put forward

    because we are hoping to have a combined single draft

    proposal out for community review by March, to have some

    time to review it, to update it as needed and to get it

    to the NTIA by July.  That seems like it's not going to

    happen or it seems unlikely if the names proposal

    doesn't come in until June.

        I don't think we have ruled it out because, after

    all, these proposal development processes are completely

    transparent, they are completely open, so anyone can

    watch the names proposal in production and can see what

    it is likely to contain.  If there is not some really

    late last minute surprises, if there is not some serious

    inconsistencies that really would cause a problem for

    the ICG in bringing it together, then conceivably, if

    that proposal comes in by June, it could be assembled

    into a joint proposal, but a fast feedback from the

    community and then it goes to NTIA.  But that's assuming

    all going well.

        We all know that what the NTIA can do is extend the

    contract for another two years.  It could do that twice,

    in fact.  But they have let it be known that even if

    they do extend it, they will still be looking for the

    proposal from ICANN and as soon as that proposal comes
    27





    in, then the NTIA can complete the transition.

        So I think we still have an urgency nevertheless.

    Even if the contract is extended, we have still got the

    urgency or the importance and the opportunity to put in

    the transition proposal.

        I think everyone knows that the US Government goes

    into election mode about 12 months later, and that will

    both stop sort of rational -- any feasible likely

    progress and then, of course, there is potentially a new

    government, and anything could change.  It seems that we

    have up to an absolute maximum of a 12-month delay to

    this process and preferably, for safety sake, a lot less

    than that.

        Let's see: that's from the ICG's point of view.

    I think that's the status at the moment.  I hope that's

    helpful.

>>Craig Ng:  Thanks, Paul.  Any questions, any comments, any

    issue you want to raise at this point?

        Kuo-Wei.  I should mention that Kuo-Wei is also

    a member of the, ICG as the ICANN board liaison to the

    ICG.

>>Kuo-Wei Wu:  I would like to know how many names community

    are in this room and what is their view about the CWG

    process, because what Edmon just mentioned about,

    I don't know what the names community is thinking about
    28





    this transition means to them.  If the time is taking

    too long and just missing the time of 30 September, what

    are they thinking about?

>>Craig Ng:  Thank you.

        I can see there is a queue forming.  If you can

    identify yourself.

>>Peter Thimmesh (Addrex Inc.):  My name is Peter Thimmesh,

    with Addrex.  We are in the Internet identifier

    business; some of you know what we do.

        We are very curious to get the response from

    everyone there.  What if NTIA decides it is out of time,

    based on your timeline, and it chooses to extend the

    contract, which it has the right to do, for another two

    years, to avoid haste?  What is the effect to your

    particular groups and can you see that as an end-all or

    is that something you can live with?

>>Craig Ng:  Paul, that is for you.

>>Paul Wilson:  It is a point I tried to explain before.

    The NTIA has advised that they can extend the contract

    by two years, twice.  So there are two extensions before

    it goes to another level of rebidding, as I understand

    it.  They have said they will renew it if they are not

    in receipt of a proposal that they can approve and it

    will be renewed for two years.  But if they receive

    a proposal at any point after the renewal, they can
    29





    terminate that contract at the time and then we are in

    that transition -- the transition has happened.

        I think everyone is contemplating or thinking about

    what might happen if this whole thing is cancelled or it

    falls by the wayside and doesn't happen.  In that case,

    we are back in the same condition that we have been in

    for the last 15 years, which would be unfortunate.

        After all -- this is speaking more with an RIR hat

    on -- ICANN was established precisely to have this

    transition, to be the vehicle for this transition.  In

    the original White Paper this was supposed to happen by

    the year 2000, and 15 years later we are still talking

    about it.  If it doesn't happen, I think it would

    reflect rather poorly on what has been so far a pretty

    impressive multi-stakeholder process of

    self-determination and self-management across the

    multi-stakeholder community.

        Also -- as someone put it during a meeting last

    week -- the position of the US Government in the special

    role, with the special contract for the provision of

    IANA services, to say the least, has been a consistent

    irritant in an intergovernmental space, sort of a red

    flag for people to sort of claim that somehow there's an

    inappropriate element to the structure and to the

    management of the Internet.  If that irritant goes on
    30





    then it will go on, but it doesn't really -- it's

    a distraction, it's a risk factor, I suppose, that it

    does attract undue attention.

>>Craig Ng:  Thank you, Paul.

        I think the other point to make is that even if the

    US Government extended the contract by two years, by

    consent ICANN and the US Government can always terminate

    it for convenience earlier on, in any event.

        I have got Jordan and then Izumi and then Nurani.

>>Jordan Carter (InternetNZ):  I would like to talk about

    two things: one is a point about accountability.  Could

    you go back to your slide that had the diagram at the

    end?

        I'm a member of the Accountability Cross Community

    Working Group.  I don't know why it's called CCWG, but

    it is.

        I just want to make the point that it looks from

    that picture like accountability is that group's problem

    and that the transition is the ICG's problem.  But it's

    really important to be clear that accountability for the

    IANA functions to their operational communities is the

    responsibility of the ICG, so that part of

    accountability is the CRISP Team's responsibility for

    numbers, it's the IANA Plan Working Group's

    responsibility for protocols, it's the CWG's
    31





    responsibility.

        So you can't just forget about accountability issues

    in the work that you have done, and I know you haven't.

    It is important to say that because some people are

    starting to say, "The names community, the thing that's

    locking them up is the dispute about accountability.

    Don't worry, the Accountability Working Group will solve

    that."  Well, it won't.

>>Craig Ng:  Thank you.  You make a good point.  Izumi will

    talk a little bit about that because Izumi is the

    representative from the ASO, which is the Address

    Supporting Organization of ICANN, to the Accountability

    Working Group, so she will talk a little bit more about

    that.  Thank you for making the point.

>>Jordan Carter (InternetNZ):  That's where the separability

    point will probably come up.

        As a ccTLD person, I think, in retrospect, we made

    a big mistake in one way with the CWG, which slowed it

    down.  The protocol parameters group had protocol

    parameters people in their group, the CRISP Team were

    CRISP people.  The names team is ccTLD registries and

    GTLD registries and it's governments and it's registrars

    and it's users.  So we kind of got everyone else here.

    Surprisingly enough, when you mix governments with

    Internet people, there are some -- some things slow
    32





    down.  If we had been able to just have registries in

    that CWG, I think the names community would have been on

    time.  But that was never going to happen.  I don't know

    if it was a mistake or not, it was probably unavoidable,

    but that is a key point.

        There is a personal observation -- and I'm not

    a member of the CWG -- they have a tendency to

    over-engineer their processes in developing their

    proposal, that I don't understand, because I'm not

    involved.  We have made good progress in accountability

    by keeping things simple and doing them quickly and

    being iterative.  I'm not sure why the other names

    people didn't do that.

>>Craig Ng:  Thank you very much for that, Jordan.

        We have Izumi, then Nurani, then Edmon.

        Then I would like to close off the queue on that, so

    we can move on to implementation.

>>Izumi Okutani:  I raised my hand to reply to an earlier

    question about this.  Paul has made comments to answer

    most of the things I wanted to say.

        Just to add, as Paul has mentioned, in terms of the

    IANA functions, even if this doesn't happen, it has no

    real impact in terms of the IANA functions, it will

    still continue, even if the stewardship transition does

    not happen.
    33





        At the same time, I do want to -- I do feel this is

    a chance for our community to demonstrate that this

    process of a bottom-up, open inclusive way of developing

    proposals works.  So even if we don't make it in time

    for the targeted initial time, which is September this

    year, I do hope that we are at least able to say we have

    made progress and it's just that we need a little bit of

    time, rather than just say we couldn't make it.  That's

    my observation.

        Jordan has made many points that I want to comment

    on.  Should I put that later and then maybe have Nurani

    make her point?

>>Craig Ng:  Sure.  Thank you.  Nurani.

>>Nurani Nimpuno (Netnod):  Nurani Nimpuno, I'm a member of

    the CRISP Team representing the RIPE region.

        I very much agree with the comments made by Izumi.

    I just want to make a few quick points.  Even as someone

    who has been a member of the RIR communities for a very

    long time, when the task was laid ahead of us to put

    together the proposal in such a short time, I was

    somewhat sceptical that we would manage.

        There was a lot of hard work that went into it but

    really what made it look easy was actually all the work

    done by the RIR communities up to this date.  That's the

    same in the IETF community.  We have over this time
    34





    developed all these structures and this model that

    actually made it possible for us to develop this.  So

    I think that's actually quite important to keep in mind

    also, when comparing the various communities.

        I just wanted to make another point about when we

    circulated drafts and asked for input, traditionally in

    the RIR community, unless people strongly disagree, they

    don't comment.  So we really tried to get people even to

    just come out and endorse the proposal, and it was very

    positive to see.

        I would like to ask everyone in the RIR community to

    continue that engagement as we go forward, that if you

    feel that this is right, that we are going in the right

    direction, to come out and actually endorse it.  I think

    that is quite important also, to show that this is

    a bottom-up process, this is not a few people drafting

    something in a separate room, but it is a bottom-up

    process.

        The final point I would like to make is that as we

    are approaching the deadline, it is important to keep in

    mind that the ICG is not tasked with actually trying to

    merge these three proposals.  They are a coordinating

    body.  They are not supposed to draft a new proposal,

    they are supposed to work with what they get.

        I would like to ask those in the CWG to speak to us
    35





    in the CRISP and the RIR communities and the IETF

    community because the proposal that they will then

    produce in June, if they speak to the other communities,

    if that proposal affects the other communities,

    hopefully we will have something that the ICG can work

    with.  If there are proposals on the table that they

    think affect the other communities, then try to speak to

    us before you put in the final proposal to the ICT.

    Thank you.

>>Craig Ng:  Thank you, Nurani.  George.

>>George Sadowsky (ICANN):  Following up on Paul's point

    that if this process does not work, does not produce

    a result, there will be a loss of confidence in ICANN

    and the multi-stakeholder model, I think that is

    correct.  There will also be encouragement given to

    those who believe that the multilateral direction is the

    best way to go and that international organizations

    should be the ones who run the Internet, and I think

    that would be a very bad result.  Thank you.

>>Craig Ng:  Thank you, George.  Some short points from

    Edmon and Seiichi.

>>Edmon Chung:  In response to Kuo-Wei's question, and some

    of what George and Paul said, the delays you see from

    the names community is not a matter of lack of urgency.

    There is a keen sense of urgency for this to happen and
    36





    there is genuine participation and interest in reaching

    consensus ultimately.  One of the things that was

    brought up by the CWG in terms of the first question is:

    Do we want this transition to happen?  It came back as

    a resounding yes.  So the urgency and interest is there.

    That is very important.

        Jordan touched on a question on the accountability,

    and the graph is correct.  The graph, the orange circle,

    should point back to the transition part as well, and

    that's important.

        You mentioned about over-engineering.  I really want

    to respond to that.  I guess that is really -- the way

    I see it is that it is a robust example of a process

    that developed from a diverse number of stakeholders

    which you mentioned, and that is what we call the

    multi-stakeholder approach at ICANN.  I know the

    multi-stakeholder approach is quite different from

    different operating communities, but that is the ICANN

    that we have.

        I think what you see as an over-engineering or a

    drawn-out process really speaks to the balance of power

    somewhat between the stakeholders, because when you

    create a process that has sufficient uncertainty in it,

    what you are really saying when you look at it is that

    different stakeholders' power is somewhat balanced, so
    37





    that none of them can dictate what the end result is

    going to be.  Therefore it looks like an

    over-engineering but it is really much more of

    a democratic process in place.  That's very much my

    personal view.

        Finally, I totally agree in terms of what Paul and

    Craig and George mentioned earlier: we have got to get

    this right.  It is a very important part of the Internet

    Governance model and we should really drive towards

    a consensus and make this multi-stakeholder approach

    work for us.

>>Seiichi Kawamura:  Listening to the discussion about the

    deadline that everybody is worried about, I had the

    feeling that the deadline -- I feel that is only just

    the beginning.

        This bottom-up process that we are all talking about

    is a process.  We are doing this bottom-up process in

    the English language, and what fits an open process,

    a bottom-up process, especially in the Asia Pacific

    Region, we have a lot of countries where English is not

    spoken and those people use IP addresses.  So we need to

    reach out to those people.  They route, you will see the

    routes on the Internet.  Have we listened to how they

    think or what their aim for the Internet process is?

    That's going to take a long, long time.
    38





        Once we do this process, we have good documents on

    the way, maybe we can start thinking about reaching out

    to those non-English speaking operators about what's

    been done in the past and we can do more to reach out to

    those people.

>>Rinalia Abdul Rahim (ICANN):  My name is Rinalia Abdul

    Rahim, I am a member of the ICANN board from Malaysia.

        I would like to make three comments, the first

    pertaining to the timeline.  I do not believe we have

    too much of a luxury of time.  But I do acknowledge your

    point that the process is a very important one, we need

    to hear from people around the world that may be

    affected.  The key documents are translated into the

    official UN languages, and we tried to circulate that.

    Please help us circulate that.

        In terms of timeline, we have to be mindful of the

    domestic political situation in the United States.  The

    policy window for getting change done is not so wide.

>>Seiichi Kawamura:  I agree with you.

>>Rinalia Abdul Rahim (ICANN):  When there is a change in

    presidency, the policy environment will be less

    conducive, and we need to be aware of that.

        The second point I want to say has to do with the

    proposal being submitted by the board to the NTIA, and

    I do affirm there will be no modification by the board,
    39





    the board will just transmit it.  But the board does

    retain the right to attach a note if there are any

    unresolved issues.  The understanding we have is that we

    will work towards not having any issues and, if there

    are any issues, we will address our concerns directly

    into the development phases of the Working Groups so

    that there are no surprises.

        The final point I want to make is regarding Craig's

    question on the Affirmation of Commitments.  My personal

    view -- and I have seen this echoed in community

    comments -- is that they should be absorbed into the

    ICANN by-laws because they are good requirements.

>>Seiichi Kawamura:  The comments I made, I didn't mean to

    say that we have enough time to do things, but there is

    more that we can do after that deadline when the

    documents are made.

>>Craig Ng:  Thank you very much.  I am sorry to cut this

    short, because we have a couple more things we want to

    go through in this session.

        Izumi, who was the Chair of the CRISP group and also

    representing the ASO in the accountability stream, would

    like to mention a little bit about our work in those two

    places.  Then we will move to Paul Wilson to get some

    discussion about implementation.  Please go ahead,

    Izumi.
    40





>>Izumi Okutani:  Thank you.  I want to make a brief comment

    about the comments made earlier and then talk a little

    bit about the ICANN accountability issues.

        I don't know if we have sufficient time to do

    a recap of the CRISP Team proposal.  The presentation is

    on the website, so maybe you can ask me questions or

    interact with the CRISP Team members about the details

    of the CRISP Team proposal, which I believe you would

    have read and confirmed by the time, but of course we

    are happy to keep engagement.

        I really like the point that Seiichi has made about

    the need for keeping the communities involved, not just

    the people who are active in keeping track of what's

    going on.  But then, of course, in parallel with the

    process, so it doesn't mean that everybody -- there

    really has to be a balance of how much people should

    know and do we have to wait for the process until people

    are engaged?  I think we can do this in parallel.  We do

    this within JPNIC, within Japan; maybe there is more to

    be done within other communities in Japan.

        All of us who are here, I'm sure you are from

    different economies, maybe you have different

    engagements, not just with the operational communities.

    Really we can help in reaching out.  I'm sure Seiichi,

    being strongly engaged in JANOG, maybe there is
    41





    something you can do to help us reach out about this

    topic?

>>Seiichi Kawamura:  Unfortunately not everybody comes to

    JANOG.  There are a lot of people that don't.  How to

    reach out to those people, that's something I still

    don't have the answer to yet.

        Five hundred people come to JANOG meetings, but I'm

    pretty sure there is at least 100 times more people who

    do engineering stuff on the Internet, and they have

    their own conferences, there are web conferences, HTPP

    conferences, cloud service conferences.  I haven't been

    able to reach those people myself.

        Those people have some involvement in this as well,

    so that's something -- I can probably do a lot with

    JANOG, the network operators community, and I think

    there are more communities that do not interact with the

    network operators.

>>Izumi Okutani:  If you have a good suggestion of moving

    things forward, that would be great and we could

    consider this in parallel to moving the process forward

    and making sure we engage with the people we need to.

        I really like the point Nurani made about being

    implicit about expressing support.  I was very

    encouraged during the development of the numbers

    proposal that people came up and there were
    42





    observations, like the process was not bottom-up or

    there is not enough support for the numbers proposal.

    People were quiet until that point, but came up and

    expressed support for the proposal.  So I hope you can

    still help us do the same.

        I would like to move on to talk a little bit about

    the ICANN accountability discussion that's happening.

    Jordan has made the really good point that there is an

    element of accountability that should be considered in

    relation to the IANA operations but that is separate

    from the general accountability of ICANN as an

    organization.  So it is very important that we separate

    this.

        In this Cross Community Working Group within ICANN,

    different groups are represented, so there are people

    representing the government, people representing the

    ccTLDs, people representing the GNSO.  I myself, along

    with three other colleagues, are representing ASO from

    the numbers community.  Athina Fragkouli, from RIPE NCC,

    and some ASO AC members, Fiona Asonga and Jorge Villa,

    are representing, so we are working as a team.

        My observation is that the wider ICANN community

    seems to have concerns and issues with ICANN being

    accountable to their communities.  I think they have

    different involvement with ICANN as an organization and
    43





    ICANN board, compared to the numbers.  So we tolerate

    this situation.

        When we look at the situation from the perspective

    of the numbers community, I don't really observe strong

    concerns related to ICANN's accountability.  Please let

    me know if my observation is a little bit off from what

    you think, but I think the only part that we are

    actually engaged in ICANN is in terms of, and maybe

    should be concerned or related to ICANN's

    accountability, is when ICANN board approves the global

    policy.  Until this point, I don't think we really had

    a serious issue with the ICANN board decision on ASO,

    the ASO proposal we presented to the ICANN board,

    I think it's been pretty smooth.

        From the numbers perspective, we don't really think

    of this whole accountability issue as a serious thing.

        What do we think is important in getting this

    through, related to ICANN accountability?

        As Craig introduced, we have just put up a proposal,

    at the same time as the IANA Stewardship Transition

    proposal, to NTIA, that is the accountability mechanism

    proposal that should be in place before the IANA

    Stewardship Transition happens.

        From the numbers community representatives'

    perspective, we don't want this ICANN accountability
    44





    discussions to be a factor in delaying the IANA

    Stewardship Transition, so maybe we can just come up

    with really grand, not so pragmatic plans, and it takes

    us maybe another two years to come up with a proposal,

    and that means the IANA Stewardship Transition proposal

    has to wait as well.  We don't want this to happen.

        That's one point that we want to make sure this will

    not happen in the process.

        Then related to this first point, we also want the

    solutions to the ICANN accountability issues to be

    simple.  I think there are various requirements being

    listed at the moment.  But maybe the solution may be one

    or two core simple solutions that will commonly address

    many of the issues that are being listed, and coming up

    with too many solutions may complicate the process and

    it may not necessarily help with coming up with an

    effective accountability solution.  That's the second

    point that we think is important, as ASO

    representatives.

        The third point is that we have already covered in

    our numbers proposal on the IANA Stewardship Transition

    accountability issues related to the IANA operations on

    the number resources.  This is already covered in the

    CRISP Team proposal.  So make sure this Cross Community

    Working Group within ICANN will not interfere and do the
    45





    duplicate work that has already been done and discussed

    with the numbers community.

        The fourth point is -- well, I have explained that

    the ICANN board approves the global policies that are

    being discussed and reach consensus by the numbers

    community, so any accountability mechanism that will

    come up will not overly interfere and change the

    consensus decisions that have been made by the numbers

    community.

        That probably is applicable to maybe the GNSO

    process.  GNSO actually discusses and develops proposals

    and policies related to gTLDs.  Maybe the accountability

    mechanism probably don't want to overdo -- maybe people

    who are not directly related to these things will have

    too much strong say and overrun the process that has

    been discussed and supported by the community that is

    directly relevant to these policies.

        These are the four points that we think are

    important, working in collaboration with NRO EC who have

    appointed us, and we want to keep the community involved

    as well.  I don't know what process is there in keeping

    you informed, so maybe you can talk to me or express

    your suggestion on how we can keep you informed about

    these discussions happening in the ICANN accountability

    stream as well.
    46





>>Craig Ng:  It is very important for us to note that, in

    terms of accountability, you mentioned a global policy.

    The RIRs already have an agreement with ICANN in the

    form of an MOU.  The MOU is between NRO, acting on

    behalf of all the RIRs, and ICANN, that deals with

    global policy implementation and deals with the

    situation where the ICANN board does not approve

    a global policy that has been through the regional

    processes.  So there is already an agreement that deals

    with that and that agreement will not be affected by the

    transition.  That is one of the reasons why the

    accountability issue, as Izumi said, has not been such

    a big focus of our community.

        Now I really want to move on to the future, working

    on the implementation going forward.  I would like to

    invite Paul to talk about those plans and the issues and

    questions we might have for the community going forward.

>>Paul Wilson:  Thanks, Craig.  I'll do that from here.

        The next step is simply implementation.  A plan is

    only a plan, it doesn't produce anything concrete until

    it's implemented.

        In Singapore, it was quite clear from statements

    that Larry Strickling made that the transition is not

    possible without implementation; the implementation

    steps are part of the transition.  I think what we have
    47





    got to look at, and to do so between now and the

    optimistic September deadline, is what do we need to

    implement to put this plan into action.

        To do that, we effectively need to look at the two

    major components of the CRISP proposal, which are the

    service level agreement between ICANN and the RIRs and

    the review committee.  These tasks have been assigned by

    CRISP to the RIRs as our responsibility to implement.

        What I expect is -- because, as we say, the devil is

    in the details -- what we will have is the CRISP Team

    acting to watch that process and make sure that the

    implementation as it emerges and as it is clarified

    actually does comply with the CRISP proposal in the

    first place and, I guess, also with the NTIA's

    requirements.  Those are the two things we have to go on

    in moving into implementation.

        With my RIR APNIC hat on, I wanted to talk about

    some of the issues that have come up in the discussions

    about implementation, which have started and which

    certainly need to be carried on in an open and

    transparent consultative way, both with the CRISP Team

    watching over the process but also with as much

    information backwards and forwards between the RIRs and

    our communities as possible.

        I didn't realize I had some fancy animations there.
    48





        The point of the presentation is specifically about

    the service level agreement, about implementing the 11

    principles of the service level agreement.  The review

    committee is something we haven't really started to

    discuss yet.  It is certainly open for discussion here,

    but I don't have anything in particular to report about

    that, as the SLA has been the thing that the focus has

    been on so far.

        The point of the SLA is in fact to replace the

    existing contractual relationship between ICANN and the

    NTIA.  What is proposed is that there be a service level

    agreement, a contract, between ICANN and the RIRs which

    refers to the numbering functions of the IANA.  It is

    under this agreement that ICANN will continue to carry

    out the IANA numbering functions on behalf of the

    regional and global numbering community.

        That agreement, according to the CRISP proposal,

    needs to cover a number of issues.  As it says here on

    the slide, it will deal with the services which are

    provided by ICANN to the numbering community,

    a definition of service levels and the consequences of

    failing to meet those levels; the term of the agreement

    and the termination of the agreement; dispute

    resolution, how to deal with intellectual property

    rights and governing law and jurisdiction.
    49





        This is all the legal terms, the specifics of the

    agreement.

        In the original first APNIC proposal for the

    transition plan, we spoke about two agreements.  I will

    just point out that as the CRISP Team did its work and

    as the discussions carried on around the other regions,

    the RIRs converged from a single agreement.  Although

    six months ago we spoke about an AOC and an SLA, there

    is now one SLA.  In my mind at least, the AOC components

    we spoke about are really the recitals of the SLA, it is

    the kind of "whereas" clauses that set the scene for the

    agreement.  That stuff is very important for ICANN and

    the RIRs to agree on and that is the mutual recognition

    of each other's roles and responsibilities and our own

    individual commitments to the policy development

    processes.  I think they come first, they are the

    important scene setters that actually explain, and we

    agree why we are doing this before we get into those

    details that are listed there.

        I will just mention the SLA development process.

    This is actually a little like what we saw six months

    ago with the proposal development process.  We had

    a series of RIR meetings during the second half of last

    year, where we started with APNIC again and the

    discussions at APNIC were carried through the other
    50





    regions and everyone got the chance, as we went through

    a cycle of RIR meetings, to refine what became the

    consensus view that the CRISP Team articulated.

        In this case we have the potential to do the same

    thing.  We are starting now with an APNIC Meeting, and

    this development process, this set of discussions are

    going to go on from here through the other five RIR

    meetings.

        As I said, the CRISP proposal has the RIRs working

    with ICANN.  Some of those preliminary discussions have

    started without any agreement that can be reported.

    What will happen is that we will need to go on having

    those discussions with ICANN while the regional meetings

    are going on, so we have got at least two parallel

    activities, while at the same time we have got the CRISP

    Team looking on and we have got other things going on,

    such as the ongoing development of the numbers proposal,

    the names proposal, the accountability and so forth.

        After all this is done and after all these processes

    have run their course, we should have an agreed final

    SLA as the outcome, which would then be part of the

    implementation of the CRISP plan.  As I have said,

    I think we can trust that, unless the SLA is agreed and

    detailed as a critical part of the numbers community

    proposal, then the IANA transition is not going to go
    51





    ahead.

        Just a final slide, to identify a series of related

    issues which have come up in the discussions so far

    which have happened with ICANN.  The subquestion of

    separability is a thing that was raised already and the

    question is -- the CRISP Team proposal does include

    a separable contract, it includes a contract with a term

    and termination, termination conditions and so forth.

    The question, though, is whether that is the final

    position of the community, whether we have a view on

    whether separability actually is a critical essential

    part of this, whether separability or not would be the

    best solution for the stability and security and

    resilience of the Internet.

        After that, if there is separability, when would it

    be appropriate to change the provider of the IANA

    services and under what conditions?  Who could take over

    the performance of IANA in that event?  Who would choose

    the IANA contractor and under what criteria?  Then

    separately, although related probably more to the second

    point, how should disputes be resolved?  Because, of

    course, an attempt to end the agreement naturally would

    seem to reflect a dispute, so dispute resolution is

    pretty important there.

        I want to say -- this is the last slide, and I would
    52





    really like to hear, I would be very interested to hear

    some discussion about this.  We are focusing here on

    this issue of separability, which is kind of a disaster

    scenario or a scenario where we don't necessarily want

    to be at all, so let's not assume that we are talking

    about separability because anyone wants to separate from

    ICANN.  This is about what is the best provision in the

    agreement for the security and the stability and for the

    best result for the Internet itself.

        Back to you, Craig.

>>Craig Ng:  Thank you, Paul.  I recognize we only have five

    minutes left in this session.  With your permission, if

    there is going to be some good discussion coming out of

    it, maybe we can extend it by 5 or 10 minutes.  I am

    conscious there is a "Meet the APNIC Executive Council"

    cocktail function just outside, so if you are really

    dying to get a cocktail -- I think there is probably

    just beer -- feel free to go out.

        But these are really important questions.

    I suppose, I'm the lawyer and the lawyers always look at

    worst case scenarios and how you deal with it.  What

    lawyers don't like is uncertainty.  What lawyers don't

    like is an agreement that doesn't deal with all the

    eventualities, even if you don't want that to happen.

    It's like people making a prenuptial agreement; before
    53





    you get married, you work out what happens if you have

    a divorce.  This is what it is.  I know it is a terrible

    analogy.

        We want to hear your views.

        My first question would be back to Izumi.  Some of

    the questions we are asking here are slightly

    inconsistent with the CRISP proposal.  Just in terms of

    processes, the question is how much flexibility do you

    think the RIRs have in terms of discussing with ICANN,

    and certainly no decision will be made without going

    back to the community.

>>Izumi Okutani:  Certainly.  I will be speaking from the

    perspective of what is described in the proposal and

    what we have considered as the CRISP Team in discussions

    with the community.  Of course, I'm not putting this as

    a fixed final position, but I am sharing the perspective

    from the numbers proposal.

        The separability of the IANA services from ICANN, we

    think this was one of the most important elements in

    keeping the accountability of the IANA functions.  This

    is really related to maintaining the security, stability

    and resiliency of the IANA functions are related to the

    number resources, because we are not -- we clearly

    stated we do want to keep ICANN as the operator at the

    time of the transition, and this is more like
    54





    a guarantee that in case ICANN does not keep this

    service level that is required for the number resources

    services that will be defined in the SLA, I think we

    want to be open to the possibility of the changing the

    operator to another alternative operator who would be

    able to do so.  Because if we can't, if we are left with

    no choice, then we really have to live with an operation

    that is provided by ICANN, even if we have concerns with

    the service level.  So I think that's something that

    I would like to highlight, from what's described in our

    proposal.

        I won't cover all the questions myself, because

    I would like to hear what others think.

        My last point is: how should disputes be resolved?

    We did state that we should go through arbitration and

    there were some discussions on how detailed this should

    be.  I think there are already enough common practices

    in the legal world, so I think, rather than the CRISP

    Team members specifying that there should be

    a particular jurisdiction or scheme, it is better for

    the legal experts to figure this out.  I think that's

    the kind of flexibility we have.

>>Craig Ng:  Let me take that as a baton back to me and tell

    you what I think that clause should read, as a lawyer.

    In terms of dispute, the escalation mechanism I see,
    55





    which, as Izumi said, is the common practice in legal

    contract, the way I see it happening, if there is

    a dispute at the operational level, you escalate it to

    the executive level.  If that cannot be resolved, you

    escalate it to mediation, where the parties decide to

    either use a mediator or by themselves try to resolve it

    and there is a deadline for that to be done, say within

    30 days, by way of example.

        A mediation is purely voluntary, in the sense there

    is nothing that forces you to come to an agreement, it

    is just an opportunity to sit down and talk and see

    whether you can reach an agreement.  If you can't, you

    go to an arbitration.

        An arbitration is like a private court system.  The

    idea of arbitration is that we are trying to remove the

    court of a particular country from trying to decide the

    dispute.  What we are trying to do is to work within an

    arbitration system, Arbitration Rules, which are more

    international in nature.  What I have in mind -- not

    talking on behalf of CRISP but just as a simple

    lawyer -- in this particular case what would be

    acceptable, I would imagine, would be an arbitration

    panel, which is really a panel of judges, comprising of,

    say, five people from each of the five regions, for

    example.  That is kind of more important to me than
    56





    where it is going to be held, because what we want is

    impartiality of regions.  That is the easy one.  I don't

    think we are going to see a lot of issues coming out of

    that.

        I would really like to get your views about

    severability and separability.  We heard from Edmon that

    in the names community it is the biggest issue.  I would

    like to hear your views.  Maybe I will get you to put up

    your hands if you think that the contract should remain

    with ICANN forever, even if there is a breach.  I will

    ask it the other way.

        If ICANN breaches the contract -- so we have

    a service level agreement with ICANN, so ICANN agrees

    that it will provide IANA services to the RIR community,

    it doesn't do it, for whatever reason, just refuses to

    do it -- do you think there should be a point where the

    contract can be terminated?  Hands up if you say yes.

        Do you think it should never be terminated?  Hands

    up if you say yes.

        Nurani.

>>Nurani Nimpuno (Netnod):  Nurani again.  I just wanted to

    clarify, I don't know if everyone has read the proposal,

    but the method by which we worked was to gather input to

    set the principles.  That was gathered from all the

    discussions in the RIR communities, the various regional
    57





    communities.  So I think we felt that we had enough

    guidance to set the principles.

        I think what we need to do now -- what we said, and

    certainly what I personally said was, I'm not a lawyer

    so I don't know how to do this in the right way, so I'm

    perfectly comfortable with the RIR legal teams to do

    that.

        The principles are what should guide us.  I think

    the next steps maybe should be to basically look at how

    do we implement these principles, and when the legal

    teams come up with text, do we feel that they represent

    these principles?  I think we have said that we want

    this contract to not be indefinite.  That was the

    feedback we got from the communities already.  I think

    we've sort of landed there already, and then I think

    it's a question of finding the words to match those

    principles.

>>Paul Wilson:  As I said earlier, there have been some

    initial, very preliminary discussions with ICANN that

    haven't resulted in an agreement, even an agreed set of

    principles or a framework or an executive summary of

    what we are trying to do.  There just hasn't been enough

    time.  If there was, it would be on the table here as

    something that we could say, "Does this reflect the

    principles or not?"
    58





        Where we are at is really the identification of

    principles which have come up in discussions.  From my

    point of view, I am trying to ask the community and

    CRISP Team for guidance as to whether there is room to

    move, flexibility, wiggle room around the CRISP

    proposal, to actually answer some of these questions

    differently.

        I agree with you, the CRISP proposal is pretty

    clear -- completely clear, actually.  But do we have any

    flexibility, can we confirm our position on specific

    questions which have been raised in discussions?

>>Craig Ng:  Hypothetically, if ICANN does not want to enter

    into a contract with the RIRs in the way which is laid

    out in the CRISP proposal, then what is our community's

    response?  That is the question.

>>Izumi Okutani:  Regarding the process of moving this into

    implementation, my initial assumption was that we will

    draft this contract SLA as what is desirable as the

    numbers community, based on the CRISP Team proposal, and

    then maybe we will present this to ICANN before, instead

    of ICANN saying things before we actually develop

    something.  I don't know if it makes sense.

        In case ICANN has concerns, I think they should also

    consult with -- I don't know what community there is

    within ICANN, maybe that would be ASO representing the
    59





    numbers, I don't know -- but it seems not so transparent

    that ICANN is making these comments.

        I'm not sure if ICANN is the ultimate

    decision-making body related to this or whether this is

    acceptable or not, or is it going to be NTIA and maybe,

    further on, the US Congress.

        If NTIA says this is not an acceptable way of

    contracting, surely -- again, it would help if they

    could communicate with us and explain the reasons and

    then I think we can consider whether we should

    reconsider these things.

>>Craig Ng:  Edmon.

>>Edmon Chung:  I just want to make a quick comment.  Herein

    lies the difficulty that you mentioned with the names

    community.  We believed we had to resolve much of this

    within this proposal or at least before the proposal is

    set out.  That's why it's taking a little bit more time.

        The other thing I want to point out also, it is the

    worst case scenario we are planning for.

        One of the things we need to ask is, when we want to

    sever, when we want to separate, it means that if ICANN

    goes rogue on something, one of the things we need to

    think about is if ICANN does go rogue, what kind of

    ICANN do you think that ICANN is going to be?  If ICANN

    is somewhat weak in terms of the power that they have,
    60





    unlikely they are going to go rogue.

        The point when ICANN might go rogue is probably when

    they are very "powerful" and can potentially replace

    some of the, let's say, RIRs.  That's a hypothetical

    situation.  If not that case, why would ICANN -- ICANN

    probably won't go rogue.

        The other thing is ICANN, if it does go rogue, it is

    probably economically powerful as well.  So those are

    the kinds of things you want to think about when you

    think about a "worst case scenario" and that is also the

    reason why the names community has taken a little bit of

    time to consider the issues.

>>Craig Ng:  Thank you.

        Ideally we would be in a position where we have an

    SLA laid out for today's session and lead the

    discussions for the next few months in relation to these

    issues.  The issue is that we don't because some issues

    have been raised and we are trying to address them and

    we don't want to waste this single opportunity that we

    have -- because the next opportunity is six months

    away -- for us to have a face-to-face discussion.

        I want to put some context into the reasons for

    these discussions.  We are clearly not intending to

    undermine the proposals of CRISP, definitely not.  What

    we are trying to do is to get some temperature in the
    61





    room as to what are the areas that mean a lot to the

    community.  Really that's where I'm going.

        Kuo-Wei.

>>Kuo-Wei Wu:  I would like to express my personal capacity,

    not from the ICANN board point of view, just my personal

    view.

        First of all, I think that actually the members of

    the numbers community or the names community, from

    ICANN's point of view, I think we are in one big

    community and should not separate them because we work

    together.

        Remember, somehow in these Internet communities,

    particularly from the names and the numbers, the real

    challenge is not among us.  Actually there is other big

    guys outside of this, just like Jordan mentioned about.

    I just don't want to say clear, but you know there are

    some other big monsters outside of this community.

        So I think it is very important for this community,

    from ICANN or numbers community or names community,

    I think we need to find out some way we can cooperate

    together as a very strong group, and so we can continue

    to make the Internet in progress develop in the future.

    I think that is a very, very important thing.

        Second of all, don't forget that many of the ICANN

    board is appointed by your community.  For me, I was
    62





    appointed by the numbers community.  If you don't like

    what I did in the ICANN board, you can terminate me any

    time.  Well, maybe not, but at least you can say, "Next

    term you are out," something like that.

        Of course, there is many things we can work together

    to have better cooperation, particularly for the issues

    you are raising in here.  I think Elise and I hear it

    and I believe another two board members hear it.  So

    somehow we have to discuss internally.  I cannot say how

    to go on, but I believe in these two communities or

    these two entities, we have a lot of space and room we

    can discuss, we can talk.

        I think this should be very open, we can continue to

    talk about what is a reasonable and workable model.

    I think that is my personal view.  I just don't think

    about we have to be divide very clear, this is ICANN,

    this is numbers community, this is names community.

    Because outside of this community there is a monster

    looking at the opportunity; if we fail, they will be

    very happy to jump in.

>>Craig Ng:  I am trying to visualize this monster.

        Thank you, Kuo-Wei.  I appreciate the point.

>>Kenny Huang:  Kenny Huang, Executive Council member of

    APNIC.  I am only speaking in my own capacity from the

    numbers community point of view.  Today what you
    63





    presented is very similar to six months ago and

    I remember six months ago I mentioned we have a plan,

    but things probably never happen as we anticipate, so we

    probably need a plan B.

        Right now we see everything that happen is going to

    describe in plan A, but I suggest we better have a plan

    B, in case anything happen, we probably activate plan B

    in certain conditions.

>>Craig Ng:  Thank you, Kenny.

        I know we are really stretching beyond our time.

    Does anyone have any comment to add?

        George, please feel free.

>>George Sadowsky (ICANN):  It is so tempting to talk here,

    I never get a chance in the public forum at ICANN.

>>Craig Ng:  You are very much welcome.  It is a much

    smaller group.

>>George Sadowsky (ICANN):  I have a question for you: you

    said the purpose of this meeting is to take the

    temperature of this room.  What, in your opinion, is the

    temperature?

>>Craig Ng:  The temperature -- I'm getting a very hot

    sensation from some of the comments that are coming

    back -- is that we don't want to change, that our

    proposal is our proposal.  That's what I'm reading.

        What we would like to do is discuss this
    64





    transparently.  For reasons that you would be aware, we

    can't currently do that.  As soon as we are in

    a position to talk about the issues openly and

    transparently, we would like to do that.

>>Paul Wilson:  I will just say this: there is not a secret

    thing that's happened that can't be revealed.  Really,

    there is nothing to report.  There is nothing that is

    able to be simply put on the table as a common position

    because it's not there.  That's why the questions are

    being asked.

        I just wanted to, on a process thing, I wanted to

    point out that at the end of this week we have got the

    APNIC Member Meeting, general meeting, and that is often

    a time when the APNIC community can consider what's

    happened during the course of the week.  It may be

    useful to set some time on that agenda -- I have come up

    with this idea without consulting the board or the

    Chair -- it may be possible to set some time on that

    agenda to have a further discussion.

        I was just interested to find out from this room

    whether those who are going to be at the meeting on

    Friday would like to try and set aside some discussion.

    Could I have a raise of hands for those who would like

    to have some more time to discuss this on Friday?

        That's three people who would like to discuss it.
    65





        That's not a really strong endorsement for setting

    aside time on Friday.

>>Izumi Okutani:  I have a question to you, Paul.  What more

    would we discuss on Friday in addition to what we

    discussed here?  Do we actually feel we have a general

    agreement here or do we also need additional time at

    AMM?  That's my question.

>>Paul Wilson:  My thought was that maybe some further

    thought is needed by folks in the room about what's been

    discussed here.  There is quite a lot of information,

    this is moving quite quickly and it may be difficult for

    those who are here to say "yes" or "no" to some of these

    issues.  It seems difficult to say "yes" or "no" to the

    question about meeting on Friday.

>>Craig Ng:  We will think about that.

>>Paul Wilson:  I will consult with my board and see if we

    can find time at least to open the floor for discussion.

    If there is not, that's that.  Thanks.

>>Craig Ng:  Thank you very much.  I very much appreciate

    your indulgence.  I know we have gone 15 minutes over

    time.  Thank you very much for your participation.

        I would like, on behalf of the APNIC Executive

    Council, to invite you to drinks, to meet the Executive

    Council members, just outside.  Thank you very much.

APPLAUSE