Subject: Re: [manet] Recharter Discussion

From: Stan Ratliff <[email-masked]>
Date: Tue, 3 May 2016 20:30:12 -0400

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) <
[email-masked]> 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*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> 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:[email-masked]]
> *Sent:* 27 April 2016 16:45
> *To:* Dearlove, Christopher (UK)
> *Cc:* Thomas Heide Clausen; [email-masked]
> *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
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> * If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
>
>
>
>
> On Wed, Apr 27, 2016 at 5:56 AM, Dearlove, Christopher (UK) <
> [email-masked]> 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*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> 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:[email-masked]] *On Behalf Of *Thomas Heide
> Clausen
> *Sent:* 26 April 2016 22:01
> *To:* Justin Dean
> *Cc:* [email-masked]
> *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
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> * If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
> **** **WARNING ******
> EXTERNAL EMAIL -- This message originates from outside our organization.
>
>
>
>
>
>
> On 26 avr. 2016, at 22:21, Justin Dean <[email-masked]> 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 <[email-masked]>
> 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 <[email-masked]> 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) <
> [email-masked]> 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*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> 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:[email-masked]] *On Behalf Of *Justin Dean
> *Sent:* 22 April 2016 16:07
> *To:* [email-masked]
> *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
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> * If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
> **** **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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: Rick Taylor <[email-masked]>
Date: Wed, 4 May 2016 10:23:11 +0000

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".
>
> 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?
>
> > 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:  +44 (0)1245 242194  |  E: [email-masked]
> >
> > From: Justin Dean [mailto:[email-masked]]
> > Sent: 27 April 2016 16:45
> > To: Dearlove, Christopher (UK)
> > Cc: Thomas Heide Clausen; [email-masked]
> > 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.
> >
> >
> >
> > - 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.
> >
> > 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.
> > 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
> > 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:  +44 (0)1245 242194  |  E: [email-masked]
> >
> > From: manet [mailto:[email-masked]] On Behalf Of Thomas
> > Heide Clausen
> > Sent: 26 April 2016 22:01
> > To: Justin Dean
> > Cc: [email-masked]
> > 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 ***
> > Thomas I understand your concerns but we have mostly gone over this
> > before in previous meetings.
> >
> > 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.
> >
> > 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.
> >
> > On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen <
> > [email-masked]> 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
> >
> > 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:
> >
> > 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
> >
> >
> >
> >
> > 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:  +44 (0)1245 242194  |  E: [email-masked]
> >
> > From: manet [mailto:[email-masked]] On Behalf Of Justin
> > Dean
> > Sent: 22 April 2016 16:07
> > To: [email-masked]
> > 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 ***
> > 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.
> >
> > 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

---

From: James Nguyen <[email-masked]>
Date: Wed, 4 May 2016 10:43:48 -0400

On Fri, Apr 22, 2016 at 11:07 AM, Justin Dean <[email-masked]> wrote:

> > + 1

I'm interested in "border behavior between MANET networks and fixed IP
network infrastructures."  Is there any existing work on this?

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.
> > +1

> >  I'm still unclear what would be the in the document.  As of now, there
isn't a clear management solution for MANET (eg.g, cloud computing, SDN).
As for management protocols, RESTCONF will soon be standardized, but
transport needs to be addressed for MANET.  CoMI seems to be a good fit for
MANET, but it'll be far from being matured.  Anyhow, if we work and publish
this document, it'll be out of date in a year or two.  I can volunteer to
work on this, but I need some guidance.

On a separate note, for all future protocols, will we continue to develop
MIB or YANG?

-- 
James Nguyen
Email: [email-masked]

---

From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" <[email-masked]>
Date: Wed, 4 May 2016 15:09:18 +0000

Folks:

I am also interested in the broader framework of MANETs. The framework should include as follows:

1. The fundamental network topology architecture of MANETs is peer-to-peer (P2P) by definition as all nodes move from one place to another with mobility patterns that are termed as "ad hoc" movements where each node independently with no fixed infrastructures, and they use the IP MANET physical routing protocols t(e.g. AODVv2) hat include broadcast and multicast.

