IETF 89 London igovupdate Co-chairs: Marc Blanchet, Andrew Sullivan Mailing list: internetgovtech@iab.org 0. Administrativia (co-chairs) 1. Objective of the Meeting, Jari Arkko IETF relies on IANA, and it currently runs extremely well. The system has evolved over the years, and now has SLAs, MoUs, etc. Discussions here today are in response to the recent global discussion about the IANA function. Today's discussion is just one of several that will happen in many groups around the world. What do we think about this, and given we have a well-running system, how do we want to evolve it and what should the boundary conditions be. The IAB is in charge of the oversight of the IANA relationship. The IAB has an IANA program that is thinking about these topics. That program has produced various documents over the years, and underlying those docs are some principles. This session is abou reconfirming that we operate under those principles, and discuss any changes to those principles that might be necessary. Any changes or new documents will need IETF consensus to go forward. 2. IANA History and Context, Bernard Aboba, Olaf Kolkman 3. Guiding the Evolution of the IANA Protocol Parameter Registries, Russ Housley https://mailarchive.ietf.org/arch/msg/ietf-announce/rRn3N89AuGFcarSE7dL4o-Wvxao See slide deck in meeting repository (http://www.ietf.org/proceedings/89/slides/slides-89-igovupdate-0.pdf). Has 2 parts - a general overview leading up to principles, and another part with a lot of reference material. The reference material will not be covered today. See the principles posted on ietf-announce and igovtech.By reaffirming principles, the chairs of the IETF and IAB can speak more broadly about the principles supported by the IETF. This is not about the people on the ground performing the functions of IANA. See IANA Framework draft in progress within the IAB. The support for globalization of the IANA function is something the IAB has been recommending, on record, since the early 2000's. Globalization is important, but the stability and continuity of the whole system is also important. Having decisions made by others on our behalf (e.g., the US Gov't) is not appreciated by the IETF. The functional relationship between IETF and ICANN include many contractual things that manage and document that relationship. (Summary of principles - see slide deck for full details) 1. The IETF protocol parameters function has been and continues to be capably provided by the Internet Community. 2. The administration of the protocol parameters function by ICANN is working well for the Internet and the IETF. 3. The IETF protocol parameters function requires openness, transparency, and accountability. 4. Any contemplated changes to the protocol parameters function should use the current RFCs and model as the starting point. 5. The Internet architecture requires and receives capable service by Internet registries. 6. The IETF will continue its direction and stewardship of the protocol parameters function as an integral component of the IETF standards process and the use of resulting protocols. 4. Open Discussion (Jeff Houston) RFC 6220 has a couple of things that made understanding last sentence in 6th principle difficult. We need to clarify this to indicate we reserve the right suggest changes. There was a deep and underlying issue earlier - who owns the protocol parameter registries? Where is the principle that says if and when we reconsider, the content of the registries, the content of the registries go with the reconsideration. (Olaf) We don't have a good answer, and we have not pushed the issue enough to consider it resolved to everyone's satisfaction. (Jeff Houston) One of the hard lines in the past is that you may think you have control and may change those registries, but we disagree. (Russ Housley) Should the points Jeff made go in the principles? Yes, we should say what is in 6220, but how it ended up this way is that we merged the concept that Michelle is doing a good job and so we are not contemplating a change at this time. (Jeff Houston) That's fine, but we have to emphasize we need to reconsider that if and when we choose to. (Russ) Regarding "who owns the data", if we go back far enough, the government started this and the government cannot hold the copyright. The assignments are in RFCs, and recent ones have copyright in the Trust. We are not going to go to war with the lawyers if we don't have to. Should there be a seventh principle to say this? (Jeff) the RFC created the registry, but the contents were filled in by the operator of the function, so we should get appropriate copyright advice. If we believe we can reconsider the approach of the current registry operator, the registries move with the operator. If we are prohibited from doing so, that weakens or even prohibits principle 6. (Olaf) two aspects of this - the ability to move a complete data set easily, which includes making a change to the existing data set without instruction that fits in the criteria established by the IETF. Jeff talked about the first, and the second is a matter of those MOUs and SLAs. (Peter Koch) On principle #1, it says "provided by the Internet community" then speaks of third parties in the rationale text. In these Internet Governance discussion, we have had a distinction between the Internet Community and the Internet Technical Community. With the Internet Community, there are no third parties. (Olaf) Understand what you mean, but don't have a suggestion for alt wording. What is important is that in realizing that the IANA protocol parameters is in essence a mechanical function that should be governed by various policies, we believe that for the IANA protocol parameters implementation oversight by the IAB and IETF is sufficient for stability purposes. This is not to say that governments should not provide input into policy and standards - that is a separate discussion. (Peter) there is an implicit equivalent between Internet Community and IETF/IAB, and that will be questioned violently. (Olaf) I hear you, the wording must be more precise. (Peter) for principle 3, point to discussions during the week that for anything we need a new IANA registry, we need IETF control IANA registries that step into other peoples territories, including DNS. Big warning sign here. (Olaf) we must do appropriate coordination among the three pillars. We need to be conscious about this. This is one of the benefits of having the three types of the IANA functions together. It is there where flags can be raised that boundaries are being crossed. Having the discussion constantly and being responsible ourselves, that's exactly what we mean. (Peter) Might have missed the principle that says the three pillars ought to be provided adjacently. (Olaf) There are benefits in that, and not sure if this is an Olaf or an IAB position, but there is nothing in the framework that says don't move them apart. There are reasons not to, but it's not defined by principle. (Jari) You need the coordination, that's what's needed for the three pillars to work in sync. We are here to talk about the IETF views about how we do our business, not how other orgs do theirs. (Peter) True, but we could express a desire to have the debate/discussion. (Peter) Reserving the right to move the function elsewhere and supporting stability; missing a statement about financial responsibility and stability for running the whole system. (Olaf) It is a consequence of good stewardship, not a principle. (Peter) suggest mentioning in the rational (Fred Baker) The IAB in 2001 was looking at separating the parameter function from the IP address allocation function. It is not a principle, but an accident of history. (Olaf) the principle is that these things can evolve. There is a principle of stability that says evolution not revolution, and be responsible. We want to be in a position where that sort of evolution is possible. Maybe we can make that more explicit, but the current thinking in the framework makes that clear. (Fred) +1 on the seventh principle. If we don't do that, there is an assumption built in that is a matter of ownership and who is a service. The parameter function is a service to the IETF, and to separate that from the IETF without its blessing would be a disservice to the community. That should be part of the principle. (Olaf) We contract them, they don't contract us. (Fred) Re: principle #3. Agree with the principle, but worried about the set of people in the world looking for the word "but" and we find it in the first sentence. Suggest further articulation and clarity would be beneficial. (Dave Crocker) Re: principle #6. Interesting in 3 ways. The tag "The IETF controls its destiny" on the slide, but if you listen to the IETF talk, and if you listen to ISOC talk, the IETF is a subsidiary of ISOC. Which is not true, but we present it that way. There is a confusion that we all sustain that gets in the way when we get decision making. I think you mean "The IETF controls its production" - we control what we produce. (Olaf) That seems almost a seventh principle (Dave) With respect to the uninteresting registries, we could move them somewhere. If we decided we wanted to retarget control of the DNS root, we would be fairly stupid. Somewhere in the last few decades, a concept of eminent domain came about. Where we are today means in some abstract sense, we have that authority, but we don't have the power to go with it. (Olaf) That transfer or responsibility has taken place and is documented. (Dave) This slide says we can do that. (Olaf) No, we delegated that away, we can't delegate it back. (Dave) This slide seems to claim more than that (Olaf) If you frame a principle in this language, you loose nuance. This might be misinterpreted, but it is important that the second set of the slide deck has the references that should clarify the nuance. (Dave) A simple principle is great, but if it misses something so important, it fails. If ICANN truly screwed up, we would participate in discussions to fix it, but we wouldn't have power to control the answer. (Russ) "The protocol parameter function" is what we're talking about, not DNS root. (Dave) OK, never mind (Dave) to the extent the technical spec want to define a super root, that would be different because that's additional specification (Steve Crocker) Currently chair of board of ICANN. First, with regards to principle 7, as chair needs to be very careful to coordinate with others. ICANN does not have copyright to anything they publish. There is no issue there. If anyone wants formal documentation on that, STeve will pus that through ICANN. The only issue that Steve can imagine is if there were controls pushed at ICANN that says "publish, but only doing this level of publishing" - what is published is open and available to all, and only requests against that would cause problem. (Steve) Re: opening words, internet governance, and globalization of IANA. There is a complex and poorly understood trio of globalization efforts underway. One is, globalization of IANA function. Second, globalization of ICANN function. Third, broader discussion of Internet Governance which is broader than ICANN and IANA. (Steve) Fully understand and empathize with the model that the relationship between IETF and IANA, is parallel to the relationship between the IETF and the RFC Editor in terms of getting services from a vendor. What has evolved over time, however, is not as symmetric as that. The RFC Editor has moved from one org to another, and fits the model better of a direct vendor relationship. The context from the ICANN side involves more interactions in the broader global community that is somewhat challenging to see. The knowledge of the internet ecosystem is minimal. They are looking for a degree of stability that is qualitatively different than "Vendor Relationship". They don't understand how that actually plays out. (Olaf) I think what you said is "Be careful with the audience you are talking to when you use that kind of language; it may be misinterpreted." (Steve) The IETF has a budget; ICANN has a budget, and a substantial amount of budget supports the organizations. NO money flows from IETF to support the IANA function, and none is expected. We have not even quantified from an expense understanding to know how much it costs to provide the service. We need to make that part of the pictures that everyone understands. (Olaf) The intention is to continue with the relationship that ICANN and IETF currently have. (Susan ???) We glossed over the notion that "necessary coordination" and how that works. There will be a very few areas where coordination is necessary. But where it is necessary, it HAS to happen. This needs to follow the general interop principle. In some areas, that's a work in progress. (Olaf) agree, but that's on an implementation level. Understanding that stewardship and coordination is part of the equation and both need to find the appropriate language to do so. (Jonas Honnes) The principles are ok in the high level. They are going in the right direction and show the feeling of the room. Some wording needs to be adjusted in the rationale. Have a question about the new "principle 7"- I thought principle 6 was principle 7. (Olaf) Yes, but we need a change of words. Part of this is the copyright issue, but we just had the coordination to address that. (Jonas) What you have tried to reach in principle 6 is not to change vendors whenever you like, but that the IETF is the owner of its parameters. (Patrick Falstrom) We have some confusion in some questions that have been asked. These principles are to be read together. Never interpret any bullet point in isolation. That is something that needs to be kept in mind. (Patrik) You are not conflicting with the Tunis agenda, which means you are not requesting or supporting an initiative to have a full WSIS in 2015. It is important that you verify that the principles cannot be used in favor of having a new WSIS. (Olaf) That interpretation is correct. (Michelle Cotton) The whole team is to be thanked in IANA. Pearl and Amanda and the team at ICANN that supports with tools. Michelle will be taking this thanks home. (Russ Housley) Heard many things. Capturing the high level points: first principle - needs clarification about what we mean by the Internet Community second principle - this isn't a principle at all just a statement of fact, and maybe that belongs elsewhere third principle - remove "but" fourth principle - "this is a service to IETF, and that the IETF selects the service provider, not the other way around" sixth - "use exactly the language of RFC 6220, and be more clear than just the bold text at the top that this is not about names and numbers add an additional principle to talk about content of registries and think about an additional principle to deal with the coordination Can the community support the leaders using these principles to guide discussions. This is for the benefit of the relevant leadership, this is not for IETF consensus. Others can also use this to talk about the IETF. If you talk aback home to policy people within a company, you can say this is the position of the IETF. (Very Positive Hum)