Minutes IETF104: anima
minutes-104-anima-01
| 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 |
minutes-104-anima-01
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