IANAPLAN WG at IETF 91 Co-Chairs: Leslie Daigle Marc Blanchet Agenda: Agenda bash 1. Review of outstanding issues in draft-ietf-ianaplan-icg-response Discussion of issues raised on the mailing list 2. Conclusion and next steps. ——Intro Slides—— (Leslie Daigle as co-chair) Timeline * tight timeline, externally imposed Goals of this meeting * discuss and consensus on final outstanding issues ** Questions and discussion held to the end; slides contain the change log and proposed text for all suggested changes** (Eliot Lear) presents the slide deck on changes to draft-ietf-ianaplan-icg-response. Q&A (Eliot Lear) Does the IAOC feel there is enough here for guidance? (Bob Hinden) What do you want the IAOC to do if they can’t negotiate the intent of this? Are you pushing a hard problem to a future IAOC? You are asking a lot for something to happen in the future, and maybe the IAOC will need more guidance on the desired result. (PHB) Less worried about the name or the ownership than about switching costs. The issue is if we end up in a situation where ICANN is at the center of a cyber WWIII by necessity because the name is a control point for the Internet, would like the IETF to be completely decoupled from that argument. The question is why do we need to be so attached to the name? We switched from ARPAnet to Internet. Don’t feel bound to the IANA name. We should own the brand of the registry, and that registry brand is run by IANA. (Leslie Daigle) When you have an opinion, state not just the solution, but state what problem you have to solve. Thank you, PHB, for doing that. (Scott Bradner) also on the IAOC. Probably cannot stay out of this food fight. IANA is listed in a lot of RFCs and those won’t change, so we have to deal with that at some point. As a member of the IAOC, the right answer may not be that the IAOC negotiates. Historically, this is a task that belongs to the IAB and IETF chairs. The IAOC stands as a backstop and second-guesser to that, but it’s not a good idea to have that scale a committee to be doing detailed negotiations. (Jari Arkko) The WG provides the guidance on direction, and then we’re not the ones to do the amateur lawyering. Some of these things are agreements beyond this organization so we cannot decide on them independently. The mechanics of who actually does some of this negotiation we can discuss, and part will fall on the IAB and the chairs, and part of the IAOC. Now that we have text, Jari is reasonably happy that he knows what needs to be done. To respond to Bob’s question about putting the IAOC in line of a hard problem, we need to have a plan and that plan means several things in the world need to happen. But it is a separate step, and the transition isn’t just that we publish an RFC. If those changes are impossible to do, that’s a very public and visible thing. We need to specify what the IETF needs in this space and go do that. (Russ Housley) Instead of saying what needs to be negotiated, say what the desired outcome is. There is no confusion about where to find the authoritative protocol parameters. As long as we have that outcome everything is ok. (Jon Peterson) I agree, and that’s a big improvement to the existing text. In the event of a transition, what owners are we talking about at various points of the transition? (Eliot) We mean the operator that we are transitioning from and the operator we are transitioning to. (Larry Masinter) There is a grammatical error that introduces confusion. Definite or indefinite article? (Eliot) The extra definite article needs to go. (Alissa Cooper) Don’t feel there is a problem to be solved here. Not concerned about confusion, and we will have many options on how to find parameters even in the event of a transition. Have two suggestions that have been sent to the list. As long parties agree to minimize confusion, don’t need to get so detailed. It’s hard to specify the detail in advance; just specify the goal. We are also asking too specifically things of the IAOC. Maybe say we want the IAOC/IAB to work together to minimize confusion, and leave it at that. (Dave Crocker) [jabber] Switching costs could be high but they are cheaper if we attend to the issues now rather than wait until the event. (Andrew Sullivan) Following up on Bob - you can’t have in this text anything that says “go negotiate this” that also have a detailed, sorted list of what you can give up in negotiation. Don’t believe there really is a problem here to solve, so would like people to be more clear on that. If it’s not already covered by existing arrangements, you need to say what it’s worth to you (if you don’t already have it). People need to be able to say “this is worth more than something else” else we’re not really negotiating, we’re demanding. (Andrei Robachevsky) Regard to level of requirements, heard the word “negotiations” but think it implies negotiation with ICANN, but we need to look at the united proposal. If we can’t coordinate proposals, we have a problem. The goal of this group is to make sure outcome is clearly specified, and then negotiation happens when we see other proposals. In the united proposal, we need to resolve those issues. The probability of resolving those issues will be lower if we embed a specific solution in this draft. (Tobias) seconding Russ; if you give us an indication of desired outcome that would be more helpful than what we should demand. A wish list would also be nice. (Leslie Daigle) Of the things heard so far: minimizing switching costs, and minimizing confusion, with a separate conversation about how and what going into this document. (PHB) It is important to put the reasons in. Most people involved in this dispute have no idea the technical implications and it needs to be explained to them. The people driving the meta process are not really technical. What they want to do is establish the internet as free of government control, and that is also the goal of the US government. This isn’t a negotiation in the classical sense; you are negotiating a will before the person has died. Putting this on the table to say this is what we need to be independent of US government and ICANN control is what’s important to say. (John Curren) Picking up on what Andrew said, there is an implied negotiation aspect to this. Whatever the IETF sends to the ICG is just one of several proposals the ICG will need to bring together. The IETF will need to agree to support the process. The implied “what you give up” is that the IETF would prefer the status quo. The IETF can say it believe something is necessary, with the implication being if that’s not possible, maintain the status quo. The document should be clear about what it MUST (RFC 2119) have, and what you SHOULD have, but it is implied that what you put in the proposal are necessary for moving forward, and you don’t need to specify the trade offs (Jon Peterson) Have mixed feeling about lobbying for specific outcomes prescriptively. Some people we believe we should be lobbying for a broader say, but having the IAOC specified in here is probably more detail than the ICG needs to know. We’re giving the IAOC too much direction in this. (Eliot) You hit on something nagging at me as well: are we doing th right thing in the doc mentioning the IAOC at all, or should we state what our requirements are in terms of the service, and separately charge the IAOC to have discussions to get that outcome. Is that what you said? (Jon) I am torn. Given the fact that we could drag this down into a lengthy process in getting into that detail when we understand this community cannot be privy to all the negotiations, the less we say about it the better, and the more we communicate that it would be nice to have the status quo seems good. (Alissa Cooper) Really like the thinking that John Curren has about the separate of must-have and nice to have. This doc only needs the must-haves and if the draft is limited to the must-haves, then the IAOC doesn’t need to be mentioned at all. None to the things that mention the IAOC are must-haves. In responding to Andre, there are people paying attention to proposal development, and it is not the responsibility of the IETF community to make sure this proposal is consistent with those other proposals. It’s not like we need to have everything resolved in the next two months. (Ted Hardie) We are trying to solve a superset on the question of switching costs. We are putting forward whatever we need in the process. It is a risk management exercise. Do we want to start that aspect of the risk management now, or later, or hope it never comes up? If we put in what we believe what we as a community must have, we are looking at having complex negotiation of things that might not actually need to happen. We may be increasing our risks of a putative award for a later condition not happening. Do the simplest thing that will work, and so the proposed text does not belong in the document. (Bob Hinden) Agree that this has nothing to do with the IAOC. We are talking about whether we the IETF needs to own IANA.org. Should the position of our community be that the IETF Trust owns it (if not operate it). We have more ability to negotiate that outcome than some time in the future. That’s the question the IETF should be debating. It is not a vague notion of the IAOC should negotiate something good. (Jari Arkko) More complex than that, since IANA.org is used by multiple parties. Want to make the observation so far that everyone at the mic line has said go to higher level requirements. The separation of MUST and SHOULD is a good thing. This is not the only thing we’re doing, the transition is not the only thing we’re doing. We make changes every year. We had some discussion today around those topics. You don’t have to do everything in this document, so support doing only the absolutely required things. (Geoff Houston) Though the aim of the doc was to demonstrate to the community that the NTIA doesn’t have a necessary role to the relationship with IANA functions, that they could walk away from this and the mechanisms in place would still allow things to function. The top level is saying “this is how we structure the relationship and things change, and here’s how the community can see what we’re doing”. It doesn’t need to say in precise detail what we’re doing and how we’ll react. Keep it general and as high as you can, and demonstrate that the controls and functions are in place and we are (ekr) support the points made. Don’t send people to negotiate with a precise program of what they can negotiate. Baffled that people think that’s big a deal. The notion that people will get confused about where to go for protocol parameter registry is bizarre. (John Levine) Thi sis contract negotiation and think there is a key role for NTIA. They were there in ICANN wanted to do something stupid. In some future incarnation of ICANN they could decide to demand money. It is important that we at least have an understanding of what the agreement is and how we negotiate if one side of the other needs a significant change. (Leslie Daigle - speaking personally) Making sure that the clarity of the IPR of the registries is important, and that’s another thing that mentions the IAOC. The high level requirement in the doc that’s a MUST - the IETF requires there is a stable reference on where to find the protocol parameters and how to operate the service. The implementation of achieving that, the paths are different between what you do now versus what you do when there is a problem and/or a desire for change. Another way to implement that there is stable references and clarity about IPR is to consider alternatives. This doesn’t have to be done as one flag day thing. Key points: fine with going with high level requirements in doc as long as we’re clear there are multiple possible implementations, and that a strategy for future change/negotiation Jabber room JCK - agree with Andrew that it is desirable to avoid solving problems we don’t have but agree with avoiding switching costs. Take it off this groups table and ask the IESG to consider a separate domain Martin Duerst - why not put nice to have in the draft; if another community has the same it would be a shame to drop it Dave Crocker - switching costs are not a risk, they are an expense Stephen Farrel - we do not need to own IANA.org (Russ Mundy) Has a seat on the ICG, but speaking as an individual. Heard several people mention the merger/single integrated proposal. That is absolutely the wrong thing to do. There will not be a merged proposal. There will be three or four proposals from the respective operational communities, and one letter or mini-cover piece of words from the ICG that states “here are the proposals, here are the overlaps”. The ICG doesn’t intend to merge proposals. The IETF’s proposals should/will remain the IETF’s proposal. Urge folks to take a look at documents that the FSAC (?) have produced. They talk about what the contract today says, and today’s contract specifically states there will be no cost to these functions. It also says the IPR of the registry cannot be claimed by ICANN. There are good and useful things stated in the existing contract that people may want to consider pointing to or extract from. (Jon Peterson) Some burden of reconciliation will eventually fall to the ICG (probably). Insofar as these things are up for grabs, deeply concerned that with all these things up for grabs we can lose our sense of mission. Hope you get input from people with broader governance of input. (Russ Mundy) each community should talk about what they need and want, and the ICG is looking for what collides. Those collisions will be sent back to the respective communities for resolution; the ICG doesn’t do that. (Jon Peterson) the stable registry requirement - I fear the ossification of our process that unduly binds us to procedures that may not be what we want to be in five years. I want IANA to evolve with us. (Richard Barnes) Stability is way low on the list of priorities here of what is needed to make the Internet operational. Can everyone today see the specs and protocols? We have a way to update RFCs today for errors in pointers. If you take the NTIA thing out of th machine, everything still runs. The domain name has nothing to do with that. (Randy Bush) We got here by riding on the front of the surfboard not lying down and paddling. When ICANN was formed, tried to get a librarian and a 15 year old with a modem on board. We are not responsible for ourselves, we are responsible for the Internet. We are dealing with one of the least transparent and least accountable organizations in our entire domain (ICANN). The horse will leave the barn, and it is our last chance to get transparency and accountability built in to what goes forward. They have cash and more lawyers than we have protocols. And we’re arguing over a domain name. (Andrew Sullivan) My view is that we’re trying to solve for a one-time transition. There rare some problems that are potentially dangerous in the future, and there are risks in that, but there are also risks in opening this far future up for discussion. There are things in this agreement that need to be moved around so they are incorporated into our agreement. We do not need to worry about the case where the operator goes berserk and we need to have an emergency separation with no graceful transition. That is insane. We need to engineer a practical solution for the problems we actually have. (Colin Jenkins) don’t see that the domain name itself is a must have; it is not critical. There are options about what will be available going forward. When we say our numbers HAVE to be at this domain that we don’t have control of us unnecessary. (Alissa Cooper) Leslie mentioned about the public domain; in that case, the term IAOC appears there because we don’t want the IETF to ask the other parties for this. Don’t care who asks the other parties to make the declarations. It would be nice if any party who could reasonably be claimed to have content of the registry makes clear that they don’t would be good. Keep in mind that the consumer of this is the NTIA and ask what the NTIA should do with the nice to haves. Their choices are somewhat limited. And to respond to Russ Mundy, the expectation is that there are substantive changes that need to be made to prevent the system will be sent back to the operators, but there should be only one final document sent to the NTIA. (ekr) To be clear, we’re talking about a list of numbers on a website. IANA curates that list, and the curation is important but the maintaining the website is not. (Andrei Robachevsky) When the NTIA announcement came, we though tee had a simple task because we are happy with how things work. So we need document the status quo, and the document mostly does that. But there are still some changes. The MOU operates in a changing legal environment, so we need to do a legal diff on the MOU regarding changing conditions. We should instruct the IAOC to do this legal advice, and supplement of rthe missing NTIA contract. (Dave Crocker) [jabber] IANA is critical operations infrastructure, but what’s been said is the stability is a bad thing. —— AD review came in this morning from Jari — see mailing list No blocking comments. (Eliot Lear) I agree with most comments except the last one. To be discussed. —— (Russ Housley) in an earlier discussion, there was a decision to ask the IAOC to consider jurisdiction and arbitration text. It was noted that if either party (ICANN or IETF community) is really upset with the other, there is a clause to end the relationship. But there is another clause for disputes less drastic, and those say the IAB decides. Do we need to discuss jurisdiction in any more detail? It sounds like the IAB decides. (Jari Arkko) We found out late about this text, and my general desire is to point to our existing tools rather than instruct the IAOC to add additional SLA clauses in our contracts. Don’t invent something new. (Brian Carpenter) we have already had that discussion. The IETF has done well by avoiding the word jurisdiction, and we should avoid it here too. We have managed to avoid getting our debates out of courts (patent litigation aside). (Marc Blanchet) To be inserted into the draft. —— Wrap up (Marc Blanchet, as co-chair) Do you agree with the changes listed in the section titled “I think we agree on”? [strong agreement, a single person against] (Peter Koch) Not really happy with the final bullet item, the coordination of special use domain names. (Marc Blanchet) Except of the last point in the list, do you agree with the rest? (Peter Koch) Yes, but some other mentioning of ICANN and the role of the various ICANN bodies that were proposed here. Will sent a comment to the list. Mention of .ARPA Didn’t have any comment so far. (Alissa Cooper) this is different than what she thought you were proposing earlier. Thought you were talking about what registries were in scope for this document. In this section, your’e saying no sections are needed. So why do we need to specifically call out .ARPA? (Eliot) if the IANA function operation changes, does this function change with it or not? (Alissa) so we’re expecting different things to happen in different protocol parameter registries? (Eliot) do you think that .ARPA is a protocol registry? (Alissa) we will have to be more clear. (Olaf Kolkman) I started this conversation by intro ducting ARPA in this text. .ARPA is mentioned specifically in addition to protocol parameters in the contract, so we should explicitly mention it in our response also. Not sure if it needs to be exactly here, but that’s the context. (Alissa Cooper) Agree that it needs to be separate in the list, but it does not need to be handled in the protocol registry component. (Eliot Lear) Can we talk about this on the list or in person to figure out where this should go? (Andrew Sullivan) The dispute here is that this is another one of the things that the current IANA registry operator is doing for us, and we need to list it. But it doesn’t need to be called out separately with it’s own special language. (Eliot) if it is part of the protocol parameters registry, we can define at such in the first part. (PHB) No, it is more complicated than that. .ARPA is really complicated because you have the reverse DNS in there, and so it’s an order between two spaces. This is more subtle than you might imagine, and we’re not the people that asked for this change. ICANN did, and ICANN will get the most benefit from this. So why are we saying we will only do reasonable negotiate? Be unreasonable and just take them. (Andrew Sullivan) .ARPA does not include the reverse; reverse is delegated separately underneath it. We are only talking about the TLD .ARPA, not the sub-delegation. It is just another protocol parameter and should go in the first list. (John Levine) To the extent there is a conflict in .ARPA, the administrative of that is a technical task that the IAB does as requested by the RIRs. (Brian Dickson) Wondering with the NTIA role going away, are we concerned about the ability to hold ICANN to task? Are there ways we can exert more control over ICANN? Such as delegating to ICANN all the name space except specific components, and so exert control over the root name space. (Jari Arkko) That is outside the scope of this WG. Outcome of .ARPA is : new version of text, where the .ARPA will be included as a kind of protocol parameter. ——— (Leslie Daigle as co-chair): We have good direction on most elements, and so we are coming out of WG last call (with some one big huge question mark re: the question of IANA.org marks). There is pushback on mentioning IANA.org at all in this document, and the reasons for that come back from the standpoint that this isn’t solving the question on the table at all. What we need to do now is find a solution to the problem of the existing transition and not try to solve for some future emergency. Should rephrase the section of text that keeps the operator obligations in existing contract, point three drops out altogether, and point two should be reframed just say that there is work done to ensure best effort clarity and continuity in face of existing work. (Ted Hardie) Is there more than that we really need to say than one and two? (Leslie Daigle) No. The intro paragraph will need to be revise. (Jon Peterson) Let’s take this to the list. (Leslie Daigle) It will be helpful if more people express this on the list. (Ted Hardie) Take a hum on removing the IAOC bit? (Leslie Daigle, as co-chair): If you agree with dropping the phrase that is about the IAOC… Please humm. [loud hum] Unanimous (Marc Blanchet, as co-chair): Expecting a new version of the draft to reflect today’s discussion.