Autonomic Networking Integrated Model and Approach Chairs: Toerless Eckert & Sheng Jiang IETF104, Prague, Czech Monday (March 26th, 2018) 2-hour session: 13:50-15:50, Meeting 1, Afternoon session I ********************** Abbreviation of names: TE - Toerless Eckert SJ - Sheng Jiang IB - Ignas Bagdonas EL - Eliot Lear LC - Laurent Ciavaglia EN - Eric Nordmark KW - Kent Watsen MR - Michael Richardson PS - Peter van der Stok ************************* ******************************************************************************* 1. WG Dash - by co-chairs 13:50 - 13:55, by co-chairs [IB] First thing not issues, just to give the context. Over the last year, I've had approached by 4 people saying that both of the co-chairs of ANIMA have the same affiliation. And while I don't necessarily see this as a problem. And That's not something unique. We had such cases and actually have such cases too. What I would like to do is to ask the working group whether they see this as something troubling. And if yes, what should be done by that. I am simply relaying the feedback the community that. They notice this and they ask such a question. So just to be very clear this is not an escalation from AD saying that something is not right. This is providing the feedback from the community that I got. So if you could discuss that and I think the whole working group could discuss that would be good. (To Eliot Lear)If you have something to stay for example right now come to the mic call it open mic very briefly and state your opinion [EL] Responding to Ignas's point. I didn't notice that the both chairs have the same affiliation. I have not noticed that this has been a problem. And I would raise the issue if I thought it was a problem and at the moment I don't see it and until I do see it for me it's not a problem. [LC] I also noticed changing affiliation but it was more than a year ago something like this. But I've not seen any issue so far in how to work a new chair I've been managing the group or the document so far for me it's not an issue. [IB] Anyone else has anything to say？All right, so can we do like this and that let's keep this window stay open for a week or two weeks after the meeting and if you have anything send out to the mailing list. But the message that I'm getting that this is not a problem for the working group at this time. I think that will be just silent closed and that's it. Not the working group I mean. *** Sheng Jiang continues on the slides. [IB] So this is what I was going to ask. Both the responsible ADs and one of the AD's holding the discuss will change this week. So I think it's already too late to try to do anything here but basically what is your plan of addressing that. The responsibility is still the question moving historically that has been on the (??? @ 11:26) side. Maybe it will happen we had a brief discussion with Eric. Maybe that document will come to me which will be probably more logical but I think that doesn't change the discussion hold a problem. As one of a security AD is changing. [TE] So from the understanding having talked to other folks. Eric is leaving and so I can show the changes done to resolve the discuss and that there was done against the review from Eric and from Benjamin. And so I would our expectation was that hopefully Benjamin would take care of reviewing both of these feedbacks. Because there were also a lot of the discuss were overlapping. The third one from Alissa actually and (Jen art ??? @ 12:14) I think was already resolved last time. I just didn't try to ping Alissa to say clear the discuss because I first wanted to work on the big chunk where was a security one. So and if basically Benjamin is to overload it I mean he does a lot of things then willing to find another reviewer. So otherwise I think he could maybe take care of also Eric's. Because he's kind of you know he spent a really large and goode amount of time in reviewing that. [IB] So if you're asking me right now. I don't have what to answer. I'm just saying from CMO from administrative position what's the situation of that. But if you say that the discussion of the Benjamin is ongoing I think that is fine. [TE] Yeah. So I think Benjamin said that obviously after IETF he can come back and review the -19 and I think at that point in time we can check if we need to get somebody else involved or if you can take care of Eric's feedback as well. And I'm not just saying it from the perspective of I think he would be the best person of already having delved into the matter and having all the discusses. If there is some you know IESG process that says somebody else needs to do it then. [IB] No. Simply discuss needs to be cleared by the AD arising in the discuss. Once lady changes it's the new idea which inherits that well in head of the whole document and he has to go through naturally he probably doesn't understand the whole context and other things that will just delay things. [IB] While you had a previous slide on the actual BRSKI. So I've been looking into the comments which are coming in as resolution mostly for the IOT directorate. And I believe that addresses most of the concerns. And in a current state of waiting for an AD write-up I would say that once you feel that you're happy with those commands as the changes which we went into the document are substantial. We'll need to do an IETF last call for that document once again. Once that is done, it will progress. (Sheng Jiang: Yeah, thanks) ******************************************************************************* 2. WG Document Update (25 min) 2a. Autonomic Control Plane - 10min 13:55 - 14:05, by Toerless Eckert, draft-ietf-anima-autonomic-control-plane [EN] So that you said there's issues dealing with as CRL and OCSP servers not being reachable. But you control the other end of this communication, right? You could mandate OCSP stapling and be done with it. [TE] That's true, but if that node is attacked and compromised, it may not do this anymore. [EN] What mean not do it? If you don't get a staple, you say 'yeah I'm not gonna talk to you'. If the staple is bad, I'm not gonna talk to you. [TE] Right. But I think one of the points is also that as I said later in the slide deck that we want to support the case where you don't have your (knock back-end?) with all these big servers running. So if you basically just connect three or four ACP nodes together at that point in time. None of them may have OCSP or a CRL. [EN] Well, they would have certificates and they have connectivity to the OCSP server I can vouch for that certificate. They're a complete Island where they can't act anything. So you don't what know time it is either because you don't want to be ready. [TE] No, No. I mean if I look at typical deployments that we had like let's say a site in an enterprise that is losing its internet link and all the big servers are basically behind that internet link. You still have locally in the site the ACP running. [EN] But Is this only the issue when you're on board new devices? [TE] No, There's nothing to do with onboarding. ACP is not about onboarding. [EN] Okay. Pained yourself in the corner, but okay. [TE] Yeah, I mean if you have any better ideas on how we can deal with that. I mean the whole point is trying to find the right balance between security and connectivity. And that's what the (text?) is trying to do. [EN] This sort of like initial thing and then all I have is a thin straw to drink through. Being able to .... [TE] That is perfect you're running network. But basically it's too expensive to cumbersome to basically put CRL OCSP server in each of the five hundred remote branches that you have an entire enterprise. But you have basically in them twenty or thirty switches that basically are hopefully in the future becoming more and more... [EN] If you're doing CRLs or so you end up falling back to not providing any security from OCSP or CRLs. Because you're saying that if I'm can't connect to the internet I can't talk to that OCSP RCL server(TE: It's fancies). I'm gonna run in an insecure mode, right?(TE: No.)Because I can't check the validity of the certificates. [TE] Well, another way there is also (text?) already that is basically pointing to the fact that one way to introduce security in these environment is to work with short-lived certificates right so that basically you use simply the certificate expiry as one of your based security mechanisms [EN] Well sure, but my point is that stapling doesn't change any of this. It just makes your thin straw be more useful. Because you don't have to worry about I can reach a server but I can't reach the CRL or OCSP. I mean you can have the same policy choices saying if I don't get an OCSP response in their response that stapled what is my policy of how to operate in that case. Because it could be that end that's a local guy in your enterprise you couldn't talk to the server anyhow. And that removes you as the person who might have very limited connectivity from trying to deal with that complexity. So I think that you're not removing any policy choices. You're just making it simpler. [TE] Well, so let's say that right. So I mean the solution for the ACP was also done a lot in conjunction with the BRSKI authors. Unfortunately, some of them are not here today and one of the consideration was to basically keep the solution simple and there was kind of the operational experience that OCSP and CRL do make operations. Let's say for example more complex than short-lived certificates. And from that kind of the conclusion that maybe what we try to do in this first version of the ACP is to try to come up with a good reasonable minimum subset. Now if you want to have a policy for stapling, I think that's fine. We have raised in the certificate to add extensions and given how this policy is something which I think should be carried through these certificates. So otherwise that we have no way to provision. Maybe that would be a good very simple to a three-page modification that may be basically we're saying certificates with a particular extension they mandate the following for people who like CRL or OCSP. And just I mean we already I had a lot of fight for any option that I introduced. So I'm trying at this point and not any more options at this point. [EN] I figured out if you could reduce some things by making it simpler. I don't understand how short-lived works when you disconnected either because I can't get a new certificate, right? (TE: yes)If it expires during the night and whatever the time span is a month and then how do I deal with having a lack of connectivity when it expires. [KW] So first I think I'm not sure if you remembered. But in the voucher itself there's a leaf, I think it's called revocation checks required. Which is to say it's an opportunity for the policy to be specified whether or not. Or CRL or OCSP is mandatory, critical. So I think we already have the hook in place in the voucher. (Peter talks? @ 38:12) And then my second response to the Peter's comment is that the short-lived voucher if expires in the night. I think the intent is that the voucher is actually ephemeral and that is only being used to do the initial bootstrap then once the post has been completed it's unnecessary. [MR] So yeah we had a lot of discussion of it whether or not we would include CRL in the voucher process. And we made the vouchers very short and a response to that. Because if you're not at all online you have these other problems within just it doesn't work anyway. As for the ACP so and keeping the whether or not you're gonna have connectivity if your vouchers if you are short vouchers expire. That's an issue. And it's an issue whether you have CRLs or OCSP or whatever. So if parts of your network are falling asleep or whatever such that you can't do this then that's an issue. I think that is essentially all controllable by the certificates that the registrar issues if it issues them with OCSP stapling instructions then that's what will happen if it issues it with CRL points then that's what you'll do. There's lots of IPSec implementations in the other hand that kind of just go that's too hard. And so be it, there's quality of implementation issues and there's other things. But mostly what I would like to see is I'd like to see if you have an island network that has no time. It could have time from GPS or something with no internet connectivity. It could have time because the power hasn't gone off and it trusts its RTC. Just the fiber was cut its back whole event earthquake I don't know earthquake not in your location somewhere else. Then the hope is that if you had unless you believe the certificate is bad even though it expired you might still use it anyway. And if the rest of the network has convinced your certificate is bad and they won't talk to you anyway. So I think that the in many cases operationally we're gonna have to have an experience I think that operator is going to say I would prefer a little bit of insecurity to loot having to send a person an airplane to reset that a piece of equipment. But at least as BRSKI it would be a low a person someone who just knows how to push the button not someone who knows how to reconfigure it. [TE] I mean if any of you I would really encourage you to read these sections where this is done and the diff between 18, 19. Should show you those places easier and if you have any specific text you'd like to suggest there's something you really feel how is strong about doing now. Please send that to me and the list otherwise you know as I said I think it's easy to add more policy options through the certificate details are just describing the ones that already exist as Michael said. And hopefully then because I just really can't see that one option fits all and I think at this point in time if we start documenting even more options I think will never end here. ******************************************************************************* 3. Potential New Charter Unscrambling - 30 min 14:20 - 14:50, by co-chairs [EL] First thanks very much for your hard work on the Charter. This charter looks pretty good. A couple of comments about BRSKI and also the I think the last line in your in the Charter text about gating work. So I see the desire to implement class-based QoS in the draft q. And so which I think is interesting we have to I think be a little careful of head-of-line blocking in this. From a BRSKI perspective, Michael might want to comment on this a little bit. And I know that Steffen and Thomas might also want to comment. I see that there are quite a number of drafts as you do too. My view is that we should probably take some time in tomorrow's IOT onboarding session to see if we can spend just a little bit of time mapping all the work. So that we can organize a little bit around the principle that you're following here in terms of how work is delivered. I would only ask that you not be too firm in terms of how many drafts you're taking on just to avoid the head of line blocking but also I do think this allows for a certain amount of discipline in terms of making sure the works are at least somewhat baked in order to be adopted. Now I say somewhat baked because I don't think as a working group you want them fully baked when they come to you. You want them you want to have at least maybe an implementation to test against, But you don't really you want to have the opportunity for change rather than having people interoperability test before you even adopt the work. So with that caveat in mind my suggestion in terms of filling in the blank for BRSKI is this is something that I don't think you're going to be able to solve in this meeting today. I think it's probably something we need to talk about tomorrow and then take to the mailing list once we've had the discussion tomorrow. Is that okay with everybody know about side meeting tomorrow it's two o'clock. And it's I don't remember the name of the room but it's in the 104 side meetings wiki. And everybody is welcomed, there's plenty of room in fact, there's more room than there is in this room I think. [SJ] Actually we fully noticed that there's a bunch of the BRSKI documents newly submitted. But there are two sessions we want to make sure. One is for now the BRSKI still not fully completed. I mean the main draft. We would like to the working group particularly those BRSKI relevant people to review that draft and if possible to contribute to that draft? it to be completed as soon as possible. Then that's a time we can discuss how many drafts we can follow up and what just now Toerless present. There is you know what we set up for the initial milestones and obviously we don't want to show our IESG we try to ?? your version at the beginning. But after we gets our new Charter approved we could have say more flexibility during the working group procedure. If there's enough manager and enough quality work to guarantee working group outputs then we can do more work. [LC] Some comments made essentially for clarification. Forget the beginning you mentioned we work on protocols and procedures. Is it to be to I mean constraining that nothing else except protocols and procedure can be yield the outcome of the working group？ But maybe this is something we can improve. Can you go out at the beginning of the text please ? So I mean in the sentence you mentioned interoperable protocols and procedures. So if this is the only type of outcome or that we can think about other things such as mechanisms or I'm not fan of architectural framework. But maybe sometime we will need other types of output. Just don't make the Charter too constraining on that. If you go to the next page please ... [TE] Just as a comment, right? I mean this was a little bit written in fear of the same type of discussion of useless documents as perceived by at least IESG we've seen in the past, where useless includes architectures, use cases, requirements which I don't agree with. But I think we should have if we do anything like that doesn't focus on interoperable aspects then I think we need some strong evidence that these are useful as far as the working group sees and what the ... [LC]I understand the where it comes from and the constraint. But just mapping for instance to the draft or work. Is it I'm not sure it would be a protocol but not sure you can call it a procedure. So you see I don't see it in the mapping here. I can live with that and just ... [TE] I think procedures right. I think the lifecycle account under procedures. [LC] Yeah but life cycle can also rely on the model and some mechanism inside... [TE] do you want to propose explicit text I think because I especially now that I can't... [LC]Maybe I will send some from the offline proposal. The second page please. Just on the second bullet points just for clarification you mentioned lifecycle management including coordination and dependency management. It clear what dependency means here because I don't understand what dependency to which to what. [TE] Wasn't that the term that you I was hoping I was using the term that you were using in one of the drafts that you were showing which was the dependency graphs of the dependency, is it? [LC] hmm I'm not using the term that the same meaning. Mean if you think about dependable components or... [TE] Dependency graph, right? So the dependency graph between the different components so that you can resolve... [LC] xxx xxx [TE] If you have a better term sure that I hope but I hope you know what (LC:I know but) yeah please suggest better (LC: okay then next is... ) [LC] Again not the last bullet just the one before you mentioned generic use cases I don't know exactly what is a generic use case for major. Use case is a use case. It's very difficult to make something generic out of a use case my question is more like I mean if I want to go into some use cases we have to clarify what will be the output expected by the working group, to come back to my first comment. If we have protocols and interoperability protocols and procedures what's the expected outcome or form of the outcome of that can go from the use cases. Again just a comment maybe we don't need to - and you mentioned autonomic SLA assurance just for the record energy one of the initially you can both use cases was published as an RFC last year on autonomy SLA violations. So this can be either an extension or needs to be clarified easily if the same thing or not. [TE] So I couldn't take good notes of that so if you have specific suggestions for the text I think that would be even better than us trying to convert your thoughts and... [LC] Okay, I'll write offline can you go to the last I'm not sure I have something... just yeah... that's was okay. Thank you. [IB] While we are on a BRSKI topic. So where would you see and how would you see fitting in the more details the various variations and extensions and what I would use it what profiles for the BRSKI. Which we initially targeted at the BoF which didn't materialize and now it is kind of self- organizing in the side meetings. How much of that you see as a maintenance and how much of that is rather central work which can possibly be separate. And the reason for asking that if you talk about four cycles for me this BRSKI derivative work. I really hardly see how that can fit into four cycles. That's much more than four cycles [TE] Yeah I mean that's I think one of the interesting challenges. The four cycles was just some mistake in the ground that we put in there we can remove it. So I mean I think we were just trying to show to the IESG that we're trying as good as possible to ensure that we've got more timely delivery what we were able to do in chart around one. So I think that obviously the way we would handle this is that for each individual draft that we accept we would say how long do you think it takes to get into last call and when this is more than four cycles I think. What we would do is basically ask our AD at that point in time if that's acceptable. Right? Because ultimately it's the AD who wants to see the timeliness of delivery of work from the working group. And if you right now is the AD already see that specific work items will take longer to finish then it's a value judgment that should be done anyhow. Right? The whole point was just to basically ensure that the working group without asking the AD doesn't take on things where we can't even predict how long they take. [IB] I do understand that from your side however that might be work that is both important and not necessarily directly BRSKI as such derivative. Well call it BRSKI derivative. So the question is where's the ride home is that ANIMA or is that something else and I don't expect an answer from you. This is an open question. [EL] I think the issue here that you're hitting on Ignas is meeting time like in this room and like if we if we monopolize the meeting time with BRSKI then other work doesn't get done or vice-versa if there's so much work other work that's happening then BRSKI gets starved for time in the room. That's one issue. And that can be solved I believe there're two ways you can solve that. The first is you can split off the BRSKI work into another working group. You always do that. The second is that we can use other means for communicating like having interim meetings either virtual or real. I think the hackathon work that Michael is doing is really excellent along with the guys from SIEMENS and NXP and others. I think that's all good stuff. So we can leverage all those means communication. But I think it is a cautionary point to take into account that if we do see one of the other aspects of the ANIMA work starved, then I think we do need to start thinking about splitting off. My personal expectation is a little premature to do that. But I would actually be in the hands of the chairs in terms of their view and their experience as to how this is played out. [TE] So we had a lot of ideas when we had simply two meeting slots right. And if we see that the work amount that we have and there are a lot of working groups that have a lot more during the week than just this amount of working slot so as soon as we see that we have enough work items or items we would like to discuss to add up. I think that's the most easy starting point even before going into any of the more difficult entrants. Obviously is always a good thing and that can be as much self organized as you want it to and we as working group chairs are always very happy to support it through all the things like webex passwords that we have and whatever we can help to make that happen so. ******************************************************************************* 4. Information Distribution in Autonomic Networking - 10 min 14:50 - 15:00, by Xun Xiao and Artur Hecker, draft-liu-anima-grasp-distribution [SJ] The chairs won't call for adoption for this meeting because actually there is a milestone miss it. Because that's just our proposals for the new charter. So maybe next time. I really encourage the working group participant to read this draft. It's actually the extending of the grasp verticals. So it's in the candidate charter also should be in the proposed new charter. ******************************************************************************* 5. BRSKI Relevant work Discussion - 37 min 15:00 - 15:37 5a. Bootstrapping Remote Secure Key Infrastructures (BRSKI) - 10min 14:05 - 14:15, by Michael Richardson, draft-ietf-anima-bootstrapping-keyinfra [KW] I'm sorry can you just be more clear about what is the decision. Because there's a question. You're saying things and the framings questions. (MR: yes) it's very clear what actually is... [MR] The decision is should unconstrained BRSKI. (KW: that's a question asked) What is your view? I believe that we should remove unsigned pledge requests from BRSKI. I believe that constrain BRSKI which uses constrained vouchers should always how so always have signed pledge requests as well. And I had a different view six months ago. [KW] Okay to restate that you the consents or they you're thinking is that vouchers should always be signed [MR] The voucher should always be signed. That's a good way to put it yeah. [EL] I agree however. I think over time the form of that signature may need to vary. [MR] I totally agree like we have CMS we have we could have JWT. If someone would like to have something between we can have quantum crypto alien stuff doing whatever my notes. That's okay as long as it's signed. [IB] So what's next with this document. You mentioned your issues list. Is that completed now. I've done a AD review for version 17 which is quite radically different from what it is a 19. (MR: yeah) Do you expect 20 be posted really soon and no major changes afterwards. Do you need more time what's our studies. [MR] The only issue is this one that are talking about now. It involves the leading text not adding any. And like for paragraphs or something, the diff from 17 to 19 which I also I did post that in the message. It's a not a trivial death but it's actually I thought it actually looked quite well it actually I found it went quite well to me to say yes. There's not actually that many changes the text that has changed is mostly in response to clarifications that people have asked for. No changes on the wire from these changes. The exception that we remove unsigned pledge requests. So from that point of view anything or any thoughts I don't have or any code that anyone's written is unchanged. I would suggest please start to review now if the working group concludes on the mailing list. That is the good idea then we'll cross that text out and post 20 but I don't have an intention of host 20 this week or next week until someone says that we have clear consensus. [IB] Okay so another point on this, due to the amount of changes which went in since WGLC. The version which was last call's this will have to be another last call. [MR] Okay fair enough. [IB] So 20 anyway we'll have to materialize at some point of time and probably 20 can be the last call version. [MR] Okay so I would be very happy to do that if we do a two-week last call. Then and the conclusion from this is to remove it then let's remove it. And so we're gonna get the cable fixed for those who are remote. And that would be great I did do unicast the three reviewers with the updates .I'm going to pigeonhole some of them in the hallway tomorrow. And make sure that they really saw the updates and I'd like their positive acknowledgement that they're okay with it. I mean there's a lot of issues that were opened. And let's we'll working group last call it again I guess. [IB] Okay. ******************************************************************************* 5b. Constrained Voucher Artifacts for Bootstrapping Protocols -10 min 14:15 - 14:20, by Michael Richardson, draft-ietf-anima-constrained-voucher [PS] Let me worry you only a little bit more. The YANG specifications and YANG support specification and specific which we actually are using are now being discovered to discuss its core. I hope that they agree about the document such that 0 will go forward. [MR] Okay. So that's better news for that guys. So at this point we've taken some allocations they're allocated from a mega range, the idea was that I would give out to various. I gonna being a fairly expensive allocation process for implementers would give out ranges of a million numbers to other entities that would parcel them out in groups of 50. One of which was a reference mutation called commute space. And they gave us those numbers that are shown there. So we're using the numbers. we don't know how to allocate them properly. And I guess this is something you have to go back to the core working group whether they're gonna let us basically put our numbers in or they're gonna tell us, you lose your internet Draft, go back to scratch. Okay so that could screw us up at least a little bit because we'll have to fix code. ******************************************************************************* 5c. Constrained Join Proxy for Bootstrapping Protocols - 7 min by Peter van der Stok, draft-vanderstok-anima-constrained-join-proxy [TE] Just as an individual contributor, I think to review all these constrain documents. It would be good to understand what the typical type of constraint devices are that the solution is targeting. I mean that context so because it's hard to figure out the applicability without knowing what it's meant to be applied for us. And I'm not sure if any of these drafts has a specific good section about that or how would we deal with them with that type of... [PS] It actually says you look here constrained devices use (co-up??) and DTLS how can we handle that in the context of BRSKI. I think that's the layer at which the trap is. So we don't go any below say what is the 6lowpan structure of the message we do not do that how large may be made the processor be that depends on the implementations. We don't discuss there? Okay. [SJ] Answer your question. I mean there are so many work proposed irrelevant to BRSKI proposed to ANIMA working group. And we a proposed to including those works in the next charter but until you know we get that approved, still in there [PS] A lot of work. But much of the work done for the joint proxy is done in collaboration is the constraint voucher. So this actually goes together if the constraint voucher examples can be made. They can be made for the constraint proxy. So there is a lot of synergy with these those drafts. So it's not just an extra branch of work in nicely fits together. So if you if the work load is any consideration I don't think. You should bother too much business. [SJ] All right. Thank you. ******************************************************************************* 5d. BRSKI enrollment of with disconnected Registrars ¨C smarkaklink - 7 min by Michael Richardson, draft-richardson-anima-smarkaklink No comments here. ******************************************************************************* 5e. Support of asynchronous enrollment in BRSKI, - 7 min by Steffen Fries, draft-fries-brski-async-enroll No comments here. ******************************************************************************* 5f. bootstrapping Key Infrastructure over EAP, - 4 min BRSKI over IEEE 802.11, - 4 min by Eliot Lear, draft-lear-eap-teap-brski, draft-friel-anima-brski-over-802dot11 [EL] Any question? [TE] No, I think definitely I think the most important part please focus requests a lot of time for these new things. Next time around so that we really make sure that we do get either three hour or two two-hour sessions. Then we can actually spend good time on getting these enough reviewer discussion in the room. So that we can have a better adoption call because right now we hunted off any hour because we're still trying to finish up on the Charter but next time around hopefully that would be a really good time to have long discussions and we'll get more time. [EL] So just to response to that really quickly. This work was not ready for adoption. It isn't ready for adoption was shown to email as well. And some of the organizational discussion is does that belong in email does it belong in here. and that as a matter of where we need the experts to be honest. [SJ] Sure. So hopefully we will have our new charter approved before next IETF meeting then we have we're in better position to serve they in the community. So I declare to close this session and say all you guys in Montreal. ******************************************************************************* 5g: discussion & chairs wrapping-up - 8 min ******************************************************************************* 6. Scenarios and Requirements for Layer 2 Autonomic Control Planes - 10 min 15:37 - 15:47, by Bing Liu (remote), draft-carpenter-anima-l2acp-scenarios Not presented giving the limited WG time. ******************************************************************************* 7. Summary & ANIMA future activities - e min 15:47 - 15:50, by co-chairs