* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Anima Status Pages

Autonomic Networking Integrated Model and Approach (Active WG)
Ops Area: Ignas Bagdonas, Warren Kumari | 2014-Nov-03 —  
Chairs
 
 


IETF-104 anima minutes

Session 2019-03-26 1350-1550: Karlin 1/2 - Audio stream - anima chatroom

Minutes

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



Generated from PyHt script /wg/anima/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -