Subject: [manet] Stephen Farrell's Block on charter-ietf-manet-03-05: (with BLOCK)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 16 Jun 2016 05:47:21 -0700

Stephen Farrell has entered the following ballot position for
charter-ietf-manet-03-05: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-manet/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Apologies if I'm getting the wrong thing here, but what is DLEP?
I seem to recall there being something similarly named that had
potentially significant security affects, so if this is the same thing, 
then maybe the charter needs to say some more about that and 
what the WG need to do about it. (Again, sorry if I'm getting the 
wrong end of the wrong stick here but we can chat about it on 
the call;-)

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 16 Jun 2016 13:01:06 +0000

On 6/16/16, 7:47 AM, "iesg on behalf of Stephen Farrell"
<[email-masked] on behalf of [email-masked]> wrote:

Stephen:

Hi!

>--------------------------------------------------------------
>BLOCK:

https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/

I think you're thinking of the right document.  It is currently in my
publication queue, the authors are addressing my comments (some in fact
security related) -- hopefully we'll have it in a Telechat in a couple of
cycles.

We didn't explicitly put DLEP in the updated charter (just its
maintenance) because the work passed WGLC, etc., so (hopefully) the WG is
done with the base specification.  I don't have a problem if you think we
should explicitly call out DLEP as a deliverable -- I don't think we can
put more details in at this point.

Thoughts?

Thanks!

Alvaro.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Jun 2016 14:31:30 +0100

On 16/06/16 14:01, Alvaro Retana (aretana) wrote:
> I think you're thinking of the right document. 

Ah good:-)

>  It is currently in my

Was DLEP ever mentioned before in the MANET WG charter? I guess I'm
wondering if it's really MANET specific and whether, if it was more
broadly used, it'd also have potential privacy issues.

S.

---

From: Justin Dean <[email-masked]>
Date: Thu, 16 Jun 2016 13:36:09 +0000

We do have a DLEP extension listed as a deliverable. There is quite a bit
of interest and effort regarding extending it from various
person/organizations. It's a safe bet that some drafts WILL be produced.

Some history regarding DLEP (dynamic link exchange protocol). It was not
mentioned previously in the WG charter. The draft had cleared WG last call
over a year ago but after an extensive directorate review was sent back and
reworked to address those conserns. Security related issues have be raised
both in last call, and most recently in Alvaro's comments. I do believe the
remaining issues will be resolved as the working group has multiple options
ready to go, as it has been discussed at length and rough.

Justin

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 16 Jun 2016 13:51:57 +0000

On 6/16/16, 8:31 AM, "Stephen Farrell" <[email-masked]> wrote:

Hi!

>Was DLEP ever mentioned before in the MANET WG charter?

No, but AFAIK manet-type applications where the radio and the router are
not in the same box are the only ones requiring the functionality, which
is why the WG took on the work (several years ago) -- and had done other
related work before.

>I guess I'm

Note that while MANET means "mobile..", mobility is of course relative and
anyone can successfully argue that any network "moves"...  So, yes, it
could be used in other scenarios.  One of my review comments was precisely
about that: if DLEP is used outside the expected deployment scenario, what
changes?

Back to the charter...  Should we explicitly list DLEP (not just
extensions, as Justin pointed out) as one of the deliverables?

Thanks!

Alvaro.

---

From: Justin Dean <[email-masked]>
Date: Thu, 16 Jun 2016 14:01:57 +0000

If that is the only option to move it forward than I'm okay removing it. I
do like having a deadline for producing something though. Stan and others
likely has a strong opinion than myself. As long as we are charted to do
the work I'm okay.

Justin

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 16 Jun 2016 14:16:11 +0000

On 6/16/16, 9:01 AM, "Justin Dean" <[email-masked]<mailto:[email-masked]>> wrote:

Justin:

Hi!

If that is the only option to move it forward than I'm okay removing it. I do like having a deadline for producing something though. Stan and others likely has a strong opinion than myself. As long as we are charted to do the work I'm okay

My proposal to Stephen is not to take anything off, but to explicitly add DLEP (the base document) as a deliverable.

I'm on the IESG Telechat with Stephen right now...we should talk about it in a few minutes.

Alvaro.

---

From: Justin Dean <[email-masked]>
Date: Thu, 16 Jun 2016 14:29:28 +0000

Sounds good to me.

On Thu, Jun 16, 2016, 10:16 AM Alvaro Retana (aretana) <[email-masked]>
wrote:

> On 6/16/16, 9:01 AM, "Justin Dean" <[email-masked]> wrote:
>
> Justin:
>
> Hi!
>
> the work I'm okay
> My proposal to Stephen is not to take anything off, but to explicitly add
> DLEP (the base document) as a deliverable.
>
> I'm on the IESG Telechat with Stephen right now…we should talk about it in
> a few minutes.
>
> Alvaro.
>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 16 Jun 2016 07:55:33 -0700

> https://datatracker.ietf.org/doc/charter-ietf-manet/

imho dlep is about extending adjecency detection to adjacent radios
attached to a router, rather than requiring that it (the routing
function) be embedded in the radio itself. it may extend to the other
end of the radio link.  enumerating prefixes that are offlink (by which
we mean not bounded by the common broadcast domain) is really the domain
of a routing protocol running over the link e.g. olsrv2 ospf etc.

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 19 Jun 2016 17:52:14 +0200

Hi Alvaro,

I get distracted by many work items Last-calls/large-volume when they
submited without priority and specially when we work in MANET WG. Is their
priority in approving items/efforts. Management needs priority and clear
work path, specially when group of remote participants are working.

I would recommend to your management that they focus the recharter to list
item works per schedule/periority. IMHO, in MANET one important job of
AODVv2 was not completed because of past other works that were not listed
in charter and no priorities in WG efforts.

 I think that All ADs look into priorities of jobs in each WG and work in
line with Chairs, but it is not clear if we don't write it down in your
approval. I am sorry that IESG approval has no priorities or words of
instructions per recharter, but please advise if I am wrong, I just see
approvals without conditions and guidance. I think that there are many work
in MANET WG that can be accepted because the group works are about mobile
protocols, that is a problem. Mobile and dynamic does not mean having
dynamic in management of our projects. I did mention before about not to
take many work in MANET WG but the ADs/Chairs did not follow my discussion
on the discuss-list. I think in future work that ADs and chair need to
follow up seriously with items in each meeting.

I think this WG needs to get approval from IESG of some focused and
important MANET drafts, one is maintenance of OLSRv2 and other MANET
protocol. I proposed before that this WG needs a clear use case which is
focused in a draft, while the old draft of our manet-use case should be
updated as recharter. Only then we can see the priorities per items.  I
remember when the DLEP item was accepted I was wondering why me as remote
participant was not asked to accept or note.  I propose that DLEP should
not continue in MANET only if the WG completes the multicast routing issues
(so it should have less priority).

Please IESG look into priority and schedules of work items per WGs. Please
draw per recharter a clear approval with guidance and conditions, as it is
done in many other organisations. In this way we can force the WG to focus
their efforts and times. Still the IESG and IETF WGs are following authors
to focus/work, so if the participant is bussy with less periority wg-item
he/she must give more effort to most-priority and help authors in editting
that. Please this needs to change especially in our MANET which seems
dynamic in work and submission. Overall, WG participants should follow
WG-schedules and IESG-approvals per priority.

I advise that this charter needs more focused item works, clear draft (it
seems dynamic recharter with future random flow), How can we fix this
dynamic in work submission/lists/proposals without priorities or listed
items in the charter to be approved. What do you think?

Best Regards

AB

On Thu, Jun 16, 2016 at 3:51 PM, Alvaro Retana (aretana) <[email-masked]>
wrote:

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

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 20 Jun 2016 13:23:14 +0000

On 6/19/16, 11:52 AM, "Abdussalam Baryun" <[email-masked]<mailto:[email-masked]>> wrote:

AB:

Hi!  How are you?

I advise that this charter needs more focused item works, clear draft (it seems dynamic recharter with future random flow), How can we fix this dynamic in work submission/lists/proposals without priorities or listed items in the charter to be approved. What do you think?

I'm sure you've seen the current version of the proposed charter: https://datatracker.ietf.org/doc/charter-ietf-manet/

As you can see, there are specific milestones listed at the bottom, which are the focused work items the WG has agreed on.  I read the milestones as an indication of priorities - with the description in the charter of what the items are.

Do you have specific work items that you think belong on the list?  Or maybe items that you think don't belong?  Or is the milestones indication of priorities not clear enough?

Thanks!

Alvaro.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 20 Jun 2016 13:45:48 +0000

My comment is that the charter wording is the first place I've noticed that it's been "baked in" that the multicast approach is to be based on SMF. SMF is good within a MANET, except for the real problems of recognising duplicate packets which is why SMF has multiple incompatible mechanisms there. (I presume getting that down to one for each of IPv4 and IPv6 would be a requirement.)

But SMF may not help as much for groups that are inside and outside the MANET. What's the design space here?

(This also excludes ODMRP, which was in this group many years ago, dropped out, resurfaced more recently, then went away again. Is that a decision? - I'm not saying it's the wrong one, just wanting to check.)

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://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 Alvaro Retana (aretana)
Sent: 20 June 2016 14:23
To: Abdussalam Baryun
Cc: [email-masked]; [email-masked]; The IESG; Stephen Farrell
Subject: Re: [manet] Stephen Farrell's Block on charter-ietf-manet-03-05: (with BLOCK)

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

*** 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 6/19/16, 11:52 AM, "Abdussalam Baryun" <[email-masked]<mailto:[email-masked]>> wrote:

AB:

Hi!  How are you?

Thanks!

Alvaro.
********************************************************************
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.
********************************************************************

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 20 Jun 2016 14:45:33 +0000

On 6/20/16, 9:45 AM, "iesg on behalf of Dearlove, Christopher (UK)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

[Took the IESG off as there's no need for them in this discussion.]

Christopher:

Hi!

The charter text that was discussed on the list said: "The MANET WG will standardize a multicast MANET protocol framework based on previous work and lessons learned for scoped forwarding within MANET networks."

When reviewing it with the chairs, I asked: "Will SMF be used as a base ("based on previous work and lessons learned") or what?  If so, let's call it out."  That resulted in: "Standardize a multicast MANET protocol framework based on Simplified Multicast Forwarding [RFC 6621] for scoped forwarding within MANET networks."

I think a charter should be as specific and focused as possible, which is why I asked the question.  However, it is just a starting point - if, as you point out, there are issues that the WG should consider and decides that SMF is not the way to go then that will be the consensus and the way forward.  Even if specific, the charter is not meant to solve the work items for the WG.  In other words, I don't think that calling out a starting point should preclude the WG from deciding to use a different base.

Having said that, if you have better wording that is not as vague as "based on previous work and lessons learned", and doesn't require the listing of every possible starting point (I'm sure there may be others besides ODMRP), please suggest it.  We still have to time to play with words.

The question about the design space is again one that the WG will have to resolve.  One of the potential outcomes (obviously!) is to treat inside and outside as separate problems (just an observation as a WG participant) -- the latest version [1] (resulting from the BLOCK) includes a little text about the manet WG interacting with others on potentially common issues, in this case the pim WG.  That doesn't mean that you must agree with the pim WG on every step, but that they are a resource that could be used because they too have done previous work on multicast and have learned from it.

Thanks!

Alvaro.

[1] https://datatracker.ietf.org/doc/charter-ietf-manet/

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 20 Jun 2016 14:51:33 +0000

(Yes, I should have removed the IESG. Apologies for that - though they won't see the apology.)

I think I might use different words than "based on". I appreciate we don't want to ignore SMF, and if we can manage a good uniqueness test I think it's a good solution for its part of the problem. But because of the "if" and "part" I'd use perhaps "starting from".

But it is the position rather than the words that really matter, and you've summarised the position.

From: Alvaro Retana (aretana) [mailto:[email-masked]]
Sent: 20 June 2016 15:46
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]
Subject: Re: [manet] Stephen Farrell's Block on charter-ietf-manet-03-05: (with BLOCK)

*** WARNING ***

Christopher:

Hi!

Thanks!

Alvaro.

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 20 Jun 2016 19:53:32 +0300

Hi Alvaro,

I am ok, unfortunately I cannot attend this meeting because I am fasting
Ramadan, but hope to join in other opportunities.

On Mon, Jun 20, 2016 at 4:23 PM, Alvaro Retana (aretana) <[email-masked]>
wrote:

> On 6/19/16, 11:52 AM, "Abdussalam Baryun" <[email-masked]>
> wrote:
>
> AB:
>
> Hi!  How are you?
>
> I'm sure you've seen the current version of the proposed charter:

yes

>
> As you can see, there are specific milestones listed at the bottom, which
> are the focused work items the WG has agreed on.  I read the milestones as
> an indication of priorities — with the description in the charter of what
> the items are.
>

Milestones in my opinion are not priority indications, because in project
management work-items mostly work in parallel, so milestones do not show
priority, and in the past practice of MANET WG there are many later
milestones that were advanced old milestones. I suggest that IETF and IESG
change plans for approvals to add priority especial for groups like MANET
WG.

>
> Do you have specific work items that you think belong on the list?  Or
> maybe items that you think don't belong?  Or is the milestones indication
> of priorities not clear enough?
>

Yes, we worked MANET unicast manet routing; reactive and proactive,
experimentals and standards but submitted successfully only the proactive
as standard, so we need to work multicast manet routing now. So we need
multicast reactive and multicast proactive routing, usually multicast
routing is the most important routing in MANET environment. However, it was
a great plan that MANET WG started in the past with unicast and now the new
issue is multicast routing. We need multicast for reactive routing and
multicast for proactive, we got a proposal before for a multicast routing
which was presented in IETF89 meeting.

Therefore, this group needs to focus on two new routing: 1- Multicast
Reactive Routing, 2- Multicast Proactive Routing, in addition we may add 3-
Hybrid Routing. The multicast routing is with high priority, because we
only have very simple multicast, which MANET needs multicast because most
use cases depend on group communication.

IMHO, our group needs an information draft for MANET considerations and use
cases. We had separate considerations in RFCs and we need to add uses of
our past done protocols and looking to the future work use cases. This
draft needs to work in parallel with updating RFC2501, which needs update
specially that it ignore the new MANET packet and MANET interfaces. For
example, in MANET WG the 5148 was just for jitter, and to solve issues
related to a protocol, but we need a full picture of other considerations,
and one place to have all consideration, not many documents with
considerations. However, we need to separate a one item that covers MANET
security considerations related to the MANET protocol, and security related
to the MANET packet. Therefore, my overall suggestion is that the work
items with priority are as follows:

1- MANET considerations and use cases   (highest priority, p=1)
2- update of RFC2501     (p=2)
3- Multicast Reactive Routing (p=3)
4- Multicast Proactive Routing (p=3)
5- MANET security considerations (p=4)
6- Maintenance of OLSRv2 (p=3)

Best Regards
AB

AB

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Mon, 20 Jun 2016 19:18:55 +0000

On 6/20/16, 12:53 PM, "Abdussalam Baryun" <[email-masked]<mailto:[email-masked]>> wrote:

AB:

Hi!

...

Milestones in my opinion are not priority indications, because in project management work-items mostly work in parallel, so milestones do not show priority, and in the past practice of MANET WG there are many later milestones that were advanced old milestones. I suggest that IETF and IESG change plans for approvals to add priority especial for groups like MANET WG.

I think that those are great comments for the WG Chairs to keep in mind, after all, there are the ones responsible for the progress of the WG (rfc2418).   Besides using milestones, the WG Chairs can use any other project management methodology to keep the WG on track.

On the other hand, I don't think the IEFT/IESG should make special provisions for any specific WG.  Having said that, the WG Chairs and I will be working together to make sure the focus of the WG is applied to the agreed upon priorities.

Some of your other suggestions (I left them below for reference) I think may fit in items that are already in the charter.  The WG may want to discuss others and their priority - but that is something I will leave to the Chairs and the WG to decide.

Thanks!

Alvaro.

Yes, we worked MANET unicast manet routing; reactive and proactive, experimentals and standards but submitted successfully only the proactive as standard, so we need to work multicast manet routing now. So we need multicast reactive and multicast proactive routing, usually multicast routing is the most important routing in MANET environment. However, it was a great plan that MANET WG started in the past with unicast and now the new issue is multicast routing. We need multicast for reactive routing and multicast for proactive, we got a proposal before for a multicast routing which was presented in IETF89 meeting.

Therefore, this group needs to focus on two new routing: 1- Multicast Reactive Routing, 2- Multicast Proactive Routing, in addition we may add 3- Hybrid Routing. The multicast routing is with high priority, because we only have very simple multicast, which MANET needs multicast because most use cases depend on group communication.

IMHO, our group needs an information draft for MANET considerations and use cases. We had separate considerations in RFCs and we need to add uses of our past done protocols and looking to the future work use cases. This draft needs to work in parallel with updating RFC2501, which needs update specially that it ignore the new MANET packet and MANET interfaces. For example, in MANET WG the 5148 was just for jitter, and to solve issues related to a protocol, but we need a full picture of other considerations, and one place to have all consideration, not many documents with considerations. However, we need to separate a one item that covers MANET security considerations related to the MANET protocol, and security related to the MANET packet. Therefore, my overall suggestion is that the work items with priority are as follows:

Best Regards
AB

---

From: James Nguyen <[email-masked]>
Date: Mon, 27 Jun 2016 13:31:22 -0400

Hi,

I notice that the MANET Management Document is back on the work item list,
but I thought that we wouldn't work on this as we discussed during the last
interim.  Please advise.

Work Items:
...

- Document outlining challenges and best practices for deploying and
managing MANET networks.

Milestones
...
- Nov 2016 MANET Management Document (Informational)

Thanks,

James

On Mon, Jun 20, 2016 at 3:18 PM, Alvaro Retana (aretana) <[email-masked]>
wrote:

> On 6/20/16, 12:53 PM, "Abdussalam Baryun" <[email-masked]>
> wrote:
>
> AB:
>
> Hi!
>
> …
>
>
>
> I think that those are great comments for the WG Chairs to keep in mind,
> after all, there are the ones responsible for the progress of the WG
> (rfc2418).   Besides using milestones, the WG Chairs can use any other
> project management methodology to keep the WG on track.
>
> On the other hand, I don't think the IEFT/IESG should make special
> provisions for any specific WG.  Having said that, the WG Chairs and I will
> be working together to make sure the focus of the WG is applied to the
> agreed upon priorities.
>
>
> Some of your other suggestions (I left them below for reference) I think
> may fit in items that are already in the charter.  The WG may want to
> discuss others and their priority — but that is something I will leave to
> the Chairs and the WG to decide.
>
> Thanks!
>
> Alvaro.
>
>
>
>
> IMHO, our group needs an information draft for MANET considerations and
> use cases. We had separate considerations in RFCs and we need to add uses
> of our past done protocols and looking to the future work use cases. This

-- 
James Nguyen
Email: [email-masked]