Re: [manet] Recharter Discussion

[Rick Taylor <[e-mail]>]

All,

There are several DLEP extension drafts already in circulation, so no
matter what happens to MANET, I would like there to be some home for
further DLEP work.  My preference would be for a MANET re-charter
including DLEP.

Cheers,

Rick


On Tue, 2016-05-03 at 20:30 -0400, Stan Ratliff wrote:
> Christopher/All,
>
> Time to pick this discussion up again. What type of buy-in do you
> think is necessary? On the one hand, you discuss a "small team of
> authors"; on the other, you mention that we're "way short of what we
> really need in terms of buy-in".
>
> There has been interest expressed in addressing the MCAST issue, and
> volunteers (specifically, Justin, and probably Brian) to submit work.
> There is also a small number of potential authors interested in a few
> (three or so) DLEP extensions. Is there any OLSRv2 work on the
> horizon? Is there a definable, manageable problem space for things
> like cryptographic key management in ad hoc networks?
>
> We need to either come to consensus on a 12-18 month charter, or be
> prepared to close the WG. What is the interest level?
>
> Regards,
> Stan
>
>
> On Wed, Apr 27, 2016 at 12:35 PM, Dearlove, Christopher (UK) <
> [e-mail]> wrote:
> > OK, you know there are some people at NRL. Good. But still quite a
> > way short of what we really need in terms of buy-in. (I’m assuming
> > the people at NRL are represented by you and/or Brian, as otherwise
> > even they aren’t showing up.)
> >
> > --
> >
> > Christopher Dearlove
> > Senior Principal Engineer
> > BAE Systems Applied Intelligence Laboratories
> > ___________________________________________________________________
> > _______
> >
> > T:  [phone]  |  E: [e-mail]
> >
> > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
> > Baddow, Chelmsford, Essex CM2 8HN.
> > www.baesystems.com/ai
> >
> > BAE Systems Applied Intelligence Limited
> > Registered in England & Wales No: 01337451
> > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
> >
> >
> > From: Justin Dean [mailto:[e-mail]]
> > Sent: 27 April 2016 16:45
> > To: Dearlove, Christopher (UK)
> > Cc: Thomas Heide Clausen; [e-mail]
> > Subject: Re: [manet] Recharter Discussion
> >
> >
> > *** WARNING ***
> > This message originates from outside our organisation, either from
> > an external partner or the internet.
> > Consider carefully whether you should click on any links, open any
> > attachments or reply.
> > For information regarding Red Flags that you can look out for in
> > emails you receive, click here.
> > If you feel the email is suspicious, please follow this process.
> >
> >
> >
> > On Wed, Apr 27, 2016 at 5:56 AM, Dearlove, Christopher (UK) <
> > [e-mail]> wrote:
> > The key points as I see it are:
> > - We shouldn’t wait for telecon, and can’t rely on telecon and cut
> > out list.
> > I agree.  We shouldn't wait for the telecon.  I'll continue to
> > engage everyone on this list about what people are willing to work
> > on.
> >
> > - We are very short of contributors. Many who have contributed have
> > dropped away. And those who have been main creators of WG RFCs
> > (looking at statistics, Clausen and Dearlove in particular, but
> > also others - but not a lot of others, especially after the first
> > batch of Experimental RFCs) may or may not be contributing.
> > We are short contributors and we may be able to get more by
> > focusing the group on specific issues and possibly creating new
> > focused groups to invite a larger/wider IETF involvement.  Security
> > being the one coming to mind.  Your mention on the list about
> > security stuff that you are interested in hasn't brought a lot of
> > discussion on this list but it very well may bring a lot of
> > interest from the larger ietf community.
> >
> > - But even more importantly we need real people (preferably
> > companies with products) using our protocols with real problems.
> > DLEP I think has some real adaptors, though I think most are
> > waiting for an RFC. OLSRv2 is short on companies advertising they
> > are using it - I wish some would (I’m told they exist, but couldn’t
> > name any). AODVv2 (which may or may not be in scope) appears not to
> > have even up to date experimental code (please correct if wrong).
> > - Hence although we may have some great ideas, it’s not yet clear
> > people want them and we can deliver - DLEP maintenance being I
> > think closest to contradicting that, at least publicly.
> > Well I KNOW that here at NRL we have the real people and prototype
> > products relating to the multicast issue that it can happen. The
> > key issue is making sure there are enough people willing to
> > contribute and engineer a solution to an issue that needs solving.
> >
> > There is the horrible warning of Autoconf that went wrong in
> > several ways, but at the end, had no one who would do the work
> > (which is a lot of work, taking longer than you expect) to create a
> > draft and take it all the way. And that means a small team of
> > actual authors, plus wider input.
> >
> > Incidentally the autoconf problem is still real, but was too
> > narrow. That was considering address autoconfiguration (though the
> > WG never actually got there). As I see it, there’s an inseparable
> > (in terms of thinking about it, drafts may of course separate out
> > details) issue that is of address assignment, identity
> > assignment/management, cryptographic key management, and other
> > forms of management (network management). And several chicken and
> > egg problems that arise in them, especially in ad hoc networks.
> > I think the issue with autoconf is that it was attempting to solve
> > to broad a problem.  There were demonstratable solutions to very
> > specific problems (e.g. multihop DHCP) but then there were more
> > exotic solutions to more complex problems like DAD in disconnected
> > partitioning/merging networks. If we can focus on a specific well
> > defined problem space I think we'll be fine.
> >
> > --
> >
> > Christopher Dearlove
> > Senior Principal Engineer
> > BAE Systems Applied Intelligence Laboratories
> > ___________________________________________________________________
> > _______
> >
> > T:  [phone]  |  E: [e-mail]
> >
> > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
> > Baddow, Chelmsford, Essex CM2 8HN.
> > www.baesystems.com/ai
> >
> > BAE Systems Applied Intelligence Limited
> > Registered in England & Wales No: 01337451
> > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
> >
> >
> > From: manet [mailto:[e-mail]] On Behalf Of Thomas
> > Heide Clausen
> > Sent: 26 April 2016 22:01
> > To: Justin Dean
> > Cc: [e-mail]
> > Subject: Re: [manet] Recharter Discussion
> >
> >
> > *** WARNING ***
> > This message originates from outside our organisation, either from
> > an external partner or the internet.
> > Consider carefully whether you should click on any links, open any
> > attachments or reply.
> > For information regarding Red Flags that you can look out for in
> > emails you receive, click here.
> > If you feel the email is suspicious, please follow this process.
> >
> > *** WARNING ***
> > EXTERNAL EMAIL -- This message originates from outside our
> > organization.
> >
> >
> >
> >
> > On 26 avr. 2016, at 22:21, Justin Dean <[e-mail]>
> > wrote:
> >
> > Thomas I understand your concerns but we have mostly gone over this
> > before in previous meetings.
> >
> > The IETF conducts is business on mailing lists.
> >
> > My recollection is that the strawman charter was presented once in
> > a WG meeting, then the chairs did not animate any charter
> > discussion for several IETFs, on the list (nor was the charter
> > discussed in subsequent meetings) - until this present "urgency"
> > was declared (by the chairs) to the WG.
> >
> >
> > The AD will not allow us to meet at the next IETF meeting if we do
> > not have a new charter and new work items.
> >
> > That does not negate my point, however, which was that:
> >
> > it should be established on the list that there are meaningful
> > things to do, and there's a meaningful critical mass of people to
> > be doing those things, before a (virtual) interim is called.
> > Brainstorming on a teleconference is rarely a constructive way to
> > spend time
> >
> >
> > Thomas
> >
> >
> > To your point it's imparative that the discussion continues on list
> > about the charter.  With that in mind here is a suggested edit of
> > the previously floated charter, with comments in () with JWD tags.
> >
> >
> > The purpose of the MANET working group is to standardize IP routing
> > protocol functionality suitable for wireless routing application
> > within both static and dynamic topologies with increased dynamics
> > due to node motion or other factors.
> >
> > Approaches are intended to be relatively lightweight in nature,
> > suitable for multiple hardware and wireless environments, and
> > address scenarios where MANETs are deployed at the edges of an IP
> > infrastructure. Hybrid mesh infrastructures (e.g., a mixture of
> > fixed and mobile routers) should also be supported by MANET
> > specifications and management features.
> >
> > The MANET WG is responsible for the maintenance of OLSRv2, AODVv2
> > (JWD TBD), DLEP and NHPD. Of particular interest: security
> > enhancements, and encryption security extensions for RFC5444. (JWD
> > we may want to break this out of the WG and make a new MANET Sec
> > working group to grab the attention of those interested in security
> > and get their participation.)
> >
> > The MANET WG will standardize a multicast MANET protocol framework
> > based on previous work and lessons learned for scoped forwarding
> > within MANET networks.  As part of this framework the WG will
> > produce a well defined MANET multicast forwarding information base.
> >
> > The WG will produce an informational draft outlining challenges and
> > best practices for deploying and managing MANET networks.
> >
> > The MANET WG will interact with the PIM working group on issues
> > relating to the multicast work.  The WG will also pay attention to
> > other IETF and IRTF work that is addressing topics related to MANET
> > environments.
> >
> > In summary, the WG will develop the following drafts:
> >
> > MANET Management Document (Informational)
> > MANET Maintenance
> >  - RFC5444 Security extension (Standards) (JWD possibly move this
> > to new working group)
> > MANET Multicast
> >  - Multicast FIB (Standards)
> >
> >
> >
> > On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen <
> > [e-mail]> wrote:
> > Hi,
> >
> > I believe that an virtual interim is premature: a teleconference
> > is, mechanically, less inclusive than are mailing list discussions
> > (time-zones, other commitments, requirement of synchronicity of
> > participation, etc.).
> >
> > Furthermore....
> >
> > Until such time that a strawman charter is proposed, updated to
> > reflect the reality of the group as stipulated by the AD and by Mr.
> > Dean, as well as additional charter items emerging on the list,
> >  and with relatively broad and deep support for the included items
> > by the working group, having an interim - virtual or otherwise - is
> > not constructive.
> >
> > In other words, it should be established on the list that there are
> > meaningful things to do, and there's a meaningful critical mass of
> > people to be doing those things, before a (virtual) interim is
> > called. Brainstorming on a teleconference is rarely a constructive
> > way to spend time.
> >
> >
> > Best,
> >
> >
> > Thomas
> >
> > Sent from my iPad
> >
> > On 22 Apr 2016, at 17:50, Stan Ratliff <[e-mail]>
> > wrote:
> >
> > Hello WG,
> >
> > Do we need to hold an interim meeting (via WebEX) to discuss? I'd
> > like to get opinions on the list about that. We'll need a couple of
> > weeks to schedule, but we can do that.
> >
> > One other point inline:
> >
> > On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christopher (UK) <
> > [e-mail]> wrote:
> > Multicast is the obvious top item. Lots of possible approaches,
> > time to discuss.
> >
> > Gateways for AODVv2 at Standard is obviously not possible since
> > AODVv2 is going to be Experimental at most.
> >
> > Management we did of course have an NHDP/OLSRv2 draft killed by AD.
> > Which since NHDP/OLSRv2 us all we have (SMF excepted) that was a
> > bit tricky.
> >
> > I would have to make an IPR declaration to say some of what I might
> > have to say about encryption. Not today.
> >
> > Understood. But please remember - there's only about a 5-week gap
> > now before the charter needs to be complete in order for the WG to
> > meet in Berlin.
> >
> > Regards,
> > Stan
> >
> >
> >
> >
> > Missing from the list is any work on OLSRv2 (or NHDP). MT-OLSRv2 is
> > experimental. That would need implementation tests to advance to
> > PS. Anyone interested in that (I’m not saying I can)?
> >
> > More broadly on OLSRv2 there are various things that could be done,
> > but what is really needed is people with a real application. Any
> > that exist were frightened away from this group.
> >
> > --
> >
> > Christopher Dearlove
> > Senior Principal Engineer
> > BAE Systems Applied Intelligence Laboratories
> > ___________________________________________________________________
> > _______
> >
> > T:  [phone]  |  E: [e-mail]
> >
> > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great
> > Baddow, Chelmsford, Essex CM2 8HN.
> > www.baesystems.com/ai
> >
> > BAE Systems Applied Intelligence Limited
> > Registered in England & Wales No: 01337451
> > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
> >
> >
> > From: manet [mailto:[e-mail]] On Behalf Of Justin
> > Dean
> > Sent: 22 April 2016 16:07
> > To: [e-mail]
> > Subject: [manet] Recharter Discussion
> >
> >
> > *** WARNING ***
> > This message originates from outside our organisation, either from
> > an external partner or the internet.
> > Consider carefully whether you should click on any links, open any
> > attachments or reply.
> > For information regarding Red Flags that you can look out for in
> > emails you receive, click here.
> > If you feel the email is suspicious, please follow this process.
> >
> > *** WARNING ***
> > EXTERNAL EMAIL -- This message originates from outside our
> > organization.
> >
> > I'll start things off by floating the draft re-charter which was
> > presented in Prague.
> >
> > The purpose of the MANET working group is to standardize IP routing
> > protocol functionality suitable for wireless routing application
> > within both static and dynamic topologies with increased dynamics
> > due to node motion or other factors.
> >
> > Approaches are intended to be relatively lightweight in nature,
> > suitable for multiple hardware and wireless environments, and
> > address scenarios where MANETs are deployed at the edges of an IP
> > infrastructure. Hybrid mesh infrastructures (e.g., a mixture of
> > fixed and mobile routers) should also be supported by MANET
> > specifications and management features.
> >
> > The MANET WG is responsible for the maintenance of OLSRv2, AODVv2,
> > DLEP and NHPD. Of particular interest: border behavior between
> > MANET networks and fixed IP network infrastructures, enhance AODVv2
> > gateway functionality; security enhancements, encryption security
> > extensions for RFC5444.
> >
> > The MANET WG will standardize a multicast MANET protocol framework
> > based on previous work and lessons learned for scoped forwarding
> > within MANET networks.  As part of this framework the WG will
> > produce a well defined MANET multicast forwarding information base.
> >
> > The WG will produce an informational draft outlining challenges and
> > best practices for deploying and managing MANET networks.
> >
> > The MANET WG will interact with the PIM working group on issues
> > relating to the multicast work.  The WG will also pay attention to
> > other IETF and IRTF work that is addressing topics related to MANET
> > environments.
> >
> > In summary, the WG will develop the following drafts:
> >
> > MANET Management Document (Informational)
> > MANET Maintenance
> >  - RFC5444 Security extension (Standards)
> >  - Enhanced AODVv2 gateway extension (Standards)
> > MANET Multicast
> >  - Multicast FIB (Standards)
> >
> >
> > This will likely be considered too broad to pass.  We will likely
> > need to cut some and focus the work.  For me personally I know I
> > have the time and backing to work on the Multicast piece.
> >
> > Justin
> > *******************************************************************
> > *
> > This email and any attachments are confidential to the intended
> > recipient and may also be privileged. If you are not the intended
> > recipient please delete it from your system and notify the sender.
> > You should not copy it or use it for any purpose nor disclose or
> > distribute its contents to any other person.
> > *******************************************************************
> > *
> >
> > _______________________________________________
> > manet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/manet
> >
> >
> > _______________________________________________
> > manet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/manet
> >
> > _______________________________________________
> > manet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/manet
> >
> >
> >
> >
> > _______________________________________________
> > manet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/manet
> >
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet