Justin Dean notes
Stan Ratlif: The LID DLEP extension has been in request for publish state for 80 days
Rick Taylor: Log jam of lid extension please unjam document chairs/area director
Alvero Retana : It's just a bunch of documents in the queue ahead of it and it's nothing about the document itself at this time.
Rick Taylor: Okay we have working code and just would like the documetns moved forward.
Stan Ratlif: There are 4 active working group documents that Lou is going to talk about.

Lou Berger (Presenting): DLEP Extensions.
Lou Berger: here are the DLEP extensions that are working group documents.  Working with David Wiggins and Bonan Chang.  We just talked about the latency extension...I'm sorry we didn't talk about. We issued a last call there wasn't any comment on list.  Latency is ready to be pub requested.
Justin Dean (chair): Agree this document is ready for pub request it's really simple and shouldn't be an issue.  Any comment in the room?
None
Lou Berger presenting slides:  I'm going to talk about a set of 3 documents that are all related to credit based flow control.  These documents have a bit of history.  It started with a document that Stan had written, DLEP flow control; and along the way there was some decisions to split the doucment apart.  That's why we have a 00 that we think is ready for last call.  We have taken the last open issue in 03 of the previous document.  Documents have been split apart to reflect specific extension functions.  We think these three documents are ready for last call.  We also have another draft ethernet-credit that we would like to be adopted into the working group.  We think it may be ready to rapidly move though the working group although most authors think that about thier documents. 
Rick Taylor: I fully support addoption of the ethernet credit extension into the working group. 
Rick Taylor: the reason we were spliting it out was that DLEP extensions exsited in their own ethernet and dscp were split was so that they each extension had it's own draft? 
Lou Berger: I think you're presenting my slides for me.  Credit control is an important thing on its own as is traffic classification and we may want to do traffic classification without credit control and vice versa and we should be able to specify that.  We can refercne the RFC that just references just credit control.  If the WG would like to have them together we can do that but we also buy into the rational for splitting them appart.
Rick Taylor: I was the guy who asked to split the doucments simply because I want to do metrics per flow hence I want to refer to the document about flows without having to refere to credit windowing.
Lou Berger: I think you're getting to the bottom of my slides.  Here we have ethernet credit windowing vs IP credit in seperate documents so you can be clear on what you are specifying.  Thats both from a vender standpoint and user standpoint.  If you don't do this you can have a radio/modem and a router that says it's conformant and one does ethernet and one does IP and guess what it doesn't work together.  These are basicly the same doucment but they sepcify differnt code points.  The key point that extension drafts do is that they ask IANA for assignments.

Lou Berger: What's next? We think the first 3 are ready for last call.  The ethernet-credit is very simple, as Rick said difserv aware but with ethernet ieee802 headers.  On that last document we would like the working group to adopt it and last call it although it would have been outragous to put that on a slide.  For current documents they have been basicly stable with improvements in cleaning up the document but functionally they are the same.  
Stan Ratliff: I think we should put the 3 documents into last call and put adoption of the ether-credit-extension onto the mailing list.  Because of that I don't think think we can bundle them all together because of that extra step.
Alvero Retana: I don't really want to add more docuemtns to my queue, as you've already pointed out in your first slide I'm already late.   It's up to the chairs descression to issue a last call or not.  In other words that ethernet draft is pretty similar to the other ones and there is no contention you can adopt and issue last call.
Stan Ratliff: We could have some very slim chance that someone has some issue that comes out of the left field with some issue we had not seen coming.
Rick Taylor: It' would be good to have a pause between addoption and last call to allow for ipr declerations.
Lou Berger: there are none from the authors whatsoever.
Rick Taylor: Same for me.  Just a small pause.
Lou Berger: I'm a firm beliver in offical IPR decleration periods.  Just a question does anyone have any objections or comments about any of these documents?
(there were none)
Lou Berger: I'd like to point out that my co-authors have some open source DLEP code published. They have made an update, I meant to check before I got up here that it got pushed....the hope was that update would be availble in the repo and that change was to put in sub-data items. And the putting in subdata items ended up being a little bit more complimented than anticipated. It's my opinion, not that of the person doing the coding, that's David, that was because the code was originally written without this in mind and had to be refactored.  We did talk about a simplification that would have made his code more easy to impliment but we both agreed that it wouldn't be the right format for the standard.  It actually is an unnessary restriction that would limit how we use future extenions and that was is in the documents is better even though it made his implimentation work a little bit harder. In the end it's done and people can get the code.
Justin Dean: I have a question to the working group and the IETF in general about documents do we want to continue proceding with having one extension per document, or is there a way that the the IETF uses to specify multiple extensions so that you can say RFCXXX.2 or some subset of that document.
Stan Ratliff: There was a smart man who had explained if you put mulitple extensions into one document you then let implimenters pick and choose feature you want to impliment and then claim conformance.  So my vote would be no on that approach for exactly the reason that Lou comment on on multiple occasions. 1 to 1 so that if you say I support RFCxxx you support all the functionally in that document. 
Justin Dean:  I agree with that but if you say you support RFCX you support everything in that RFC.
Lou Berger: I think that options lead to interoperability issues. So, I'm from a physisophical standpoint I want to eliminate or minimize options in a document.
Justin Dean: Like I said this is more a question of how the IETF wants to function.  You know is it a problem having 100 DLEP drafts/extenions as RFCs?
Alvero Retena: Routing Ad. It's up to the working group to decide what to do.  For me personally because they have to come into my queue I'd prefer fewer documetns.  This isn't the only working group that has has this question.  Sure you ask if someone supports RFCX section 2 but that gets really not nice.  So if the working group wants to publish any number of extenions in differnet RFCs thats okay by me. 
Lou Berger: Alvero a question.  Does it matter if the documents come in a set or trickly out a little bit at a time.
Alvero Retena: the only issue for me is if they reference each other.
Lou Berger: the ones that have -extension being on ref wait on the other two. The second two depend on the first two.
Alvero Retena: The only thing that really matters to me are those references.
Lou Berger: I think it would be nice to have them as a set but is it required absolutly not.
Alvero Retena: You may want them to be processed together around the same time.  
Lou Berger: I think it would make the directorate review easier if they were together.
Alvero Retena: In the past I've often sent some notes letting people know which draft to read first so things can move a bit smoother.  So if you do that please provide me some guidance so that I can pass it along.
Rick Taylor: Talking about RFPs the incoming RFPs I've seen about DLEP have actually specififed extensions and not RFC numbers mostly because most of them are in drafts.  People seem to be talking about I need this extension or that extension. 
Lou Berger: So that argues for colapsing them.

(seems to be agreement that doing documents one per extension is the way to go for now but will take it to the list)

Christos Politis (Presenting) M-CML presentation
Christos Politis: You may have remembered us as we gave a presetion on similar work in 2014 called chameleon your meeting in amsterdam and one in the states as well.
Christos Politis: We tried to commercalize it and to be honest we haven't been very successful so far. We have a very big project funded by the UK governemnt to work with Malaysia to set up an emergency netowrk to provide comunication like with the tsunami here years ago.  They will have a 5g network so we will have an extension to that.
Christos Politis: Chameleon was a hybrid between proactive and reactive protocols very well defined by the IETF so I'm not going to talk about these protocols.  So we've continued work and created a update to Chameleon we are currently working on this at a protype level.  The plan is to operate a network here (Malaysia) with 4 phases of operation.  We got a lot of comments that last time we presented and took those on board to create a monitoring phase.  We have two new messages, one is the hop count request, and hop count reply. We are working with the multipath extention of OLSRv2, and the reactive side is AODVv2. This montioring phase is done within the proactive phase.  The reactive phase is triggered when depending on the current scenario and the algorithm we've designed.  The transion from proactive to reactive is the (oscillation?) phase which is the same at the prior Chameleon phase.  We've used the NS3 for simuations based on emergency cases.  The adaptive mode analysese the network state and chooses the mode of operation. 
Stan Ratliff:  From the chairs prepective my question to you is.  As one of your future directions looking to ask the working group to accept this document and take on this work?  Or is this more of an informational thing?
Christos Politis: We would like to move it through your working group. I know that takes time and takes effort obviously. Hopefully we will make this a working document.
Charlie Perkins: there is a monitoring phase is this some sort of distributed monintoring or how does that work. Where is the monitoring working is there some device in the network that is doing it or is it distributed? 
Christos Politis: Yes.  Slide number 7.  The monitoring phase is part of the adaptive module that was part of the previous draft.  The only difference is it monitors the hop count reqeust messages.  The plan here is to be distributed.  We want to use some sort of AI to train the system.  In order for us to train the system what we need to do is to have more scenarios.
Chairs: Interesting work but in the interest of time we need to take this to the list and discuss if this is work that we are intresting in working on.
Christos Politis: Just one last thing there is a bunch of working happening on the periphery of the network so MANET type work is a hot topic right now.

