IANAPLAN BoF at IETF 90 Toronto, ON, CA 2014-07-24 09:00 local time (13:00 UTC) Agenda: - Preliminaries and agenda bash (co-chairs) - Introduction (co-chairs) - NTIA transition in the larger Internet community, and the Coordination Group (Alissa Cooper) - What does the transition mean from an IETF and IAB perspective? (Andrew Sullivan) - Discussion - Review of proposed charter (co-chairs) - Discussion of charter - Close/any final questions (AD) ------ Notes: - Co-chairs: Marc Blanchet, Andrew Sullivan - Preliminaries and agenda bash Scribes: Heather Flanagan (notes), Ted Hardie (jabber) - Introduction (Marc Blanchet) This is a working group forming BOF. An important goal is to see if there is consensus in the community to form a working group. The typical set of BOF questions will be asked at the end of the meeting. History from IETF89 igovupdate (see slides) - NTIA transition in the larger Internet community, and the Coordination Group (Alissa Cooper) (slides 1, 2) Brief and recent history (slide 3) NTIA's transition plan criteria (slide 4) ICANN facilitation (slide 5) IANA Stewardship Transition Coordination Group (ICG) (slides 6, 7) Draft ICG charter (slides 8, 9) Draftier request to communities (slide 10) Even draftier timeline (slide 11) Next steps (slide 12) References Q&A: Olaf Kolkman (wearing no hat) -- we will have to ask process questions as we go, and we will have to invent some process in order to answer questions you come up with as representatives in the ICG. One question now is about the finalized charter. That means that the charter that you presetned the outline of is rough but very advanced draft. Is there an expectation on the ICG side that you will need something of a consensus about that charter and if there are un-eases in the community can you bring those back. If you were to ask that question, I would say the charter is in pretty good shape, clearly pointing out that the IETF is one of the customers of this thing and identifies us almost explicitly. I would support the charter, but is there is an ask from you to the community about endorsing it? Alissa: We felt pretty good about the charter, but we want input from the community. The charter is open for discussion for two weeks (until next Friday?) For matters of internal organization of groups, it is more important to set a marker down and keep moving than to run a big consensus process for every single thing that the ICG does. The communities need to focus more on their own processes. Lee Howard: did not understand about testing. Alissa: in the IETF it is hard to wrap your head around. We do not interact with NTIA now, so testing how we will interact without NTIA is difficult. But in other situations, if a new accountability structure is created, then you want to run your system that way for a few months to see how it goes. The other thing that has implicitly fallen in the testing bucket is scenarios analysis. Brian Carpenter: I have complained about the length and complexity of the charter on email, but did NOT complain about the wording. The other comment is about the polite argument being held with Avri via email. There is something we can test - if there are liaison relationships for coordination within the major blocks, that we haven't been explicit about in the past, those new liaison relationships would be testable. Jari Arrko: More info on testing and an example. The arrangements for IANA are not a static thing. Every year we add new things to the contract. This year it was a requirement for an audit that would show the database or record location function is following the policies set by the IETF. Once this is run the global community can see that things are working. Since it is in this years SLA, it will not be available now, but look for it next spring. - What does the transition mean from an IETF and IAB perspective? (Andrew Sullivan) (slides 1, 2) Stuff requested Russ Housley: missing an important accountability mechanism which ties to our normal appeals process. Important to talk about the fine-grained mechanisms as well. Andrew: Absolutely correct. We have running process to handle things. (slide 3) A suggestion Russ Housley: Please explain the bullet, because we do not have a contract with NTIA, we have one with ICANN Andrew: the point I'm making is that we have a contractual relationship and that isn't changing; their contractual relationships are what's changing. (slide 4) Have we done everything? - Discussion Brian Carpenter: I am an advocate of "if it ain't broke, don't fix it" but something you said before is complacent, and that is that "everything is working." We need some self-examination before we can really make that determination. I am of the opinion that we don't have major things to fix, but we should look at any cases of coordination failure that might exist today. John Klensin: As an observation, channeling conversations on the list. There is a critical issues that differs if the accountability procedures are self examination, or if there is an opportunity for review by an outside community. We are operating in self-examination mode and have done so successfully, but at various times we expect other organizations to operated in external evaluation modes because we don't think their self-examination modes don't work. If we expect other organizations to be accountable to external review, we may be asked to defend what we do more strongly than before. Andrew Sullivan: the observation on the previous slide, that the contractual relationship that's changing is between IANA and NTIA. The ones between us and IANA are not changing. Our relationship is an external body that's overseeing that policy. We are not responsible for the other part. Do you think you're talking about the NTIA oversight of IANA or of other communities and their oversight of stuff. John Klensin: you are engaging in hair splitting. Russ Housley: responding to that point, we don't have a contract with NTIA, that's going away. We need to make sure a spart of this analyssi that our contract with IANA is sufficient to get everything we need in the new world. Peter Koch: much of this is an education exercise. Documenting practice is a good start. There are a couple of things developing in the recent past, that we ourselves are reacting the boundaries of the MoU between the IETF and IANA/ICANN. The timezone database is an example. The IETF is one customer of the IANA/ICANN; assuming the IETF has the monopoly on protocol parameters might seem strange to the rest of the world. The IANA taken as a metaphor as the policy development for our registries. An example is the possibility of someone not getting a code point assigned they want pointing at IANA as IANA's fault. "Do nothing" is one option, but would like an escape route or a plan B that may not be for the ICG, but needs to be discussed internally. That might include adding figures to the contract about the costs of the whole thing at the moment so we could put up a tender for a new operator. Elliot Lear: Agree with Russ on the overall point, that we should be looking to see that we've covered everything. But I want to make sure we cover metrics. Russ has suggested that needs to be handled through the IAOC, and so I like what you have in the charter. Second point, one of those little nits, when we wrote the timezone database we made the deal with the ICANN not the NTIA. Brian Trammel channeling Eric Burger: Please don't take this as an opportunity to change things. Jari Arrko: Strongly support the idea presented here not to do too much of a change; stability is important. But am respectful of the comment that that's being a bit complacent. This is a good direction, this is the direction we are thinking of. At the end of the day we need the document that explains all the different cases and all the details, and will identify if there are other pieces needed. Also want to mention this "plan B"--those are in our minds, and we are considering them. We do have the IAB and iana program thinking about this whole system, and are considering plans for different scenarios. Lars-Johan Liman: This is a good starting point. One thing that could be added, even if we don't have direct contractual relationship with NTIA, if we remove it and replace it, we must look at the pressure balance in the system because it changes. The replacement may have an impact on us. Bernard Aboba: It makes sense not to change anything with the operator. In terms of existing contracts, many clauses in the contract between NTIA and ICANN are things we asked for, including: intellectual property protections, transition itself is specified itself, the IETF is contractually through user documentation becomes rule setter for IANA, ICANN cannot set policy. There are a bunch of protections in that contract that we don't want to lose. Jari Arrko: That is exactly right, and what I meant that we must write that document to captures those details. Leslie Daigle: Liman already made the points I want to make. "If it ain't broke, don't fix it" but, when Russ framed it as "does the current MoU work even if the NTIA contract with ICANN goes away" that's missing the point that the NTIA contract is not just going to go away, some other frameworks will take its place. Our existing contractual documentation will not be accurate. It is a good starting point, but it is the fourth bullet on A Suggestion slide that I object to. Last three words should be, observe what's going on in the rest of the conversation and when the dust settles, is the IETF the generator of protocols and parameters, and are we the only one? Alissa Cooper: Agree with the general thrust here. Relaying a conversation with the ICG last week, our process and relationships that we have are well understood by people in this room. The transition plan needs to be understood by a broader audience. You can't just throw together a list of references and expect people to understand. This plan will go well beyond the IETF to people not familiar with our systems. Russ Mundy: happy to be a member of the ICG, but not speaking with that hat on. One of the things that has caused help and confusion is the NTIA contract itself. It is big and long and painful, but it does contain many useful pieces of information. Bernard made good points earlier, that some of those things were placed in that contract at the request of the IETF. Whether or not all of them, some of them, more, less, different still belong there needs to be examined. The bigger thing is that the IETF has the easiest problem to solve, with the numbers people being second, but the names people having the hardest of the problems. Tht IETF needs to document things as quickly as they can because this can become the example that the rest of the community can take and follow. The IETF has the most well-defined set of things to be looked at and will help the others. Jari Arrko: agreeing very much with Russ Mundy. Continuing the thread of Leslie and others, re: the need to interact with the rest of the system and document those interactions. The rest of the system does change, and we don't fully understand what those ways are, and we need to understand that better. There is overlap and interaction points between the broad categories of things that we need to document and understand. The NTIA is going away, but I don't think it is being replaced by another "super entity" that would have special oversight over things like port numbers. Larry Masinter: I made a point on the list that some of the IANA registries are not working so well, such as around URI schemes and MIME parameters, esp. at the application level where people don't bother registering things, and where other SDO can add things to the registries without consulting the IETF. The response was satisfactory, in that those are part of the existing relationship. Not sure if those are going to be handled later, or handled now in figuring out the new contract(s). The system we have resolve that, it would help to make it more explicit that if you want to say IANA should offer a way to insert comments in the registry, how would we institute that in the existing and new framework? John Levine: Agree with the suggestions that there are things in the IANA contract that we should look at, but one of the most important things to remember is the fact it doesn't cost us anything. Should the contract go away and the cost go up, that could be a problem. Jari Arrko: responding to the cost issue, not too worried about the cost part. The reasons why it is set up like it is will continue after a transition, regardless of whether NTIA is there or not. The motives remain, and even if things do change, cost shouldn't drive the good solutions to our problems. The good of the internet should drive the requirements. - Review of proposed charter (slide 1) Content of charter draft charter has been circulated - Discussion of charter John Klensin: you have captured my objection to the charter. A charter that long and complicated is almost equivalent to no charter at all. I don't know how to fix it, but it's a problem. Andrew: there is a lot of background in there that I felt needed to be captured somewhere, but without it, anyone who came to this without that material would be lost. Brian Trammel channeling Eric Burger: I was convinced by Andrew's thought that we needed a venue for consensus. I don't see this charter as longer as more complicated than others, and that newbies would be confused without the background. Eliot Lear: Agree with Eric Burger; I don't think that if you go down to the milestones, these are fairly general. The only question is whether the dates, esp. the May dates, are possible. Dates in charters tend to be so fluffy. The charter is well written and a good starting point. The one question is RFC 3777 - don't know what updates to that means in this context Leslie Daigle: want to make the IETF aware that the different groups don't understand IETF function. Having a WG makes this an obvious landing point for people not already in the IETF. For them, there needs to be very clear context setting. Whether that belongs in the charter and listing them out, that makes them something of a target. Larry Masinter: we are not setting them aside for future consideration, we are assuming they will be handled in the framework that will be established. Will propose a better sentence on the list. Bernard Aboba: one way to think of the existing contract is that the ICANN can update those documents at their discretion. The IETF can have a WG to update stuff, but that has nothing to do with the arrangement. A best transition plan allows you to update these outside the transition plan. Alissa Cooper: The WG might want to review, comment, and evaluate proposals that impinge on the IETF, not just protocol parameters. Jari Arrko: Bashing the traditional working group forming BoF questions. Do we believe we need to have a forum for this topic? Bernard Aboba: One other comment, under RFC 6220, there is an org that owns the contracts with IANA, and that's the IAOC. Need to consider how this WG would work with the IAOC. Andrew Sullivan: there is text in the charter that says the contract must be negotiated with the IAOC; is that sufficient? Jari Arrko: This WG is to discuss the IETF processes and RFCs about how we view the IANA organization from our perspective, and the actual execution of those process belongs to other organizations such as IAB, IANA, IAOC. Brian Trammel as Eric Burger: Is there a real problem here? Yes, but not a typical IETF problem. It is not a technology problem. Andrew Sullivan: in order to satisfy this, the first question that the way you expand problem is "documentation to be done and agreed to, investigation of the various contractual language and whether there are gaps, and understanding of what the agreement of the community is." those are the potential problems a WG could solve in this case. CONSENSUS (yes: loud hum; no: silence) in the room on there being a problem here MAJORITY hum, but some level of no on understanding the problem Geoff Houston: no, I don't understand the problem. The NTIA role in terms of what we, the IETF, and our protocol parameter registration function has, the NITA role's is nothing. If the topic is the transition of the NTIA role to something else, our function shouldn't change. On the other hand, there does seem to be a view of "while we're at this, ..." re-engineer because we can. If that's the problem you want to solve, that's fne, but it has nothing to do with the NTIA. If you are looking to provide the NTIA that they can step back and it would be fine, the worst thing you could do is to say "we're going to change everything". This is simple: they weren't editing our protocol parameter function, they were saying ICANN can do the job. If we were confident before, we should say we're confident now. Olaf Kolkman: I hummed twice. That is debating with Jeff; I am in Jeff's camp re: that we don't have a problem. We have a good relationship, we have good documentation on what we expect from the vendor. But I am also in the camp that we are not on an island. We work with other communities in a complex environment. We have an opportunity to explain/make clear that what we're doing is rock-solid. If the problem statement is that, I'm on board. If the problem statement is to change everything, I agree with Jeff. Pete Resnick: Generally agree with Jeff that we are rock-solid, and we should express that. Even if I go completely down that pass, an IETF WG documenting that is a fine thing; that expresses IETF consensus. One point that's a bit worrying, and that is the NTIA is one stick we're pulling out of the pile that can shift the pile quite a bit. This WG should consider if there are side effects that would impact that stability. We should look carefully at those possible side effects. It is worth forming the WG, we should look at those effects, we should do as little as possible to change the state of affairs. Russ Mundy: In agreement re: type and quantity of change. I've read through all the contractual material. The way it is written, it's not clear how many things in there that relate to this functionality, are things that were really desired by the IETF and put in because the NTIA were trying to be helpful, or if they were things thought up by bureaucrats in Washington. This is something the WG need to give careful thought to. Would put the things that go on relative to that functionality into two groupings. One, the mechanical, operational, here are things that happen. Two, how do we measure the quality with which this is done. These are things that show up in the NTIA contract. How much of this quality kinds of things are needed esp, if we're happy with things today. Jari Arrko: In response to Russ Mundy, those quality controls are in our SLA, so we're better off than people who just read the contract language might thing. Next point, agree with Jeff Houston. There isn't much to do, but we're letting ourselves be confused by the "problem" word. In retrospect, a better way to phrase that is "Does the IETF need to express it's opinion on how IANA will be going forward?" Of course yes. That guidance might be "don't change anything" Alissa Cooper: I think if there is a question about whether we need to respond to the NTIA request for the piece of this that is the purview of the IETF, that question should be asked. If people thinks we don't need to respond, that's important to know. If people thing we should respond but not via a WG, that should be known too. There might be people who thinks we don't need to respond to this; thought that is what Jeff was suggesting. Bernard Aboba: How many people in this room know what the iproc is? That is the group that includes members of the ICANN, IAB, IAOC, that oversees the IANA function. It might be a good idea to document the workings and procedures of that organization. Andrew Sullivan: to address what Jari and Alissa have asked for. - Do we need to respond to the NTIA, yes or no? (majority yes; CONCENSUS) - Do we need we need a WG to do that, yes or no? (large hum, very few no) - do we know what else we need if no? (for those who said no, have no alternatives) Jari Arrko: I do think we need a WG. We do have the IAB and ianaprogram who are formally responsible for this. They have done most of the leg work. This is an important topic, and you should get the IETF opinion on this. The WG should confirm the opinion and work with the ianaprogram. Geoff Houston: the IAB has a responsibility for a number of things, including the RFC Editor and the protocol parameter registry. We handled the RFC Editor transition well without a WG. The function fell within the natural parameters of the IABs role. They could work within the administrative framework of the IETF. We are not changing what we expect of the IANA role. We still think it is a contracted function. This isn't a difficult problem, and to give the NTIA confidence that they were not a foundational piece, we don't need something special. It is an IAB function that should be documented and sent to the NTIA. Don't create new stuff just for this. Leslie Daigle: It is a comforting thought to have the IAB take care of it, but the difference between this and the RFC Editor situation, our view of the universe is not the totality of the universe. It is not as straightforward as the RFC Ed situation. The community will expect to have had an opportunity to provide input. Brian Trammel: Agree with what Leslie said. There is a need for, at minimum, a venue in which we can evaluate IETF consensus in a smaller room. I would like to have an alternative to taking this to ietf@ietf.org Ran Atkinson: Mostly agree with Jeff Houston's analysis. The minor difference is, it could be useful to have a WG to demonstrate to the rest of the community that we collected input. But I don't want the output of this to be more than "the way it works is fine; the IAB represents the IETF in this manner, and we want to continue to have the kind of independence from third parties going forward. Do not micromanage the IAB, but provide a forum for input, and reinforce the notion that the IAB is allowed to act on behalf on the IETF on this topic. Andrew Sullivan: Repeating something on the list, normally this would be the IAB, but the NTIA has explicitly mentioned the IETF as a specific group, separate from the IAB, to get input. If the NTIA wants the input of the IETF, we only have one way to do that. Jari Arrko: The IAB and the program is in charge and they should do most of the work. It would be useful for the IAB to have a place in the IETF to collect consensus. We have done it in different ways (e.g., ietf@ietf.org) but that's a detail. We don't want a WG that comes up with crazy ideas and tries to redesign the whole system, but that's not the intent. This is a place to confirm the IAB's opinion. Why do we need this? it's not just because the NTIA mentioned our name. It's the fact that when we go to other groups, saying "the IETF community believes this" that has a huge amount of weight. Erik Nordmark: Agree with a number of things that have been said, and trying to find a path forward. We are looking at the ianaprogram as a design team that feeds input into a WG. The key thing is to write down what isn't already written down in an RFC, some things that are only in the contract language now. As the different communities come together, there might be input that we have to respond to, and there needs to be a place to have those discussions. Being able to have a place to gauge IETF consensus to capture things not written in RFCs, and a place where we can react. Bernard Aboba: to elaborate on something Jari said. It would be useful to have IETF consensus on points in the NTIA contract. If we have input that the intellectual property points are mandatory, and the consensus is clear, that's very useful input. This WG will probably not be useful in that some of the broader work has come with very very short time frames (like 2 weeks) and those things should go to the IAB where they can be handled more expeditiously. Ted Hardie: +1 what was said about the timeline problem. It may be useful to take Erik Nordmark's formulation and apply a bit of recursion. The ianaplan group is both a design team for the WG, and the WG is a sounding board for the design team responses to the NTIA. - Close/any final questions Andrew Sullivan: does the sponsoring AD (Jari) have any further questions? Jari Arkko: didn't hear a lot of opposition. Andrew Sullivan: some adjustment to the charter needed, but not radically wrong. So we have heard what we need to hear, yes? Jari Arkko: yes, we have talked about the overall situation, the need to support stability but make sure to document anything missing from existing documentation. The IAB and its program in charge of the issue, but they will use any WG list as a sounding board and a place to confirm consensus.