Minutes IETF104: anima

Meeting Minutes Autonomic Networking Integrated Model and Approach (anima) WG
Title Minutes IETF104: anima
State Active
Other versions plain text
Last updated 2019-04-09

Meeting Minutes

   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

[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

[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

[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?

[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

[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