Ed Birrane DTN presentaiton:
Stan Ratliff: If I could ask you to keep it brief as we are running short on time.
Ed Birrane:  I'm a member of the DTN working group and one thing we have been working on in the DTN working group is what does netowrk management in a DTN network?  How do we manage a network when we have interuptions and disconnections? We cannot assume a full model of information.  The way we distilled the problem was what is the most constrationed systems we have, space management systems.  Where didn't have an idea of timely round trip time data exchange. I worked on new horizons which was out past pluto and what we did in these systems was to have an autonomy model for fault management and we know how to do it.  Pretty much all spacecraft do it in the same way there are some differences but they are by and large the same.  This is not how we manage our terestrial systems as we have open standards high connectivity and large investments into these systems.  The question then (in DTN) is there a motivating overlap between these highly customized autonomous systems and highly connected fast pull network management systems?  And we came back and said there is a use for something that lives in that overlap and that is what we are designing in DTN. We coined the term asynchronous management and open loop control where the devices have high distruption of comunication either via physical limitations or by the priority and or cost of mantaining those connections.  We decomposed the work into 3 layers.  The asynchronous management, basicly a requriements document.  Second we developed a data model we called it an application data model, primatives and how you would communicate with them.  These (the primatives defined in the chart) aren't particulary new for those used to doing management of networks but the difference is that it's not simply reporting back open loop control saying when I can't communicate with you these are the responses I want the device to take. This is the data and when to report and when not to report and this is more than 
just a table with some stasticis to report on. And last is AMP or the Asynchronous management protocol which defines how to communication the information. 
We are starting to standarize on this the AMA is out there and this is the place to start looking.  We have taken several appliations associated with DTN and thought about what it would be like to manage those protocols and applications and we put that in an open soure management using AMP.  The reason we are bringing this working to this working groups is that part of our motivaiton is sensor netowrk, space networks, and mobile networks. So we are looking for people working in those spaces to give us feedback on what it would be like and is typically currently like to manage those types of systems. and challanges when trying to manage these highly mobile netowrks.
Rick Taylor: As working group chair of DTN we are taking this around outside of DTN because we understand that we can't just come up with our own way of doing netowrk management. Please comment.

Rick Taylor presentaiton: DLEP multicast priority extension idea
Rick Taylor: This is a pre draft presention idea.  There are two reasons for DLEP.  The radio knows more about the radio link than the router so the router should go and ask the radio what's happening at the link level.  Second is if you can pre-fill your link information and your arp caches you can send around some inintial data without fewer messsages.  Fundamentally multicast procolos rely on relay points for distrubuting.  A lot of the algorhtims that select these points use 2 hop tables and messaging and varous algorithsm.  The radio system underneth has it's own topology based on this own physics. A sat network, hub and spoke, for example you want the satilite to be the relay point but an algorithm might just say hey I have the largest ID I'll be the relay point. The basic idea is to allow the modem to inform the router I'd make a good relay.  A second part of that would be to allow the router to inform the radio that I've been selected as a relay.  This is really useful for multicast this orthogoal to any of the multicast stuff in DLEP already.  How do we do this?  A new extension!  It would have two parts one would say I'm a router and the willingness to be a relay or if it's already been selected as a relay.  And the second would be the other way with the radio informing the router that "hey I don't know how you're doing your relay selection, but you'd make a really good relay canidate" or "you'd be a really BAD canidate for a relay because you have awful connectivity".  After this there could be a second draft saying this is how you'd use this with PIM for example.  Also OLSRv2 or OSPF MDR election.
Alvero Retena: PIM is currently working on ASM which means that you don't need relays anymore as the multicast is single source multicast. 
Rick Taylor: I'm not a PIM expert but there is still tree building so for a branch in your tree their effectly relaying.
Alvero Retena: So I'm a better canidate to be a forwarder for exmaple.
Rick Taylor: exactly without having to say you are the designated randevu point.  Good point about those points disapearing.
Unknown: how does this effect the layer 2 having it's own topology? 
Rick Taylor: That's exactly what it's designed for.
Unknown: No. So when you're layer two you inform the router you're a good canidate. The election happens at the network layer. The next hop is taken before the decision is made.  The conditions might be good when you informed the radio and then when it's time to forward a message the conditions might have gotten worse for example, as that's what can happen in wireless networks. 
Rick Taylor: The singnals comming through are not sets. they are not demands. they are purly information.  So the radio can say you'd make a really good relay and the router can say I'm running on 2 AA batteries and not self select. What the other layer does it entierly up to that layer, this is just providing more information to make those decisions.  So is this really 2 extenisons router-radio and radio->router. This goes back to the one document 2 extensions and or 2 docs. 
Justin Dean: OLSRv2 has a willingness value of 0-8 and in SMF their is a router priority field which these could feed right into. 
Lou Berger: In the interest of limiting scope of inforamtion instead of just providing a single number I would like to see more details from the radio, such as connectedness, and let the router decide how to use that informaiton instead of a single number that the modem is making up based information that may or may not be important to the router.
Stan Ratliff: That is what we were trying to do is to provide more information to the router so that it can better make a decision.
Lou Berger: But you have to give the modem knowledge of the selection algoirthm instead of that just provide the router information about the state and let the router use that informatin as it best can.
Rick Taylor: If I can paraphase. You're saying don't just have a boolean flag good/bad but have data items which list information about the radio.
Lou Berger: Yes and I think that this is great stuff and would like to see it done.
Chairs: out of time lets please take it to the list.