2. The large-scale MANETs topology architecture will be hierarchical al least of two tiers: Access MANETs and a Backbone MANET that connects all access MANETs. Each access MANET may use IP MANET physical routing protocol (e.g. AODVv2). However, the Backbone MANET may use "logical" routing protocol (such as, Key-based Distributed Hash Table [DHT]) that may use unicast among the backbone node peers (may cluster head). It implies that we need to develop (or choose or modified from the existing DHT) the Key-based DHT "logical" routing protocol with unicast that is suitable for the Backbone MANET.

3. It implies that there will two kinds of routing protocol: Access MANET Physical Routing Protocol (e.g. AODVv2) and Backbone MANET Logical Unicast Routing Protocol (e.g. DHT-based routing schemes).

Comments will be appreciated on the above topic.

Best regards,
Radhika 

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of James Nguyen
Sent: Wednesday, May 04, 2016 10:44 AM
To: Justin Dean <[email-masked]>
Cc: [email-masked]
Subject: [Non-DoD Source] Re: [manet] Recharter Discussion

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser. 

________________________________

On Fri, Apr 22, 2016 at 11:07 AM, Justin Dean <[email-masked] < Caution-mailto:[email-masked] > > wrote:

	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. 

I'm interested in "border behavior between MANET networks and fixed IP network infrastructures."  Is there any existing work on this?  

	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)

>  I'm still unclear what would be the in the document.  As of now, there isn't a clear management solution for MANET (eg.g, cloud computing, SDN).  As for management protocols, RESTCONF will soon be standardized, but transport needs to be addressed for MANET.  CoMI seems to be a good fit for MANET, but it'll be far from being matured.  Anyhow, if we work and publish this document, it'll be out of date in a year or two.  I can volunteer to work on this, but I need some guidance.  

On a separate note, for all future protocols, will we continue to develop MIB or YANG?  

	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

	_______________________________________________
	manet mailing list
	[email-masked] < Caution-mailto:[email-masked] > 
	Caution-https://www.ietf.org/mailman/listinfo/manet < Caution-https://www.ietf.org/mailman/listinfo/manet > 

-- 

James Nguyen
Email: [email-masked] < Caution-mailto:[email-masked] >

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Wed, 4 May 2016 15:22:25 +0000

Radhika,

To me, depending on how one looks at this, it boarders on either a
research item or a deployment item (addressing schemes that work between
ad-hoc and backbone, etcŠ).

Can you better define what you would like out of the engineer group?  Do
we need a protocol that operates between the tiers?

Will

On 5/4/16, 11:09 AM, "manet on behalf of Roy, Radhika R CIV USARMY RDECOM
CERDEC (US)" <[email-masked] on behalf of
[email-masked]> wrote:

>1. The fundamental network topology architecture of MANETs is
>peer-to-peer (P2P) by definition as all nodes move from one place to
>another with mobility patterns that are termed as "ad hoc" movements
>where each node independently with no fixed infrastructures, and they use
>the IP MANET physical routing protocols t(e.g. AODVv2) hat include
>broadcast and multicast.
>
>2. The large-scale MANETs topology architecture will be hierarchical al
>least of two tiers: Access MANETs and a Backbone MANET that connects all
>access MANETs. Each access MANET may use IP MANET physical routing
>protocol (e.g. AODVv2). However, the Backbone MANET may use "logical"
>routing protocol (such as, Key-based Distributed Hash Table [DHT]) that
>may use unicast among the backbone node peers (may cluster head). It
>implies that we need to develop (or choose or modified from the existing
>DHT) the Key-based DHT "logical" routing protocol with unicast that is
>suitable for the Backbone MANET.
>
>3. It implies that there will two kinds of routing protocol: Access MANET
>Physical Routing Protocol (e.g. AODVv2) and Backbone MANET Logical
>Unicast Routing Protocol (e.g. DHT-based routing schemes).
>
>All active links contained in this email were disabled. Please verify the
>identity of the sender, and confirm the authenticity of all links
>contained within the message prior to copying and pasting the address to
>a Web browser. 
>
>
>On Fri, Apr 22, 2016 at 11:07 AM, Justin Dean <[email-masked] <
>Caution-mailto:[email-masked] > > wrote:
>
>
>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.
>
>> + 1
>	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.
>
>> +1  
>
>
>	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)
>
>>isn't a clear management solution for MANET (eg.g, cloud computing,
>>SDN).  As for management protocols, RESTCONF will soon be standardized,
>>but transport needs to be addressed for MANET.  CoMI seems to be a good
>>fit for MANET, but it'll be far from being matured.  Anyhow, if we work
>>and publish this document, it'll be out of date in a year or two.  I can
>>volunteer to work on this, but I need some guidance.
>
>
>	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
>
>	Caution-https://www.ietf.org/mailman/listinfo/manet <
>Caution-https://www.ietf.org/mailman/listinfo/manet >
>	
>	
>
>
>
>
>-- 
>
>James Nguyen
>Email: [email-masked] <
>Caution-mailto:[email-masked] >

