Subject: Re: [manet] MANET action items (as seen by Justin Dean)

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 7 Sep 2014 22:56:58 +0200

Hi Thomas,

Sorry for the delay. I agree that we work together for progress of
WG drafts. My respond and comments below.

On Monday, July 28, 2014, Thomas Clausen wrote:

> Abdussalam,
>
> On Jul 23, 2014, at 14:18, Abdussalam Baryun <[email-masked]>
> wrote:
>
> On Tue, Jul 22, 2014 at 10:35 PM, Justin Dean <[email-masked]>
> wrote:
>
>> Notes on action items coming out of the MANET working group meeting.
>> (this list is not exhaustive of the topics covered in the meeting)
>>
>> 1) A suggestion was made to ask Stan if dlep editing help would be
>> helpful. If yes who should that person(s) be?
>>
>> 2) What to do with the report MIB; Kill, finish, revise?
>>
>> 3) Request for WG adoption of SMF sec threat document was made.  No one
>> in the room had read the draft, but there was positive room reaction to
>> adopting a document with this subject and no negative reaction as measured
>> by hum.  Please read the draft and comment.
>>
>
> The WG should read the draft and discuss before adopting or humming and I
> hope the chairs consider the high volume of drafts to give me more time
> before their decisions.
>
>
> The documents were submitted well in advance of the meeting, before the
> document submission deadline that precedes all IETF meetings, and were
> announced on the list at about the same time.
>

I really think there are limits for any WG/individual of work item volume
in and out. However, it was just my comment to clarify I am not responsible
for missing deadline dates of WG Calls. If our calls are serious then it
should consider abilities. However, that may make my reviews get late in
IETF LC.

> There were not a whole lot of new WG documents in MANET this time around,
> and there were no updates to two of the documents which otherwise are WG
> documents, made before that official deadline — compared to other WGs, I
> don’t think that this can be considered a particularly high volume of
> drafts, and the drafts are not particularly complex nor wrong either.
>

If WG agrees I don't mind but just I made clear my comment on the thread.

>  6) Request for WG adoption of OLSRv2 multi-path for experimental status
>> was made.  No one in the room had read the draft, there was mixed but
>> positive reaction as measured by hum.  Please read the draft and comment.
>>
>
> I reject until we get time to review and do our priorities on other drafts.
>
>
> I agree, that it would be good to see forward progress on the documents,
> for which there has been none.
>
> As you have no doubt also observed, for both draft-ietf-manet-aodvv2 and
> draft-ietf-manet-dlep, there have been ample feedback and reviews given on
> the mailing list, but (for the former) that feedback has not been reflected
> in the recent versions of the document, and (for the latter) there has been
> no new version for a while (but, a lot of good discussion).
>
> While the authors of these two documents work to figure out to spin new
> revisions among themselves, revisions which fold in all the feedback that
> the WG has provided, the rest of the WG can’t be expected to simply idle
> when there’re other things to do.
>
> Perhaps your volunteering to help the authors of draft-ietf-manet-aodvv2
> and draft-ietf-manet-dlep in the editorial process might be a way for you
> to contribute to making progress?
>

I am doing my best volunteering these drafts and for all other WG drafts,
but trying to cope with WGLCs as well. However, I think our milestones to
meet are more important than meeting deadlines of WG calls.

>
> 7) Request for WG adoption of ODMRP was made.  Discussion within the room
>> touched upon the charter and was generally positive to multicast work but
>> again charter. No hum was held.
>>
>
> I dont support adopting reactive multicast until we finish the reactive
> standard
>
>
> For what it’s worth, there’s actually no dependency between ODMRP and the
> reactive unicast protocol
>

Both are reactive and both are with similar applicability use, so from user
point of view if more dependent possibilities may make advantages to both.

— I would even make the case that ODMRP would work quite nicely on a
> network on which OLSRv2 provides unicast routing, since ODMRP in that case
> could take advantage of OLSRv2’s optimized flooding (for example) for
> diffusing its control messages and maintaining link status tracking.
>

Ok, we can make it for that applicability use case, which is reasonable for
me as 7181 is completed and being accepted.

AB