---

From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" <[email-masked]>
Date: Wed, 4 May 2016 15:31:30 +0000

Hi, Will:

Please inline [RRR].

BR/Radhika

-----Original Message-----
From: Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]] 
Sent: Wednesday, May 04, 2016 11:22 AM
To: Roy, Radhika R CIV USARMY RDECOM CERDEC (US) <[email-masked]>; James Nguyen <[email-masked]>; Justin Dean <[email-masked]>
Cc: [email-masked]
Subject: Re: [manet] [Non-DoD Source] Re: Recharter Discussion

Radhika,

[RRR] Yes. A unicast protocol between the independent peers that form the hierarchical tiers (in this case, say 2-tier network: access and Backbone - the peering nodes that form the backbone may be cluster heads). That is , we need a routing protocol among backbone nodes using unicast.

Will

---

From: "Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" <[email-masked]>
Date: Wed, 4 May 2016 15:37:52 +0000

Hi, Will:

For further help, I am providing a reference paper to understand what I am trying to say for standardization in this MANET WG:

Shahbaz Akhtar Abid, Mazliza Othman, and Nadir Shah. 2014. A survey on DHT-based routing for largescale
mobile ad hoc networks. ACM Comput. Surv. 47, 2, Article 20 (August 2014), 46 pages.
DOI: http://dx.doi.org/10.1145/2632296

If you google it, you can retrieve the paper.

BR/Radhika

-----Original Message-----
From: Roy, Radhika R CIV USARMY RDECOM CERDEC (US) 
Sent: Wednesday, May 04, 2016 11:31 AM
To: 'Ivancic, William D. (GRC-LCA0)' <[email-masked]>
Cc: [email-masked]
Subject: RE: [manet] [Non-DoD Source] Re: Recharter Discussion

Hi, Will:

Please inline [RRR].

BR/Radhika

-----Original Message-----
From: Ivancic, William D. (GRC-LCA0) [mailto:[email-masked]]
Sent: Wednesday, May 04, 2016 11:22 AM
To: Roy, Radhika R CIV USARMY RDECOM CERDEC (US) <[email-masked]>; James Nguyen <[email-masked]>; Justin Dean <[email-masked]>
Cc: [email-masked]
Subject: Re: [manet] [Non-DoD Source] Re: Recharter Discussion

Radhika,

To me, depending on how one looks at this, it boarders on either a research item or a deployment item (addressing schemes that work between ad-hoc and backbone, etcŠ).

Can you better define what you would like out of the engineer group?  Do we need a protocol that operates between the tiers?

Will

On 5/4/16, 11:09 AM, "manet on behalf of Roy, Radhika R CIV USARMY RDECOM CERDEC (US)" <[email-masked] on behalf of [email-masked]> wrote:

>where each node independently with no fixed infrastructures, and they 
>use the IP MANET physical routing protocols t(e.g. AODVv2) hat include 
>broadcast and multicast.
>
>least of two tiers: Access MANETs and a Backbone MANET that connects 
>all access MANETs. Each access MANET may use IP MANET physical routing 
>3. It implies that there will two kinds of routing protocol: Access 
>MANET Physical Routing Protocol (e.g. AODVv2) and Backbone MANET 
>Logical Unicast Routing Protocol (e.g. DHT-based routing schemes).
>
>All active links contained in this email were disabled. Please verify 
>the identity of the sender, and confirm the authenticity of all links 
>contained within the message prior to copying and pasting the address 
>to a Web browser.
>
>
>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.
>
>> +1
>
>

---

From: Jiazi YI <[email-masked]>
Date: Mon, 9 May 2016 13:26:48 +0200

Hi,

On Wed, May 4, 2016 at 2:30 AM, Stan Ratliff <[email-masked]> wrote:

> so) DLEP extensions. Is there any OLSRv2 work on the horizon?
>

Personally, I have interests in OLSRv2 source-destination routing, and
possible extensions to make OLSRv2 more scalable (fish-eye? or even
hierarchical)?
The multipath extension is for experimental track -- hopefully it can be
last called soon. If there are interests on it, we can think about the
possibility of pushing it towards standard track after the experimental RFC
is published.

I will try to participate the interim meeting, but not sure yet.

cheers

Jiazi

> Is there a definable, manageable problem space for things like
> cryptographic key management in ad hoc networks?
>
>> - 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
>> 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.
>>
>>
>>
>> *From:* manet [mailto:[email-masked]] *On Behalf Of *Thomas
>> Heide Clausen
>> 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

---

From: Henning Rogge <[email-masked]>
Date: Mon, 9 May 2016 14:05:01 +0200

On Mon, May 9, 2016 at 1:26 PM, Jiazi YI <[email-masked]> wrote:
> Hi,
> Personally, I have interests in OLSRv2 source-destination routing,

I have a working implementation for this so I would also be interested.

> and

Fisheye is a crude hack, but sometimes necessary unless we think about
something better.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 9 May 2016 13:10:37 +0100

Fish-eye is already supported in OLSRv2. We wrote 5497 to add the final needed detail. However we didn't really call it out (or some other similarly supported features) in 7181. We have various bits of unpublished material describing this. I might have mentioned it in my one published paper on OLSRv2 (it's in a NATO conference). Or might not, I don't have access this minute.

Hierarchical on the other hand is a different question. There were some Canadians who looked at this, but it was some time ago. I think you'd want to start from a clean sheet to design though.

-- 
Christopher Dearlove

> On 9 May 2016, at 12:26, Jiazi YI <[email-masked]> wrote:
> 
> Hi, 
> 
>> 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?
> 
> Personally, I have interests in OLSRv2 source-destination routing, and possible extensions to make OLSRv2 more scalable (fish-eye? or even hierarchical)? 
> The multipath extension is for experimental track -- hopefully it can be last called soon. If there are interests on it, we can think about the possibility of pushing it towards standard track after the experimental RFC is published. 
> 
>> 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) <[email-masked]> 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
>>> __________________________________________________________________________
>>> 
>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>>> www.baesystems.com/ai
>>> 
>>> 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.
>>> On Wed, Apr 27, 2016 at 5:56 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
>>> 
>>> - 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
>>> __________________________________________________________________________
>>> 
>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>>> www.baesystems.com/ai
>>> 
>>> From: manet [mailto:[email-masked]] On Behalf Of Thomas Heide Clausen
>>> 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.
>>> Thomas I understand your concerns but we have mostly gone over this before in previous meetings.
>>> 
>>>  
>>> 
>>> 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. 
>>> 
>>>  
>>> 
>>> 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.
>>> 
>>> 
>>> On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen <[email-masked]> 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
>>> 
>>>  
>>> 
>>> 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) <[email-masked]> 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
>>> __________________________________________________________________________
>>> 
>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>>> www.baesystems.com/ai
>>> 
>>> From: manet [mailto:[email-masked]] On Behalf Of Justin Dean
>>> 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.