From abdussalambaryun@gmail.com Sat Sep 1 11:41:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A99E11E810F for ; Sat, 1 Sep 2012 11:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4e5L09o8UTez for ; Sat, 1 Sep 2012 11:41:11 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46F8811E80BA for ; Sat, 1 Sep 2012 11:41:11 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4846213vbb.31 for ; Sat, 01 Sep 2012 11:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GQOQwadY+pgIPX3gS1zCrCuBpErz/STb4n2Clivm7MA=; b=wAkBIZw13vD36lcmP0kW0pBrvm8b/GlY0RSSKZcDXDpzPg7oEBDnPEmFLMSh/FX9Ku 3ubVuHDPuZisGNZjIMzBPicprUXimPKkwwYOQ57QEpyxuvF+kpRWOgd1VL2rOEOGDY3Q FJsd0s7nhxJj/+2LTijunM9A9oMfBvlI8KbQDb78PPBlKj57BCSjCpuOgDnmisz6G3mq mOrMg9s+UNz9JcVmjTQDYEWHSQS4oadsxdASAjyBIoAB3N/wi5JyYAs9Tuh7LPXkaXyz 1iQKGvQaZIP3WQEBUiBq+l5OtCt2G6TpvQ2iWnywbeZq7pWJWlEKDyLjJNFlhdUxdHZd SHIw== MIME-Version: 1.0 Received: by 10.220.119.198 with SMTP id a6mr8394161vcr.23.1346524870314; Sat, 01 Sep 2012 11:41:10 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Sat, 1 Sep 2012 11:41:10 -0700 (PDT) In-Reply-To: References: Date: Sat, 1 Sep 2012 20:41:10 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Discussing LOADng suggestions/Reminder X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 18:41:12 -0000 >From 29-March-2012 until 30-July-2012 and now, loadng authors did not discuss issues, however, I will send a fourth reminder after three weeks if no responds. Have a nice vacation, Best Regards AB On 9/1/12, Thomas Heide Clausen wrote: > You address me nominatively so I will respond - but, note that I am but one > among the authors. > > I believe that all the various feedback currently is being digested by the > authors - but, do not forget that August is vacation-week in good parts of > Europe, and some of us are only just coming back to the office. > > Best, > > Thomas > > > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ > > "Any simple problem can be made insoluble if enough meetings are held to > discuss it." > -- Mitchell's Law of Committees > > > On 1 Sep 2012, at 02:48, Abdussalam Baryun > wrote: > >> +++++++++++++++ Third Reminder ++++++++++++++++ >> >> Hi Thomas, >> >> I have two emails (on 30 May and on 31 July, as below) of suggestions >> and questions not responded to, please your respond is important for >> progress and discussion on the list. I beleive the issue was also >> raised in the last WG meeting on 30 July, and the WG agrees to see >> discussion. Not sure if the authors are willing change the draft or >> not. >> >> AB >> === >> On 7/31/12, Abdussalam Baryun wrote: >>> Hi Thomas and All >>> >>> I am interested in LOADng and did discuss about it from May 2012 until >>> now. I gave comments [1] on LOADng but no respond so far, I asked from >>> before for more discussion but there was no, and hope that we don't >>> forget the past comments on any document in ietf. The LOADng SHOULD >>> specify use case that are related to MANET not LLN. I suggest that the >>> word LLN taken out of the name as well and specify mobility [1-2]. >>> >>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >>> then changed its direction to MANET [3]. However, please note that >>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>> adoption. >>> >>> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12924.html >>> [2] http://www.ietf.org/mail-archive/web/manet/current/msg12928.html >>> [3] http://www.ietf.org/mail-archive/web/manet/current/msg12933.html >>> >>> thanking you, >>> AB >>>> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun >>>> wrote: >>>>> On 5/29/12, JP Vasseur wrote: >>>>>> >>>>>> We already have two different WG: MANET and ROLL. >>>>>> >>>>> >>>>> Yes we know. That is why LOADng authors should choose either to serve >>>>> LLN that is considered by ROLL WG or they choose serving MANET, and it >>>>> is considered by MANET WG. But the question is which suggestion option >>>>> do you think is better for LOADng-draft? >>>>> >>>>>> MANET is tasked, amongst other, to publish a reactive >>>>>> routing protocol. >>>>> >>>>> MANET is tasked to publish routing protocols that serve the MANET >>>>> network. IMO, MANET-WG is not tasked to publish protocols serving only >>>>> LLN just because the protocol is reactive. Please note that LOADng >>>>> protocol does not even mention MANET nor mobile routers in its draft, >>>>> which confuses its purpose, the authors should look into that. >>>>> >>>>> Abdussalam Baryun >>>> >>> > From ulrich@herberg.name Sat Sep 1 14:38:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C784111E8112 for ; Sat, 1 Sep 2012 14:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbAKH8yGdeFP for ; Sat, 1 Sep 2012 14:38:16 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D282811E80F4 for ; Sat, 1 Sep 2012 14:38:16 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so6196501pbb.31 for ; Sat, 01 Sep 2012 14:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=OTLjFg0MvC0YkqOwVFUhXCxaGBkbPZY8ADtSqZzNrmE=; b=a4RSB96yRNvQGhORfoj8/6CklCnLl2dQKrRCVrpuZtyz3LDGYfVjjFmCghqmn27qKt DL7b/EVHjXNaEwNbdpuLyUFiZ+6SQbEcHiBb06I7fZ7du23YjG0voj22hS4b6hKRz4pi nWp+KYMaYNfevFBVXvAlzkBipVfNGfVTRtZuc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=OTLjFg0MvC0YkqOwVFUhXCxaGBkbPZY8ADtSqZzNrmE=; b=U4A3ago36C2END8UBQLmKDohqTkLuBUDNt/Fl7m6lTgM1+3Du6we/UOUp8eUrf9nmc B3vWkRXAlxXEorJTj3KF5F8aN964RZBRNnyqzHkgaKVE7eD8JoVK9PMPS5Ws1A14T3eK gXVQFO5yYvy4x9MLEGRHYK7W1T+fWRYccaAtrofUz3fu3MUEL1+3c63vB9g+KZdCrg+W eF1vSgf22dfnLgfwkGJUYYTjqpbvqtJNtS5mf04HRqXkYgsdwsH2LkdyqIHwAg5R1m+7 Qvpo57n7eyH7YwyPbovMJSdfhfLr/tNAUGu9LDttp2nYj9PklLjGhcUIPasd3KITQI0W P3ow== Received: by 10.66.78.195 with SMTP id d3mr23752414pax.17.1346535496324; Sat, 01 Sep 2012 14:38:16 -0700 (PDT) Received: from [10.0.1.5] (c-76-102-41-234.hsd1.ca.comcast.net. [76.102.41.234]) by mx.google.com with ESMTPS id st6sm6363687pbc.58.2012.09.01.14.38.14 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Sep 2012 14:38:15 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Ulrich Herberg Date: Sat, 1 Sep 2012 14:39:23 -0700 To: Abdussalam Baryun X-Gm-Message-State: ALoCoQl8/TcCTy/3pFYyxzJ+tWIN8Kt1iwZ3ANjM46uyQhgXehKFBYsrF9oF6tnYVEbv2lro7v3l Cc: manet Subject: Re: [manet] Discussing LOADng suggestions/Reminder X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 21:38:17 -0000 Dear Abdussalam, as Thomas said, we are currently working on the feedback. Note that we all h= ave a full-time job, in addition to IETF work. There is no need to send us r= eminders. Best regards Ulrich On Sep 1, 2012, at 11:41, Abdussalam Baryun wro= te: > =46rom 29-March-2012 until 30-July-2012 and now, loadng authors did not > discuss issues, however, I will send a fourth reminder after three > weeks if no responds. Have a nice vacation, >=20 > Best Regards > AB >=20 > On 9/1/12, Thomas Heide Clausen wrote: >> You address me nominatively so I will respond - but, note that I am but o= ne >> among the authors. >>=20 >> I believe that all the various feedback currently is being digested by th= e >> authors - but, do not forget that August is vacation-week in good parts o= f >> Europe, and some of us are only just coming back to the office. >>=20 >> Best, >>=20 >> Thomas >>=20 >>=20 >> -- >> Thomas Heide Clausen >> http://www.thomasclausen.org/ >>=20 >> "Any simple problem can be made insoluble if enough meetings are held to >> discuss it." >> -- Mitchell's Law of Committees >>=20 >>=20 >> On 1 Sep 2012, at 02:48, Abdussalam Baryun >> wrote: >>=20 >>> +++++++++++++++ Third Reminder ++++++++++++++++ >>>=20 >>> Hi Thomas, >>>=20 >>> I have two emails (on 30 May and on 31 July, as below) of suggestions >>> and questions not responded to, please your respond is important for >>> progress and discussion on the list. I beleive the issue was also >>> raised in the last WG meeting on 30 July, and the WG agrees to see >>> discussion. Not sure if the authors are willing change the draft or >>> not. >>>=20 >>> AB >>> =3D=3D=3D >>> On 7/31/12, Abdussalam Baryun wrote: >>>> Hi Thomas and All >>>>=20 >>>> I am interested in LOADng and did discuss about it from May 2012 until >>>> now. I gave comments [1] on LOADng but no respond so far, I asked from >>>> before for more discussion but there was no, and hope that we don't >>>> forget the past comments on any document in ietf. The LOADng SHOULD >>>> specify use case that are related to MANET not LLN. I suggest that the >>>> word LLN taken out of the name as well and specify mobility [1-2]. >>>>=20 >>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but >>>> then changed its direction to MANET [3]. However, please note that >>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That >>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss >>>> adoption. >>>>=20 >>>> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12924.html >>>> [2] http://www.ietf.org/mail-archive/web/manet/current/msg12928.html >>>> [3] http://www.ietf.org/mail-archive/web/manet/current/msg12933.html >>>>=20 >>>> thanking you, >>>> AB >>>>> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun >>>>> wrote: >>>>>> On 5/29/12, JP Vasseur wrote: >>>>>>>=20 >>>>>>> We already have two different WG: MANET and ROLL. >>>>>>>=20 >>>>>>=20 >>>>>> Yes we know. That is why LOADng authors should choose either to serve= >>>>>> LLN that is considered by ROLL WG or they choose serving MANET, and i= t >>>>>> is considered by MANET WG. But the question is which suggestion optio= n >>>>>> do you think is better for LOADng-draft? >>>>>>=20 >>>>>>> MANET is tasked, amongst other, to publish a reactive >>>>>>> routing protocol. >>>>>>=20 >>>>>> MANET is tasked to publish routing protocols that serve the MANET >>>>>> network. IMO, MANET-WG is not tasked to publish protocols serving onl= y >>>>>> LLN just because the protocol is reactive. Please note that LOADng >>>>>> protocol does not even mention MANET nor mobile routers in its draft,= >>>>>> which confuses its purpose, the authors should look into that. >>>>>>=20 >>>>>> Abdussalam Baryun >>>>>=20 >>>>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Sun Sep 2 02:08:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C402621F8A25 for ; Sun, 2 Sep 2012 02:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZj9BA8Reihy for ; Sun, 2 Sep 2012 02:08:19 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9992221F8A24 for ; Sun, 2 Sep 2012 02:08:19 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so5304965vcb.31 for ; Sun, 02 Sep 2012 02:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XUIDL+IP6pOnHbUnM+zI1JJVqjk+V/9wk79cQ2wW7GE=; b=RfzO+2OiFU8qogDtevMXWOJHAhPt4sAGaeIINoh2lYq7NWxCErrcDqvWmXLNbUcjFW Aqp74M/6dP//1QX7dXUL7smoOzQvMACMaVhEhZnujQWwGnsNCQokUq1Sks/D0uyQuLZ5 dgzD4oDZGU3xCMxsLqnKI4xx1xG1opBreutU/UBJOFdV1EPIpd7XbGOOmYp2C+tsGu1+ GL+RRxsj8monA/GSIsRljqrt/zCmY83fkq0db+ZWepoQXlnRVF6RQPSluGfJOc7wUS6e tGNweBtn5w9fE5UAI2pvib2x+WEegZAE3bu4H2bnNBGJQexNnXJwI1/ymbgtTnoT9+vA 0GVQ== MIME-Version: 1.0 Received: by 10.220.141.208 with SMTP id n16mr9551488vcu.22.1346576898933; Sun, 02 Sep 2012 02:08:18 -0700 (PDT) Received: by 10.220.55.9 with HTTP; Sun, 2 Sep 2012 02:08:18 -0700 (PDT) In-Reply-To: References: Date: Sun, 2 Sep 2012 10:08:18 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=f46d042fd8c0b9442c04c8b45d5c Cc: manet Subject: Re: [manet] Discussing LOADng suggestions/Reminder X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 09:08:20 -0000 --f46d042fd8c0b9442c04c8b45d5c Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 1, 2012 at 10:39 PM, Ulrich Herberg wrote: > Dear Abdussalam, > > as Thomas said, we are currently working on the feedback. Note that we all > have a full-time job, in addition to IETF work. There is no need to send us > reminders. > > The WG chair requested twice to discuss the draft matters on the list (in 83 and 84 meeting), but still nothing done, I am just following, AB > Best regards > Ulrich > > On Sep 1, 2012, at 11:41, Abdussalam Baryun > wrote: > > > From 29-March-2012 until 30-July-2012 and now, loadng authors did not > > discuss issues, however, I will send a fourth reminder after three > > weeks if no responds. Have a nice vacation, > > > > Best Regards > > AB > > > > On 9/1/12, Thomas Heide Clausen wrote: > >> You address me nominatively so I will respond - but, note that I am but > one > >> among the authors. > >> > >> I believe that all the various feedback currently is being digested by > the > >> authors - but, do not forget that August is vacation-week in good parts > of > >> Europe, and some of us are only just coming back to the office. > >> > >> Best, > >> > >> Thomas > >> > >> > >> -- > >> Thomas Heide Clausen > >> http://www.thomasclausen.org/ > >> > >> "Any simple problem can be made insoluble if enough meetings are held to > >> discuss it." > >> -- Mitchell's Law of Committees > >> > >> > >> On 1 Sep 2012, at 02:48, Abdussalam Baryun > >> wrote: > >> > >>> +++++++++++++++ Third Reminder ++++++++++++++++ > >>> > >>> Hi Thomas, > >>> > >>> I have two emails (on 30 May and on 31 July, as below) of suggestions > >>> and questions not responded to, please your respond is important for > >>> progress and discussion on the list. I beleive the issue was also > >>> raised in the last WG meeting on 30 July, and the WG agrees to see > >>> discussion. Not sure if the authors are willing change the draft or > >>> not. > >>> > >>> AB > >>> === > >>> On 7/31/12, Abdussalam Baryun wrote: > >>>> Hi Thomas and All > >>>> > >>>> I am interested in LOADng and did discuss about it from May 2012 until > >>>> now. I gave comments [1] on LOADng but no respond so far, I asked from > >>>> before for more discussion but there was no, and hope that we don't > >>>> forget the past comments on any document in ietf. The LOADng SHOULD > >>>> specify use case that are related to MANET not LLN. I suggest that the > >>>> word LLN taken out of the name as well and specify mobility [1-2]. > >>>> > >>>> IMHO this protocol was intended as for ROLL WG not for MANET WG, but > >>>> then changed its direction to MANET [3]. However, please note that > >>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LLNs. That > >>>> said, LOADng SHOULD specfy where is its limits. Then we can discuss > >>>> adoption. > >>>> > >>>> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12924.html > >>>> [2] http://www.ietf.org/mail-archive/web/manet/current/msg12928.html > >>>> [3] http://www.ietf.org/mail-archive/web/manet/current/msg12933.html > >>>> > >>>> thanking you, > >>>> AB > >>>>> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun > >>>>> wrote: > >>>>>> On 5/29/12, JP Vasseur wrote: > >>>>>>> > >>>>>>> We already have two different WG: MANET and ROLL. > >>>>>>> > >>>>>> > >>>>>> Yes we know. That is why LOADng authors should choose either to > serve > >>>>>> LLN that is considered by ROLL WG or they choose serving MANET, and > it > >>>>>> is considered by MANET WG. But the question is which suggestion > option > >>>>>> do you think is better for LOADng-draft? > >>>>>> > >>>>>>> MANET is tasked, amongst other, to publish a reactive > >>>>>>> routing protocol. > >>>>>> > >>>>>> MANET is tasked to publish routing protocols that serve the MANET > >>>>>> network. IMO, MANET-WG is not tasked to publish protocols serving > only > >>>>>> LLN just because the protocol is reactive. Please note that LOADng > >>>>>> protocol does not even mention MANET nor mobile routers in its > draft, > >>>>>> which confuses its purpose, the authors should look into that. > >>>>>> > >>>>>> Abdussalam Baryun > >>>>> > >>>> > >> > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > --f46d042fd8c0b9442c04c8b45d5c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Sep 1, 2012 at 10:39 PM, Ulrich Herb= erg <ulrich@herberg.name> wrote:
Dear Abdussalam,

as Thomas said, we are currently working on the feedback. Note that we all = have a full-time job, in addition to IETF work. There is no need to send us= reminders.

=A0
The=A0WG chair requested twice to discu= ss the draft matters on the list (in 83 and 84 meeting), but still nothing = done, I am just following,
=A0
AB
=A0
Best regards
Ulrich

On Sep 1, 2012, at 11:41, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

> From 29-March-2012 until 30-July-2012 and now, loadng authors did not<= br> > discuss issues, however, I will send a fourth reminder after three
> weeks if no responds. Have a nice vacation,
>
> Best Regards
> AB
>
> On 9/1/12, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:
>> You address me nominatively so I will respond - but, note that I a= m but one
>> among the authors.
>>
>> I believe that all the various feedback currently is being digeste= d by the
>> authors - but, do not forget that August is vacation-week in good = parts of
>> Europe, and some of us are only just coming back to the office. >>
>> Best,
>>
>> Thomas
>>
>>
>> --
>> Thomas Heide Clausen
>> http:/= /www.thomasclausen.org/
>>
>> "Any simple problem can be made insoluble if enough meetings = are held to
>> discuss it."
>> =A0 -- Mitchell's Law of Committees
>>
>>
>> On 1 Sep 2012, at 02:48, Abdussalam Baryun <abdussalambaryun@gmail.com>
>> wrote:
>>
>>> +++++++++++++++ =A0Third Reminder =A0++++++++++++++++
>>>
>>> Hi Thomas,
>>>
>>> I have two emails (on 30 May and on 31 July, as below) of sugg= estions
>>> and questions not responded to, please your respond is importa= nt for
>>> progress and discussion on the list. I beleive the issue was a= lso
>>> raised in the last WG meeting on 30 July, and the WG agrees to= see
>>> discussion. Not sure if the authors are willing change the dra= ft or
>>> not.
>>>
>>> AB
>>> =3D=3D=3D
>>> On 7/31/12, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
>>>> Hi Thomas and All
>>>>
>>>> I am interested in LOADng and did discuss about it from Ma= y 2012 until
>>>> now. I gave comments [1] on LOADng but no respond so far, = I asked from
>>>> before for more discussion but there was no, and hope that= we don't
>>>> forget the past comments on any document in ietf. The LOAD= ng SHOULD
>>>> specify use case that are related to MANET not LLN. I sugg= est that the
>>>> word LLN taken out of the name as well and specify mobilit= y [1-2].
>>>>
>>>> IMHO this protocol was intended as for ROLL WG not for MAN= ET WG, but
>>>> then changed its direction to MANET [3]. However, please n= ote that
>>>> *ONLY* some LLNs are MANETs, and *ONLY* some MANETs are LL= Ns. That
>>>> said, LOADng SHOULD specfy where is its limits. Then we ca= n discuss
>>>> adoption.
>>>>
>>>> [1] http://www.ietf.org/mail-archive/w= eb/manet/current/msg12924.html
>>>> [2] http://www.ietf.org/mail-archive/w= eb/manet/current/msg12928.html
>>>> [3] http://www.ietf.org/mail-archive/w= eb/manet/current/msg12933.html
>>>>
>>>> thanking you,
>>>> AB
>>>>> On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun
>>>>> <abdussalambaryun at gmail.com> wrote:
>>>>>> On 5/29/12, JP Vasseur <jpv at cisco.com> wrote:
>>>>>>>
>>>>>>> We already have two different WG: MANET and RO= LL.
>>>>>>>
>>>>>>
>>>>>> Yes we know. That is why LOADng authors should cho= ose either to serve
>>>>>> LLN that is considered by ROLL WG or they choose s= erving MANET, and it
>>>>>> is considered by MANET WG. But the question is whi= ch suggestion option
>>>>>> do you think is better for LOADng-draft?
>>>>>>
>>>>>>> MANET is tasked, amongst other, to publish a r= eactive
>>>>>>> routing protocol.
>>>>>>
>>>>>> MANET is tasked to publish routing protocols that = serve the MANET
>>>>>> network. IMO, MANET-WG is not tasked to publish pr= otocols serving only
>>>>>> LLN just because the protocol is reactive. Please = note that LOADng
>>>>>> protocol does not even mention MANET nor mobile ro= uters in its draft,
>>>>>> which confuses its purpose, the authors should loo= k into that.
>>>>>>
>>>>>> Abdussalam Baryun
>>>>>
>>>>
>>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--f46d042fd8c0b9442c04c8b45d5c-- From jorgenavarro@ugr.es Mon Sep 3 08:00:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC1A21F8672 for ; Mon, 3 Sep 2012 08:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWSFPNJZY6CH for ; Mon, 3 Sep 2012 07:59:59 -0700 (PDT) Received: from mail2.ugr.es (mail2.ugr.es [150.214.35.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDAD21F865D for ; Mon, 3 Sep 2012 07:59:58 -0700 (PDT) Received: from smtp3.ugr.es (smtp3.ugr.es [150.214.20.71]) by mail2.ugr.es (Postfix) with ESMTP id 391E47318 for ; Mon, 3 Sep 2012 16:59:47 +0200 (CEST) Received: from JorgePC (c-24-98-192-15.hsd1.ga.comcast.net [24.98.192.15]) by smtp3.ugr.es (Postfix) with ESMTP id 4E0123C802 for ; Mon, 3 Sep 2012 16:59:45 +0200 (MEST) From: "Jorge Navarro Ortiz" To: Date: Mon, 3 Sep 2012 10:59:37 -0400 Message-ID: <048301cd89e4$bea6e590$3bf4b0b0$@ugr.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0484_01CD89C3.37982BC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2J5LXawkEg7hj3Tmm8OSyqxN9gwA== Content-Language: es Subject: [manet] FIRST ANNOUNCEMENT WoWMoM 2013 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 15:00:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0484_01CD89C3.37982BC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------------------------------------------------------------------------ =20 FIRST ANNOUNCEMENT =20 WoWMoM 2013 Fourteenth International Symposium on a World of Wireless, Mobile and Multimedia Networks =20 http://wowmom2013.tmit.bme.hu/ =20 sponsored by IEEE Computer Society, University of Texas at Arlington, IEEE Computer Society TC on Computer Communications (TCCC) =20 June 4-7, 2013 Madrid, Spain =20 ------------------------------------------------------------------------ SCOPE The evolution of wireless networking technologies and their key role in=20 future Internet scenarios offer an increasing wealth of opportunities=20 for distributing multimedia contents over wireless networks, enabling=20 dissemination of professional contents to mobile users as well as=20 sharing user-generated contents among them. Users will be able to=20 retrieve, publish, and manage information, communicate with other users=20 or devices, access and author services, create and exploit context- awareness and so on. Papers that present original work, validated by=20 experimentation, simulation, or analysis, are solicited. Practical=20 experiences and experimental efforts from both industry and academy,=20 duly documenting the lessons learned from test-beds, field-trials, or=20 real deployments, are also welcome. =20 A detailed list of topics of interest is available on the conference website at http://wowmom2013.tmit.bme.hu/. Complete instructions for submitting papers will be posted in due time. =20 Papers presented at the Symposium will be considered for a Best Paper=20 Award. Papers of particular merit will be considered for a fast track=20 publication in the Elsevier Pervasive and Mobile Computing Journal=20 (PMC). =20 Important dates: - Abstract submission: November 23, 2012. - Full manuscript due: November 30, 2012. - Manuscript acceptance notification: March 15, 2013. =20 =20 WORKSHOPS Proposals for full day workshops are solicited. Selections will be made=20 considering the expertise and experience of the workshop organizers and=20 the relevance of the topic to the central theme of the conference.=20 Instructions for submitting a workshop proposal can be found on the=20 conference website. =20 Important dates: - Workshop proposals submission: October 20, 2012. - Workshop acceptance notification: November 5, 2012. =20 =20 INDUSTRY SESSION Original and previously unpublished research papers from industry=20 researchers and professionals for a one-day Industry Session track are=20 solicited. A key goal of this session is to present systems-oriented=20 research that exposes the academic and research communities to real-life = issues and problems being faced in industry. Papers in this session will = be included in the main proceedings of WoWMoM 2013. Submission=20 instructions for submitting will be posted in due time on the conference = website. =20 =20 DEMOS Technical demonstration in the areas of wireless, mobile, and multimedia = networking as well as ubiquitous and pervasive systems are solicited.=20 Instructions for submitting a demo proposal will be posted in due time=20 on the conference website. =20 =20 PhD FORUM A PhD forum will be organized as a poster session to allow PhD students=20 to interact both with their peers as well as experienced researchers=20 from industry. Extended abstracts comprising a summary of research=20 findings, work in progress and planned research from Doctoral students=20 working in areas related to wireless, mobile and multimedia networking=20 are solicited. Instructions for submitting proposals will be posted in=20 due time on the conference website. =20 =20 GENERAL CHAIR - Sergey Gorinsky, Institute IMDEA Networks, Spain =20 TPC CHAIRS - Yonghe Liu, University of Texas at Arlington, USA - Enzo Mingozzi, University of Pisa, Italy =20 WORKSHOP CHAIRS - Miguel A. Labrador, University of South Florida, USA - Polychronis Koutsakis, Technical University of Crete, Greece =20 INDUSTRY-TRACK CHAIRS - Claudio Cicconetti, Intecs, Italy - Vania Conan, Thales Communications & Security, France =20 PUBLICATIONS CHAIRS - Angelos Lazaris, University of Southern California, USA - Balaji Rengarajan, Institute IMDEA Networks,Spain =20 PhD FORUM CHAIRS - Marilia Curado, University of Coimbra, Portugal - Silvia Giordano, SUPSI, Switzerland =20 DEMO CHAIRS - Omer Gurewitz, Ben Gurion University, Israel - Andres Marin Lopez, Carlos III University of Madrid, Spain =20 PANEL CHAIR - Albert Banchs, Institute IMDEA Networks and Carlos III University of Madrid, Spain =20 PUBLICITY CHAIRS - Michela Becchi, University of Missouri, USA - Yaping Lin, Hunan University, China - Jorge Navarro Ortiz, University of Granada, Spain - Maxim Podlesny, University of Waterloo, Canada =20 LOCAL ORGANIZATION CHAIRS - Vincenzo Mancuso, Institute IMDEA Networks, Spain - Manuel Urue=F1a, Carlos III University of Madrid, Spain =20 FINANCE & REGISTRATION CHAIR - Yonghe Liu, University of Texas at Arlington, USA =20 WEB CHAIRS - Levente Csikor, Budapest University of Technology and Economics, = Hungary - G=E1bor R=E9tv=E1ri, Budapest University of Technology and Economics, = Hungary =20 STEERING COMMITTEE - Marco Conti, IIT-CNR, Italy - Sajal K. Das, Univ. Texas at Arlington, USA (CHAIR) - Dipankar Raychaudhuri, Rutgers Univ., USA - Satish K. Tripathi, SUNY Buffalo, USA ------=_NextPart_000_0484_01CD89C3.37982BC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

------------------------------------------------------------= ------------

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 FIRST ANNOUNCEMENT

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 WoWMoM 2013

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0Fourteenth = International Symposium on a

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = World of Wireless, Mobile and Multimedia = Networks

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = http://wowmom2013.tmit.bme.hu/

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 sponsored by

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 IEEE Computer Society,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0University of Texas at Arlington,

=A0=A0=A0=A0=A0=A0 IEEE Computer = Society TC on Computer Communications (TCCC)

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 June 4-7, 2013

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Madrid, Spain

 

------------------------------------------------------------= ------------

SCOPE

The evolution of wireless networking technologies and their = key role in

future Internet scenarios offer an increasing wealth of = opportunities

for distributing multimedia contents over wireless = networks, enabling

dissemination of professional contents to mobile users as = well as

sharing user-generated contents among them. Users will be = able to

retrieve, publish, and manage information, communicate with = other users

or devices, access and author services, create and exploit = context-

awareness and so on. Papers that present original work, = validated by

experimentation, simulation, or analysis, are solicited. = Practical

experiences and experimental efforts from both industry and = academy,

duly documenting the lessons learned from test-beds, = field-trials, or

real deployments, are also welcome.

 

A detailed list of topics of = interest is available on the conference

website at = http://wowmom2013.tmit.bme.hu/. Complete instructions = for

submitting papers will be posted in due = time.

 

Papers presented at the Symposium will be considered for a = Best Paper

Award. Papers of particular merit will be considered for a = fast track

publication in the Elsevier Pervasive and Mobile Computing = Journal

(PMC).

 

Important dates:

- Abstract = submission:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 November 23, = 2012.

- = Full manuscript due:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = November 30, 2012.

- Manuscript acceptance notification:=A0=A0=A0=A0 March 15, = 2013.

 

 

WORKSHOPS

Proposals for full day workshops are solicited. Selections = will be made

considering the expertise and experience of the workshop = organizers and

the relevance of the topic to the central theme of the = conference.

Instructions for submitting a workshop proposal can be = found on the

conference website.

 

Important = dates:

- = Workshop proposals submission:=A0=A0=A0=A0=A0=A0=A0 October 20, = 2012.

- = Workshop acceptance notification:=A0=A0=A0=A0 November 5, = 2012.

 

 

INDUSTRY SESSION

Original and previously unpublished = research papers from industry

researchers and professionals for a = one-day Industry Session track are

solicited. A key goal of this = session is to present systems-oriented

research that exposes the academic = and research communities to real-life

issues and problems being faced in = industry. Papers in this session will

be included in the main proceedings = of WoWMoM 2013. Submission

instructions for submitting will be = posted in due time on the conference

website.

 

 

DEMOS

Technical demonstration in the = areas of wireless, mobile, and multimedia

networking as well as ubiquitous = and pervasive systems are solicited.

Instructions for submitting a demo = proposal will be posted in due time

on the conference = website.

 

 

PhD FORUM

A PhD forum will be organized as a poster session to allow = PhD students

to interact both with their peers as well as experienced = researchers

from industry. Extended abstracts comprising a summary of = research

findings, work in progress and planned research from = Doctoral students

working in areas related to wireless, mobile and multimedia = networking

are solicited. Instructions for submitting proposals will = be posted in

due time on the conference website.

 

 

GENERAL = CHAIR

- = Sergey Gorinsky, Institute IMDEA Networks, Spain

 

TPC CHAIRS

- Yonghe Liu, University of Texas = at Arlington, USA

- Enzo Mingozzi, University of Pisa, = Italy

 

WORKSHOP CHAIRS

- Miguel A. Labrador, University of = South Florida, USA

- Polychronis Koutsakis, Technical University of Crete, = Greece

 

INDUSTRY-TRACK CHAIRS

- Claudio Cicconetti, Intecs, = Italy

- = Vania Conan, Thales Communications & Security, = France

 

PUBLICATIONS CHAIRS

- Angelos Lazaris, University of = Southern California, USA

- Balaji Rengarajan, Institute IMDEA = Networks,Spain

 

PhD FORUM CHAIRS

- Marilia Curado, University of = Coimbra, Portugal

- Silvia Giordano, SUPSI, = Switzerland

 

DEMO CHAIRS

- Omer Gurewitz, Ben Gurion University, = Israel

- = Andres Marin Lopez, Carlos III University of Madrid, = Spain

 

PANEL CHAIR

- Albert Banchs, Institute IMDEA Networks and Carlos III = University of Madrid, Spain

 

PUBLICITY = CHAIRS

- = Michela Becchi, University of Missouri, USA

- Yaping Lin, Hunan University, = China

- = Jorge Navarro Ortiz, University of Granada, = Spain

- = Maxim Podlesny, University of Waterloo, Canada

 

LOCAL ORGANIZATION = CHAIRS

- = Vincenzo Mancuso, Institute IMDEA Networks, = Spain

- = Manuel Urue=F1a, Carlos III University of Madrid, = Spain

 

FINANCE & REGISTRATION CHAIR

- Yonghe Liu, University of Texas = at Arlington, USA

 

WEB CHAIRS

- Levente Csikor, Budapest University of Technology and = Economics, Hungary

- G=E1bor R=E9tv=E1ri, Budapest University of Technology = and Economics, Hungary

 

STEERING COMMITTEE

- Marco Conti, IIT-CNR, = Italy

- = Sajal K. Das, Univ. Texas at Arlington, USA = (CHAIR)

- Dipankar = Raychaudhuri, Rutgers Univ., USA

- Satish K. Tripathi, SUNY Buffalo, = USA

------=_NextPart_000_0484_01CD89C3.37982BC0-- From boberry@cisco.com Mon Sep 3 20:05:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74E821F84FD for ; Mon, 3 Sep 2012 20:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmtvjKKtd3oh for ; Mon, 3 Sep 2012 20:05:10 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4F58921F84D3 for ; Mon, 3 Sep 2012 20:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=1198; q=dns/txt; s=iport; t=1346727910; x=1347937510; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=h2c0QCJs8DuVjDpCmZ9YJU3bWwsoUb/NYHXfocIZg2c=; b=DHN3fpWaNUKDw6y3X+VK5W0SGVcDI8RNRRbreIC3gh50Ty7yJJHKhOGY 6s5kjXgjLrWhZ5sdNqveERzrqYAyR0PzkGPowT1sbfRwHAFlT8IHhyTYV /vSxp5hoBXYgtkQTDJkPDit5M42eXU2xYbn4wmHtQyrLnX10DdiIwOgdB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAM9uRVCtJXG+/2dsb2JhbABFhT61aoEHgjkBJ4F9HBmHawuYeoEooACRX2ADlVmFX4hUgWeCfw X-IronPort-AV: E=Sophos;i="4.80,364,1344211200"; d="scan'208";a="117714171" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 04 Sep 2012 03:05:10 +0000 Received: from [192.168.1.203] (ggsg-1vpn2-230-69.cisco.com [10.81.230.69]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q84359hn003428 for ; Tue, 4 Sep 2012 03:05:09 GMT From: Bo Berry Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Sep 2012 23:05:08 -0400 Message-Id: <793C80FE-89C5-478C-AAC1-A42C7982C391@cisco.com> To: manet IETF Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [manet] draft-ietf-manet-dlep03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 03:05:11 -0000 Hi WG Members, hope everyone is well.=20 During our DLEP edits, we missed specifying the DLEP Packet Length=20 as 16-bits. Please make a note.=20 Thanks -Bo Filename: draft-ietf-manet-dlep Revision: 03 Title: Dynamic Link Exchange Protocol (DLEP) URL: = http://www.ietf.org/internet-drafts/draft-ietf-manet-dlep-03.txt Should be: The Generic DLEP Packet Definition contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Signal TLV Type| Length | DLEP TLVs... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signal - One of the DLEP Signal TLV type values=20 defined in this document. 8-bits Length - The length of all of the DLEP data items associated with this signal. 16-bits DLEP data items - One or more data items, encoded in TLVs, as defined in this document. From henning.rogge@fkie.fraunhofer.de Tue Sep 4 01:59:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC5021F84BF for ; Tue, 4 Sep 2012 01:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.256 X-Spam-Level: * X-Spam-Status: No, score=1.256 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7z6PLRzHWDN for ; Tue, 4 Sep 2012 01:59:37 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 7387F21F84AF for ; Tue, 4 Sep 2012 01:59:35 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T8oyp-0005gf-Ot; Tue, 04 Sep 2012 10:59:31 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1T8oyp-0006DQ-MF; Tue, 04 Sep 2012 10:59:31 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Sep 2012 10:59:31 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Sep 2012 10:59:31 +0200 Message-ID: <5045C2F2.9010808@fkie.fraunhofer.de> Date: Tue, 4 Sep 2012 10:59:30 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> In-Reply-To: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000100050207070409040004" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 04 Sep 2012 08:59:31.0539 (UTC) FILETIME=[98F49A30:01CD8A7B] X-Virus-Scanned: yes (ClamAV 0.97.5/15309/Tue Sep 4 04:32:46 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 28a7e05a1c2f4a4dfab586336d5b57ad Cc: Bo Berry , Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 08:59:38 -0000 --------------ms000100050207070409040004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I spent time during the weekend to read through the new DLEP-03 draft a=20 few times. I see that the DLEP-03 draft has changed a lot since the last draft, so=20 I will try to focus both on general issues and small comments.=20 Especially the removal of the "Detached Peer Discovery" will safe a lot=20 of time on this draft, maybe we can talk about getting the "DLEP over=20 radio" feature (or a similar one) back as an extension draft. I also think we should work on standardizing more optional metric values = (otherwise interoperability for additional metrics will be difficult),=20 but that can be done at a later time. Here are my comments: 1.) Bi-directional Discovery ---------------------------- In the current draft both the Modem/Radio and the Router can be the=20 active or the passive component of discovery. I am not sure why this was even changed compared to draft 00-02. I=20 cannot remember anyone disagreeing with the former solution that the=20 Radio/Modem is the active component that sends discovery packets on its=20 own and that the Router will react to them. The new specification mentions the existence of a race condition when=20 both discovery packets are processed at the same time, but doesn't=20 cleanly specifies how this should be detected and how it is resolved. It does not mention the possibility that someone buys a Modem/Radio and=20 a Router which BOTH only implement the passive/reactive Discovery=20 method. In this case the protocol will just do nothing, even with two=20 standard compliant devices. 2.) Semi-optional Acknowledgement Mechanism ------------------------------------------- DLEP-03 makes half of the Acknowledgment messages of DLEP-02 optional=20 (the one for neighbor up/down message). But it still doesn't specify how = their are handled, except by a few rough examples in an appendix. Is one of the peers allowed to send further messages before the last one = was acknowledged? What is happening if a message is not acknowledged by=20 the other side? There is also a strange situation if the sender of a message expects an=20 ACK but the receiver does not support them. Does the receiver somehow=20 recognize the duplicate messages (if yes, how?) and do they need to be=20 dropped? The flow diagrams 30.2.1 and 30.2.2 suggest that Neighbor Updates are=20 only sent by the Modem after receiving a Neighbor Up ACK message. Which=20 would make tranfering metric data between an ACK-enabled radio and=20 router without ACK support impossible. 3.) Mandatory Metric-TLVs with optional content ----------------------------------------------- Both Latency, Resources and Relative Link Quality are defined as=20 mandatory TLVs, but all of them specify that a certain value should be=20 transmitted if the radio cannot calculate the value. Why? If we use a TLV system and accept that a value cannot be calculated by a = radio, we should just make the TLV optional. Otherwise we force the=20 DLEP-implementation to lie about the value. This is especially problematic in the case of the Relative Link Quality=20 TLV, which defines the "not calculable" value as a perfect link. Which=20 means that the routing protocol suddenly optimize their paths to radios=20 which cannot measure their links. 4.) DLEP packet format ---------------------- I am still the opinion that stepping away from RFC5444 was a bad choice, = but we could talk for ages about this so I will focus on the new format=20 defined in DLEP-03. The current format is definitely an improvement=20 compared to the DLEP-02 "half-RFC5444" one. As a general comment I think the description of the TLV values should be = either everywhere in the explaining text above the TLV graphcis or=20 below. But thats cleanup work which can be done later. Section 2: This section explains how the DLEP sequence number should be done. But=20 there is neither a sequence number in the packet format, nor is it=20 mentioned somewhere else in the draft. I am not sure if the sequence=20 number is missing from the packet format description or if the=20 description in section 2 should be removed. Section 8/10: Both section 8 and Section 10 specify the basic message format, this=20 should be joined into a single section. Section 9.1: The Identification TLV is mandatory (what should happen if its missing?) = and must always be first in a DLEP message, right after the Signal TLV=20 header. So why don't put the ID-fields into the header without a TLV=20 around them? In addition to this it would be a good idea to increase the length of=20 Router-ID and Modem-ID to six octets each. Every DLEP-capable modem and=20 router has an ethernet device, which MAC-address can easily be used as a = default unique identification number (if no other number is configured). I am not even sure why the Identification is necessary at all for the=20 router. I see a reason for the Radio-ID, because a router can handle=20 multiple radios. But the way the DLEP-protocol is described, a radio can = only communicate with a single router. Section 9.2: The Version TLV is optional, I am not sure this makes much sense. Either = make it mandatory (and maybe put it into the header) or drop it completel= y. Section 9.7/9.8: The Maximum/Current Data Rate TLVs only allow to specify a single link=20 speed, but there are a lot of radio devices which allow for asymmetric=20 link speeds. Maybe there should be a data-value for incoming and=20 outgoing link speed in both TLVs. Section 9.10: The definition of the Latency TLV is pretty vague, especially for a=20 mandatory TLV. Section 9.13: The Status TLV says that the failure codes are message specific, but=20 these specific TLVs are nowhere in the whole draft. I would suggest=20 adding at least a "generic failure" encoding. Section 9.14: The Heartbeat TLVs Threshold should be allowed to be zero if the=20 Interval is also zero. Section 9.15: The Link Characteristics ACK Timer TLV mentions a "default value", which = is nowhere defined. Maybe this draft should have a "default value" sectio= n? Section 9.18: The Credit Request TLV has length zero but an UNUSED 1 octet content.=20 Either the content should be removed or the length should be 1. I would=20 suggest removing the content until there is an usage for it. Section 11: Heartbeat Interval and Heartbeat Threshold have been joined into a=20 single TLV. Also the usage of the metric values within this message (when send from=20 Router to Modem/Radio) is vague, because its unspecified how this=20 'defaults' are used by the protocol. Section 13: This section allows to not use the Status TLV, but its still defined as=20 mandatory in the list. Section 14: How does one side "determines" that the other side does not implement=20 Layer-3 address changes in Peer Updates? Section 17: What does a Peer Termination ACK with "Status: failure" mean? Section 18: This section mentions that Neighbor Up ACK Messages are required, but=20 they were declared optional in section 7. Section 19: Shouldn't the Neighbor Up ACK Message contain a Status TLV too? Section 22: The Neighbor Update Message is not ACKed at all. Does the Radio need to=20 repeat temporarily unchanging metric values from time to time to make=20 sure they were not lost? Section 23: It would be good to mention the use of Jitter for the Heartbeat Message. This section also contains the default for the "Threshold" value if no=20 Heartbeat TLV is received. This should go to a "Default Value" section. Section 24/25: The texts for "Current Data Rate" of both sections have been mixed up. ----------------------- My general feeling about the new draft is that it is a bit too vague and = underspecified. Even more than draft-02, it leaves a lot of things to=20 "implementation details" and "options", which create the situation that=20 we might get multiple standard compliant devices that are unable to talk = to each other. DLEP specifies a protocol between Radio/Modems and Routers, so we should = work hard on making sure that independent implementations will be=20 inter-operable. There is still a lot of work to be done. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000100050207070409040004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA5MDQwODU5MzBaMCMGCSqGSIb3DQEJBDEWBBQ4gNTeBDowFGt90KDdyob5ApNrhDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAYzenXyKb9Utv4XUmszcPw2Z4QHmaIMyemJS/HljvCKqs dLqK/iK4bjh4wjcaa19V8AYrPypoILkGWPxgm8aA6rGWF/ffKCffh4ldCCTktEYgUD8ysmed m+fSO2pXA5RKyNyDRYYATUnuirh8c8gYas8R2uy9HnxRVNK+Hmj8TMHLdZhbmnaizBG+EDBL o66qKESybWlGOHnzX+to6uSwjAgWBKhGRmPNQrsByJd96FcXrXF9nEZKJAXe8/ATMgye4dQ/ SDYD0Qh6lMOF65jTjMkefbLawyzdqrR9sN0U748//lJuUNAL4hAKdo48kkjppBbBTkSjeuLh Kvk511zK+AAAAAAAAA== --------------ms000100050207070409040004-- From Chris.Dearlove@baesystems.com Tue Sep 4 02:17:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969EC21F8569 for ; Tue, 4 Sep 2012 02:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoJSBqjyZqWj for ; Tue, 4 Sep 2012 02:17:01 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 06CE621F851E for ; Tue, 4 Sep 2012 02:17:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,366,1344207600"; d="scan'208";a="268082308" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 04 Sep 2012 10:17:00 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q849GxaQ020204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 10:16:59 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.208]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0309.002; Tue, 4 Sep 2012 10:16:59 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-03.txt Thread-Index: AQHNhuPyBqCR1ySYSUO9VYuSstZ6L5d52KQAgAATBjA= Date: Tue, 4 Sep 2012 09:16:58 +0000 Message-ID: References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <5045C2F2.9010808@fkie.fraunhofer.de> In-Reply-To: <5045C2F2.9010808@fkie.fraunhofer.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bo Berry , Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 09:17:02 -0000 I haven't read this yet, but have just skimmed Henning's comments. One thin= g jumped out at me from them, they appear to suggest constraints on orderin= g of TLVs. That may be OK by me (but as I said, not read) but a word of wa= rning that pre-5444 had TLV ordering constraints, and some people on the IE= SG really did not like this. I could go into why pre-5444 had such constrai= nts (which ironically, the authors had to be argued into, then back out of)= but I don't think that would be helpful. I'd just say if you have such con= straints, I suggest having strong arguments for this, and to know what shou= ld happen if misordered TLVs are received. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 04 September 2012 10:00 To: manet@ietf.org Cc: Bo Berry; Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt Hi, I spent time during the weekend to read through the new DLEP-03 draft a=20 few times. I see that the DLEP-03 draft has changed a lot since the last draft, so=20 I will try to focus both on general issues and small comments.=20 Especially the removal of the "Detached Peer Discovery" will safe a lot=20 of time on this draft, maybe we can talk about getting the "DLEP over=20 radio" feature (or a similar one) back as an extension draft. I also think we should work on standardizing more optional metric values=20 (otherwise interoperability for additional metrics will be difficult),=20 but that can be done at a later time. Here are my comments: 1.) Bi-directional Discovery ---------------------------- In the current draft both the Modem/Radio and the Router can be the=20 active or the passive component of discovery. I am not sure why this was even changed compared to draft 00-02. I=20 cannot remember anyone disagreeing with the former solution that the=20 Radio/Modem is the active component that sends discovery packets on its=20 own and that the Router will react to them. The new specification mentions the existence of a race condition when=20 both discovery packets are processed at the same time, but doesn't=20 cleanly specifies how this should be detected and how it is resolved. It does not mention the possibility that someone buys a Modem/Radio and=20 a Router which BOTH only implement the passive/reactive Discovery=20 method. In this case the protocol will just do nothing, even with two=20 standard compliant devices. 2.) Semi-optional Acknowledgement Mechanism ------------------------------------------- DLEP-03 makes half of the Acknowledgment messages of DLEP-02 optional=20 (the one for neighbor up/down message). But it still doesn't specify how=20 their are handled, except by a few rough examples in an appendix. Is one of the peers allowed to send further messages before the last one=20 was acknowledged? What is happening if a message is not acknowledged by=20 the other side? There is also a strange situation if the sender of a message expects an=20 ACK but the receiver does not support them. Does the receiver somehow=20 recognize the duplicate messages (if yes, how?) and do they need to be=20 dropped? The flow diagrams 30.2.1 and 30.2.2 suggest that Neighbor Updates are=20 only sent by the Modem after receiving a Neighbor Up ACK message. Which=20 would make tranfering metric data between an ACK-enabled radio and=20 router without ACK support impossible. 3.) Mandatory Metric-TLVs with optional content ----------------------------------------------- Both Latency, Resources and Relative Link Quality are defined as=20 mandatory TLVs, but all of them specify that a certain value should be=20 transmitted if the radio cannot calculate the value. Why? If we use a TLV system and accept that a value cannot be calculated by a=20 radio, we should just make the TLV optional. Otherwise we force the=20 DLEP-implementation to lie about the value. This is especially problematic in the case of the Relative Link Quality=20 TLV, which defines the "not calculable" value as a perfect link. Which=20 means that the routing protocol suddenly optimize their paths to radios=20 which cannot measure their links. 4.) DLEP packet format ---------------------- I am still the opinion that stepping away from RFC5444 was a bad choice,=20 but we could talk for ages about this so I will focus on the new format=20 defined in DLEP-03. The current format is definitely an improvement=20 compared to the DLEP-02 "half-RFC5444" one. As a general comment I think the description of the TLV values should be=20 either everywhere in the explaining text above the TLV graphcis or=20 below. But thats cleanup work which can be done later. Section 2: This section explains how the DLEP sequence number should be done. But=20 there is neither a sequence number in the packet format, nor is it=20 mentioned somewhere else in the draft. I am not sure if the sequence=20 number is missing from the packet format description or if the=20 description in section 2 should be removed. Section 8/10: Both section 8 and Section 10 specify the basic message format, this=20 should be joined into a single section. Section 9.1: The Identification TLV is mandatory (what should happen if its missing?)=20 and must always be first in a DLEP message, right after the Signal TLV=20 header. So why don't put the ID-fields into the header without a TLV=20 around them? In addition to this it would be a good idea to increase the length of=20 Router-ID and Modem-ID to six octets each. Every DLEP-capable modem and=20 router has an ethernet device, which MAC-address can easily be used as a=20 default unique identification number (if no other number is configured). I am not even sure why the Identification is necessary at all for the=20 router. I see a reason for the Radio-ID, because a router can handle=20 multiple radios. But the way the DLEP-protocol is described, a radio can=20 only communicate with a single router. Section 9.2: The Version TLV is optional, I am not sure this makes much sense. Either=20 make it mandatory (and maybe put it into the header) or drop it completely. Section 9.7/9.8: The Maximum/Current Data Rate TLVs only allow to specify a single link=20 speed, but there are a lot of radio devices which allow for asymmetric=20 link speeds. Maybe there should be a data-value for incoming and=20 outgoing link speed in both TLVs. Section 9.10: The definition of the Latency TLV is pretty vague, especially for a=20 mandatory TLV. Section 9.13: The Status TLV says that the failure codes are message specific, but=20 these specific TLVs are nowhere in the whole draft. I would suggest=20 adding at least a "generic failure" encoding. Section 9.14: The Heartbeat TLVs Threshold should be allowed to be zero if the=20 Interval is also zero. Section 9.15: The Link Characteristics ACK Timer TLV mentions a "default value", which=20 is nowhere defined. Maybe this draft should have a "default value" section? Section 9.18: The Credit Request TLV has length zero but an UNUSED 1 octet content.=20 Either the content should be removed or the length should be 1. I would=20 suggest removing the content until there is an usage for it. Section 11: Heartbeat Interval and Heartbeat Threshold have been joined into a=20 single TLV. Also the usage of the metric values within this message (when send from=20 Router to Modem/Radio) is vague, because its unspecified how this=20 'defaults' are used by the protocol. Section 13: This section allows to not use the Status TLV, but its still defined as=20 mandatory in the list. Section 14: How does one side "determines" that the other side does not implement=20 Layer-3 address changes in Peer Updates? Section 17: What does a Peer Termination ACK with "Status: failure" mean? Section 18: This section mentions that Neighbor Up ACK Messages are required, but=20 they were declared optional in section 7. Section 19: Shouldn't the Neighbor Up ACK Message contain a Status TLV too? Section 22: The Neighbor Update Message is not ACKed at all. Does the Radio need to=20 repeat temporarily unchanging metric values from time to time to make=20 sure they were not lost? Section 23: It would be good to mention the use of Jitter for the Heartbeat Message. This section also contains the default for the "Threshold" value if no=20 Heartbeat TLV is received. This should go to a "Default Value" section. Section 24/25: The texts for "Current Data Rate" of both sections have been mixed up. ----------------------- My general feeling about the new draft is that it is a bit too vague and=20 underspecified. Even more than draft-02, it leaves a lot of things to=20 "implementation details" and "options", which create the situation that=20 we might get multiple standard compliant devices that are unable to talk=20 to each other. DLEP specifies a protocol between Radio/Modems and Routers, so we should=20 work hard on making sure that independent implementations will be=20 inter-operable. There is still a lot of work to be done. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de ******************************************************************** 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 henning.rogge@fkie.fraunhofer.de Tue Sep 4 02:42:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB54421F8501 for ; Tue, 4 Sep 2012 02:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.044 X-Spam-Level: X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3qHdqy2jQON for ; Tue, 4 Sep 2012 02:42:33 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id E40BC21F84FA for ; Tue, 4 Sep 2012 02:42:32 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T8peR-0003vj-D0; Tue, 04 Sep 2012 11:42:31 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1T8peR-0007UR-AN; Tue, 04 Sep 2012 11:42:31 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Sep 2012 11:42:31 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Sep 2012 11:42:30 +0200 Message-ID: <5045CCFE.9050907@fkie.fraunhofer.de> Date: Tue, 4 Sep 2012 11:42:22 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <5045C2F2.9010808@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060301030600050507050308" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 04 Sep 2012 09:42:31.0150 (UTC) FILETIME=[9A8600E0:01CD8A81] X-Virus-Scanned: yes (ClamAV 0.97.5/15309/Tue Sep 4 04:32:46 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8835b956789c73e36836d429bb2623bb Cc: "manet@ietf.org" , Bo Berry , Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 09:42:38 -0000 --------------ms060301030600050507050308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 09/04/2012 11:16 AM, Dearlove, Christopher (UK) wrote: > I haven't read this yet, but have just skimmed Henning's comments. > One thing jumped out at me from them, they appear to suggest > constraints on ordering of TLVs. That may be OK by me (but as I > said, not read) but a word of warning that pre-5444 had TLV ordering > constraints, and some people on the IESG really did not like this. I > could go into why pre-5444 had such constraints (which ironically, > the authors had to be argued into, then back out of) but I don't > think that would be helpful. I'd just say if you have such > constraints, I suggest having strong arguments for this, and to know > what should happen if misordered TLVs are received. The Identification TLV is the only one with a mandatory position (it is=20 mandatory and must be the first TLV), so it would be easy to solve this=20 problem by moving the value of the TLV to the message header (instead of = into an TLV). Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms060301030600050507050308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA5MDQwOTQyMjZaMCMGCSqGSIb3DQEJBDEWBBS+B7gEpZS7bv7Dm+N1n65gddMsWDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAJoO2Ohd+hQX93SiR2HnMChZpESlIAVxuK46KjBVSydCd Kvb25SXERzs4GbcyJ9SFMjNMfiop4GEaP1qii76uoKK2vkItjGuU59mP9zbxxF8L/VeNceJo E3Fuho9NlZYPT5wD5bTEBJ7UqKmCLroYd+UF0Z0m+UP225WBd/WaWRdl8AgB1EI+kiGplQ6k JevfFylaHrUFBJoRL/Q+EhZQSFm1n+dzENmBjf37XypYJbm2pe+HEwqr9zwRzMIuuw0KL3+s o2ViuA37fg2Mu8Xu7R1m1edv8VQeW6XKR64ET9P5pw70zqC8ncPGHF9I6lqDG+SL3pA+wzHc wtn4HnNB0wAAAAAAAA== --------------ms060301030600050507050308-- From abdussalambaryun@gmail.com Tue Sep 4 04:05:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD4821F84FA for ; Tue, 4 Sep 2012 04:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CVXqDWSyfOx for ; Tue, 4 Sep 2012 04:05:01 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A40721F84F8 for ; Tue, 4 Sep 2012 04:05:01 -0700 (PDT) Received: by ieak13 with SMTP id k13so5207397iea.31 for ; Tue, 04 Sep 2012 04:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Vk9VGSq5A4KE72pfuAzgUuXPBif9MniUH4GbWLhsxXc=; b=KJAvmrONHaB1Sc4psboykL8MeQxEhsYcIQDMUnwMaIKE/RlAFvGq6DxEFRvBZQynWW SWSTBTwgb5zaB44JAR7Sp0bENyZEKyMVTnAt1VWB+o5RHKTMvHMODicXB/aNsLHZdcRf 3/P2A+qMsTR3b0+53HvnwdBjK00HZbMzDfECCGk5jVw4h4CnT6o9oKhwA6M5DJ1qhNMK 2DE/7Tk9fxTl96CVnob7B+Jab1n7/0ygSF7Od7l3zLyKcTk1BAJu4FDU3+v78YYLOuBx oLNSzA9oQw+v4265M6xdku4zMVQ9Ol95ERSGM0/MPB2KWLJkrvAHDawCh/j4ARKPOh3M L5wQ== MIME-Version: 1.0 Received: by 10.50.152.243 with SMTP id vb19mr13663969igb.4.1346756700572; Tue, 04 Sep 2012 04:05:00 -0700 (PDT) Received: by 10.64.38.130 with HTTP; Tue, 4 Sep 2012 04:04:59 -0700 (PDT) In-Reply-To: <5045C2F2.9010808@fkie.fraunhofer.de> References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <5045C2F2.9010808@fkie.fraunhofer.de> Date: Tue, 4 Sep 2012 13:04:59 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org, Bo Berry , Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 11:05:02 -0000 Hi Henning, I have some comments in line, (I am still reading the draft not completed from my total comments), On 9/4/12, Henning Rogge wrote: > Hi, > > I spent time during the weekend to read through the new DLEP-03 draft a > few times. > > I see that the DLEP-03 draft has changed a lot since the last draft, so > I will try to focus both on general issues and small comments. > Especially the removal of the "Detached Peer Discovery" will safe a lot > of time on this draft, maybe we can talk about getting the "DLEP over > radio" feature (or a similar one) back as an extension draft. I had a feeling that will be the case that is why we needed to see the new draft before discussion. > > 1.) Bi-directional Discovery > ---------------------------- > > In the current draft both the Modem/Radio and the Router can be the > active or the passive component of discovery. That maybe an advantage, but suggest to be controled by the DLEP. > > I am not sure why this was even changed compared to draft 00-02. I > cannot remember anyone disagreeing with the former solution that the > Radio/Modem is the active component that sends discovery packets on its > own and that the Router will react to them. The draft-03 did not delete the option of draft-02 just added new discovery option, seem to get more complicated but may have good reasons, hope the authors comment on the reasons for this addition. > > The new specification mentions the existence of a race condition when > both discovery packets are processed at the same time, but doesn't > cleanly specifies how this should be detected and how it is resolved. > This support that your concerns to be added in next draft, > It does not mention the possibility that someone buys a Modem/Radio and > a Router which BOTH only implement the passive/reactive Discovery > method. In this case the protocol will just do nothing, even with two > standard compliant devices. agree > > > 4.) DLEP packet format > ---------------------- > > I am still the opinion that stepping away from RFC5444 was a bad choice, > but we could talk for ages about this so I will focus on the new format > defined in DLEP-03. The current format is definitely an improvement > compared to the DLEP-02 "half-RFC5444" one. I like that the draft is now focused on the DLEP functions and needed information as I suggested before, but RFC5444 packets can be a good advantage in the future either for this work or another version. > > As a general comment I think the description of the TLV values should be > either everywhere in the explaining text above the TLV graphcis or > below. But thats cleanup work which can be done later. > > Section 2: > This section explains how the DLEP sequence number should be done. But > there is neither a sequence number in the packet format, nor is it > mentioned somewhere else in the draft. I am not sure if the sequence > number is missing from the packet format description or if the > description in section 2 should be removed. > > Section 8/10: > Both section 8 and Section 10 specify the basic message format, this > should be joined into a single section. > > Section 9.1: > The Identification TLV is mandatory (what should happen if its missing?) > and must always be first in a DLEP message, right after the Signal TLV > header. So why don't put the ID-fields into the header without a TLV > around them? > > In addition to this it would be a good idea to increase the length of > Router-ID and Modem-ID to six octets each. Every DLEP-capable modem and > router has an ethernet device, which MAC-address can easily be used as a > default unique identification number (if no other number is configured). > I agree with you, but once one author mentioned that DLEP can be used in small devices so maybe reduce length is a good idea as well. > I am not even sure why the Identification is necessary at all for the > router. I see a reason for the Radio-ID, because a router can handle > multiple radios. But the way the DLEP-protocol is described, a radio can > only communicate with a single router. > I agree with you in the way this draft is presented, but I think the authors may have a good reason for this, I am not sure. > Section 9.2: > The Version TLV is optional, I am not sure this makes much sense. Either > make it mandatory (and maybe put it into the header) or drop it completel= y. > Why drop completely? it is ok to be optional, if not necessary. > ----------------------- > > My general feeling about the new draft is that it is a bit too vague and > underspecified. Even more than draft-02, it leaves a lot of things to > "implementation details" and "options", which create the situation that > we might get multiple standard compliant devices that are unable to talk > to each other. while skimming the draft I felt that alot of work was done which made it more interesting/progressing. The issue of too vague can be solved by amendments/discussions to produce the next draft. > > DLEP specifies a protocol between Radio/Modems and Routers, so we should > work hard on making sure that independent implementations will be > inter-operable. There is still a lot of work to be done. Your right and hope we get more discussions and suggestions from the group to add efforts and shorten the time spent to submit this work in 2013. Regards AB > > Henning Rogge > > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > > > From Victoria.Mercieca@cassidian.com Tue Sep 4 05:17:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8933621F84D4 for ; Tue, 4 Sep 2012 05:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYMXXvN0InTZ for ; Tue, 4 Sep 2012 05:17:46 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 02C5321F8491 for ; Tue, 4 Sep 2012 05:17:43 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet3.eads.net with ESMTP; 04 Sep 2012 14:17:40 +0200 Received: from f8562vs5.main.fr.ds.corp ([10.37.8.22]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Tue, 4 Sep 2012 14:17:39 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.28]) by f8562vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Sep 2012 14:17:39 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Sep 2012 14:17:39 +0200 Received: from SUKNPT8107.cogent-dsn.local ([10.80.1.217]) by SUKNPT8108.cogent-dsn.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Sep 2012 13:17:04 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 4 Sep 2012 13:17:03 +0100 Message-ID: <1E8A1FA2B3AB6D48ACE4562C7E83553401875FF5@SUKNPT8107.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-03.txt Thread-Index: Ac2Ke8SQS6o4YIivTYa6Ztp5XR/AfwAGxsHg References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> From: "Mercieca, Victoria" To: X-OriginalArrivalTime: 04 Sep 2012 12:17:04.0209 (UTC) FILETIME=[31B28410:01CD8A97] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-19160.007 X-TM-AS-Result: No--26.903600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: Bo Berry , Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 12:17:47 -0000 Hi all, I've also spent some time looking at the new DLEP draft and here are my thoughts. I have divided my comments into notes on DLEP functionality and notes on the document itself. DLEP functionality ---------------------------------- Section 3 - Credit windowing scheme I don't understand the credit windowing on the amount sent from radio to router. The router can surely handle data as fast as the radio can receive it? I do understand the need for router to limit its outgoing traffic to the radio. My initial thought was that the router would do this - when it creates a virtual interface per neighbour, it associates a data rate with that interface. With that technique though, I can see that a problem might occur if the router thinks it can send at 5Mbps to neighbour A and 1Mbps to neighbour B at the same time, if the radio can only send at a maximum rate of 5Mbps, so I suppose it does make sense that the radio can govern the total traffic sent to it from the router.=20 But, could it also do this by reporting differently, for example if it is currently sending at 5Mbps to one neighbour when its own MDR is 5Mbps, tell the router that it has no available bandwidth for other neighbours? Then the Link Characteristic Requests would come into play so that the router can request that the radio re-organises to allow communication to another neighbour. The router could even have this same intelligence to adjust the total rate it sends at based on the modem-wide MDR for example. Does the use of credit windowing mean that actually the reported CDR is not the CDR that can be used? Is it effectively a way of saying there's an available data rate, in which case why isn't Available Data Rate a metric which depends on actual traffic being sent, e.g. CDR on link to neighbour minus data rate in use by radio at current moment? If data is being sent across the radio, is the CDR reported affected by this anyway? I guess this depends on the radio itself and how it determines CDR. We come back to the age-old question of what exactly do our metrics mean? Section 9.4 I have a question about multicast/broadcast MAC Addresses. What happens in terms of IP addresses? Might there be multiple IP addresses associated with this MAC address or would we have a one-to-one mapping between multicast IP and multicast MAC? From section 9.5 it looks like DLEP can deal with multiple IP addresses per MAC address, but storage of multiple IP addresses is not something I've considered before. Does DLEP even care how the router stores or acts on this information? Section 9.14=20 If threshold is 0, it says to reject the TLV, but do we then use a default value for the threshold, or does this mean to reject the message entirely? If the heartbeat interval is 0, is it an issue if the threshold value is 0? Section 9.15 If no reply is received to a Link Characteristic Request in the timeout period, is the request sent again? Or does no reply mean the request has not been understood or fulfilled? If the timeout value is 0 does that mean we wait forever for a reply, how do we know when to send a request again? Section 9.16 - 9.18=20 Should the request specify how many credits it requires? Section 12=20 If you send a Peer Offer, what happens if you don't get a Peer Offer ACK? Section 14 When metrics are reported in a Peer Update, do these reflect the radio metrics or the router-modem link? If it's radio metrics, does the full set of the original 5 metrics have to be included? And does it make sense that all those metrics should be applied to all neighbours? MDR makes sense, and resources if it applies to local resources, in which case there's probably no point including it in a neighbour context.=20 If it's router-modem link metrics, MDR and CDR will probably be much higher than the values on the radio link, resources should be applied to all neighbours, latency values added to all latencies reported in neighbour context...? Section 16 The router should delete neighbours in its information base when a DLEP peer session is terminated, but a radio need not wipe this information just because the DLEP session is down, surely? The radio still knows about those neighbours and can be ready to report on them when a new DLEP session is established. Section 16/17=20 When you send a Peer Termination, do you wait for the ACK or a timeout before you delete local information about the session? If you delete it when you send the Termination, the Termination ACK is meaningless. The action is not clear. Section 17 doesn't mention freeing resources and re-entering discovery state but 16 does. Section 18=20 When a router informs the modem of a multicast Neighbour Up, I guess this doesn't contain any metrics? Should the modem reply with a Neighbour Update? I guess how it determines the metrics is out of scope of DLEP, but the Neighbour Up from the router would be the prompt for the modem to find out and report those? Section 21=20 Deleting entries in the neighbour database when a Neighbour Down is received - from the router's perspective, this might include deleting IP address information. If the neighbour comes back up, there may be delays while neighbour discovery takes place again. To avoid this sort of thing, some of the neighbour information could remain as long as the neighbour is marked as down, to save time and bandwidth in case of the neighbour re-appearing. Document structure/wording ---------------------------------------- Does DLEP stand for "Data Link Exchange Protocol" (as in introduction, page 5) or "Dynamic Link Exchange Protocol" (as in the title)? When "well-known port" is referred to, this could be clarified further by using "well-known UDP port". Figure 2 is split over two pages. Also some packet diagrams later in the document are also split over two pages. Section 2=20 Some of these paragraphs are not really assumptions (1,2,4,5,7). These paragraphs describe things which are explained in better detail later in their own sections. Section 5 - Extensions to DLEP=20 I would place this nearer the end of the document, before Section 26 for example. Section 6 In the first paragraph the last sentence looks like it's had another sentence pasted in the middle of it. Also the discovery procedure explanation is repeated in the second paragraph. I'd put this whole section before Credits (section 3 currently). For the peer session description there's a bulleted list but for neighbour removal there's numbering in the text. For consistency both should use the same. My personal preference is to have this within the text without any numbering/bullets. Section 7 Are Neighbor Up ACK and Neighbor Down ACK messages optional? Also in this section, would it be better to have one list of Mandatory Signals and a separate list of Mandatory Data Items?=20 It might be easier to understand if there was a section with a list of the full set of signals (indicated mandatory or optional) and the data items that can or must be included with each of them.=20 Also, the Identification data item is supposed to be in every message but is not shown in this section to be part of every mandatory message/signal.=20 Also this section mentions "Attached Peer Discovery". If there's no longer a Detached Peer Discovery, is the word "Attached" necessary? Personally, I'd like to see the sections 10-25 on message/signal types straight after section 8, and the sections about data items afterwards. Section 8=20 Is a DLEP packet only allowed to contain one order/signal/message? It would be clearer if the label "Signal TLV Type" was changed to "Signal Type". Also "first TLV" is not strictly a TLV. This is also referred to as "initial TLV" later in the document at multiple locations. Section 9 It might be clearer if the diagram showed "Data Item Type" instead of "TLV Type", to ensure consistency of terminology. Section 9.1 There is now some confusion / overlap between previous terminology (Packet/Message/TLV) and new terminology (Packet/Signal-Message/Data Item). Also "initial TLV" and "signal TLV" is mentioned again. Section 9.1 also says the Identification Data Item is mandatory in all messages but in Section 7 it's not listed for every signal in the mandatory set. Section 9.5 and 9.6=20 The message types that IPv4 and IPv6 addresses can be given in doesn't match the message descriptions in later sections.=20 IPv4 can be in Peer Offer (section 12), but Peer Offer is not mentioned in section 9.5.=20 Section 9.6 says that IPv6 can be in Peer Discovery (this is not mentioned in section 11), but doesn't mention that it can be in Peer Offer (but does in section 12). Since either side can now send the Peer Discovery, either side can send the Peer Offer, so are there TLVs which can be sent in either Discovery or Offer but only if sent from particular side (modem or router)?=20 Section 9.7 - 9.8, 9.10 - 9.12=20 If metrics can be given in a Peer Discovery message, surely they can be given in an offer message, since either side can send the first Peer Discovery. The modem could send the Peer Discovery or the Peer Offer, and if it needs to get the metric information to the router it might need to do this in the Peer Offer? It probably makes sense to say metrics can be used in Peer Discovery, Offer, or Update, or Neighbour Up, Update or Down messages, but only when sent by the modem? Section 9.7, 9.11 and 9.12 These sections say MDR, Resources and RLQ can be in the Link Characteristic Request ACK message, but section 25 doesn't agree.=20 Sections 9.14 and 9.15=20 These are written as if the modem sends the discovery to router. Is this text also valid for other way round, since section 6 says either side can send the discovery?=20 Section 9.16 and 9.17=20 Should "Credit Grant Request" be labelled "Credit Grant", since 9.18 is the "Credit Request"? Also it's not clear in Section 9.16 which messages/signals this can be used in. Section 9.17 Is this only sent in response to a Credit Request or can it be sent independently? It's not clear in what order these TLVs should be sent. I'm guessing first is the Credit Request (section 9.18), then Credit Grant (section 9.17), then Credit Window Status (9.16)? Would it make more sense to put the credit sections in this order? Or explain this earlier in the document? Section 10 The DLEP Message is exactly the same as the DLEP Packet in Section 8 but now shows the fields of the mandatory "Identification TLV" / "Identification Data Item" after the signal type and length fields. It seems that either Section 8 or 10 is unnecessary, unless it is intended that multiple messages/signals may appear in one DLEP Packet, though I don't think I saw this mentioned? I prefer how section 8 describes it. The packet structure is not clear now. Before, it was easy to understand:=20 1 Packet =3D 1 or more Message(s).=20 1 Message =3D 1 or more TLV(s). Now there's extra terms Signal and Data Item, but it seems like 1 (Packet / Signal / Message) =3D 1 or more (Data item / TLV). Also if this is clarified, the explanation of packet structure in section 1 on page 6 should be checked too. There's a difference in document structure here. Section 9 showed DLEP data items overview, then 9.1-9.18 showed the data items. Now, section 10 is the DLEP message/packet format (which is probably unnecessary if section 8 remains), 10.1 is Signal Values overview, so it would make sense for 10.2-10.x to be the descriptions of signal types. Instead we have sections 11-25 for the message types. I would have the current 10.1 being 10, then current 11-25 being 10.1-15. Section 10.1 - Would be easier to follow if this said "Signal Types" instead of "Signal TLV Values". I'd suggest to refer to the type as "Signal Type" or "Message Type" not "initial TLV Type Value". The constants like DLEP_ATTACHED_PEER_DISCOVERY could be included in the overview in section 10.1. e.g.=20 Signal Type Signal Description =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D DLEP_ATTACHED_PEER_DISCOVERY (TBD) Peer Discovery DLEP_PEER_OFFER (TBD) Peer Offer etc... Section 11 This says the Peer Offer is required to complete the discovery process, however, in section 6 it says that the Peer Offer ACK is required to finish the discovery process.=20 It also mentions "packet format described in section 11" - does it mean Section 10 or Section 8? I'd say use section 8 since section 11 then says the ID TLV is first, and section 10 says "this header structure is assumed, and will not be replicated".=20 Also, why mention the Peer Offer so early in the Peer Discovery section? Focus should be on the Peer Discovery in this section.=20 Section 11 - 25 There's inconsistency in section structure. Section 11 gave "Mandatory Data Item TLVs" list but section 12 doesn't. Same comment applies to later sections too. Again "initial TLV type value" is used. I suggest using "Signal Type" or "Signal Type field".=20 Section 11 and 12 Would metrics be present in the Peer Discovery and Peer Offer only if these were sent by the modem? Section 11 says a Peer Discovery from a peer in session should force processing as if a Peer Termination had been received (does this include sending Peer Termination ACK?) and then says it MAY process the Peer Discovery message, but section 12 says it should act like a Peer Termination was received and does not mention processing the new discovery message. Which is correct? For both these sections I'd recommend moving the explanation of "in session" and subsequent discovery/offer messages to either the end of the Peer Discovery / Peer Offer section respectively, or the Peer Offer ACK section. Section 12 Why mention the Peer Offer ACK before explaining the Peer Offer?=20 Section 13=20 This says "implementations that do NOT support the Status data item", however the status data item is listed as mandatory in section 7 and also later in this section. Section 14=20 The Peer Update can be sent from either side. Are the data items listed valid only for certain directions? E.g. can the router send metrics? This could be clarified in the list of optional data items. Also for the Peer Update message containing metrics, are there certain metrics which MUST be included or are they all optional? For a Peer Update from the modem to the router, it does not say if an ACK is required. Section 15 seems to indicate it is. Section 18=20 Just echoing the earlier point that the Neighbour Up ACK is not given as mandatory in section 7. Section 20=20 This says mandatory TLVs are Identification and MAC address, and that the others listed are optional. Then it says that Status TLV is mandatory and there are no optional TLVs for this message. Section 21 Echoing the earlier point that Neighbour Down ACK is not given as mandatory in section 7. Also this section says "As with the Neighbour Down message, there are NO OPTIONAL Data Item TLVs" - this may need adjusting if Section 20 changes. Section 22 For consistency with other sections, I'd suggest not to use a bullet list for examples of changes. Also we need consistency with other sections in listing mandatory / optional Data Item TLVs. Section 24 The first part of this section says the Link Characteristic Request message is for requesting changes, then later in the section we find out it has another use. Both uses should be mentioned in the first paragraph.=20 Second paragraph says the message contains either CDR, Latency, or both, then a bit later says it can send without either too. Suggest rewriting to make the 4 options clearer from the start.=20 Section 25=20 When this section mentions "a complete set of metric data item TLVs", does it mean the 5 mandatory ones or the complete set including EFT and any experimental ones? The mandatory / optional sections below only show CDR and Latency. Section 27.6 When it mentions multicast address, does this mean IPv4 / IPv6 / Ethernet / all of the above? Appendix A=20 There is no mention of the Peer Discovery ACK, especially in Section 30.1.3. Neighbor Sessions are mentioned in Sections 30.1.4, 30.2.1, 30.2.2, 30.2.3, 30.2.4, 30.2.5, and 30.2.6. The Heartbeat Timeout in Section 30.1.5 and 30.1.6 doesn't mention the heartbeat threshold from Section 9.14. They still mention neighbour sessions too.=20 Are there any retries on the Termination message? Do we expect an ACK at all? Should neighbour info be deleted AFTER an ACK is received or a certain timeout after the Termination is sent, or when the Termination is sent? Section 30.1.8 is the same procedure as 30.1.7, so these could be condensed into one section. There's no message flow to show what happens if the Peer Termination ACK is lost. There's no message flow describing the router sending a Neighbour Up message about multicast destination. Section 30.2.6 is about neighbour sessions and is probably unnecessary. Victoria Mercieca From henning.rogge@fkie.fraunhofer.de Tue Sep 4 06:18:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C3C21F8568 for ; Tue, 4 Sep 2012 06:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=3.103, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUCg-BeYY8LV for ; Tue, 4 Sep 2012 06:18:10 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id D565821F8574 for ; Tue, 4 Sep 2012 06:18:09 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T8t0k-0000OX-5e; Tue, 04 Sep 2012 15:17:46 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1T8t0k-0005Bo-2x; Tue, 04 Sep 2012 15:17:46 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Sep 2012 15:17:45 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Sep 2012 15:17:45 +0200 Message-ID: <5045FF72.6070101@fkie.fraunhofer.de> Date: Tue, 4 Sep 2012 15:17:38 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <1E8A1FA2B3AB6D48ACE4562C7E83553401875FF5@SUKNPT8107.cogent-dsn.local> In-Reply-To: <1E8A1FA2B3AB6D48ACE4562C7E83553401875FF5@SUKNPT8107.cogent-dsn.local> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010703070103080507020707" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 04 Sep 2012 13:17:45.0904 (UTC) FILETIME=[AC511300:01CD8A9F] X-Virus-Scanned: yes (ClamAV 0.97.5/15310/Tue Sep 4 12:41:15 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c7f8db32b27897ddd5dcaf8162788e46 Cc: Stan Ratliff , Bo Berry , "Mercieca, Victoria" Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 13:18:11 -0000 --------------ms010703070103080507020707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 09/04/2012 02:17 PM, Mercieca, Victoria wrote: > Hi all, > > I've also spent some time looking at the new DLEP draft and here are > my thoughts. I have divided my comments into notes on DLEP > functionality and notes on the document itself. Hi, triggered by your comment about the credit window system of DLEP I got another question. If I understand DLEP right it handles a credit window per neighbor. How do we handle the common usecase where we have a radio with a "sender window", which means we have credits for sending data, but not to a specified receiver. Lets say our radio (because of some TDMA waveform) has an outgoing credit window of 1000 bytes. Do we set the credit window of every neighbor to 1000 bytes? This would mean we might get 1000 bytes for every neighbor, which is too much. Do we distribute the 1000 bytes among our neighbors? This would prevent any outgoing traffic to use the full 1000 bytes. I think this should be considered before we build a Credit Window Scheme = into DLEP that is not applicable for this use case. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms010703070103080507020707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA5MDQxMzE3NDNaMCMGCSqGSIb3DQEJBDEWBBTuvmyQ/+DaQGkgkIYWY0uShsovpDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAEvUIYmOuj1VpOv67pALLVhLDURsvWbNlIKuNkCMmSCZY TLp8Z4wmMSJcfyXNWZakWCjOCYma125epMc1KVXWC7DrqCjA7GJNgSHBDBE9cz253rOoI8cU FLc0KWfOPZkIIZRdPeMNZoxupeCn60/MGFRIK/3McyehoXy0yw9BpVXqrhI9gK5fG00ax1BQ 9kh6dldCPnX4NsB0BHdpoVK6k/v/KnUSYIljIr/JTf31vwwoluPaZbRIJ8go4MQ3+svEHlCO /JFmT6auIL3GeLF2OeE7iiSJbkxDjB4RMx3eD+wjK9BVGOsT81+gl7iBTRKIBaKIJNA03W7W SRVqmjcU7AAAAAAAAA== --------------ms010703070103080507020707-- From abdussalambaryun@gmail.com Tue Sep 4 06:19:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4F121F8643 for ; Tue, 4 Sep 2012 06:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTjy+cNkNwFI for ; Tue, 4 Sep 2012 06:19:35 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49FF321F8568 for ; Tue, 4 Sep 2012 06:19:35 -0700 (PDT) Received: by iabz21 with SMTP id z21so10088071iab.31 for ; Tue, 04 Sep 2012 06:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nPKAtKmrV6lpRpld4DdXo5brh8XELHAHvbpJUt/dknc=; b=tt3qc/FlxP3B9gjDJIpVYJgMXs3Zj2/ipQhBeDxCLMSO3X95qvVD2qWXiZZZGUVskH q4Cw6QJSr1dNCU4L2+0KPgmHGwRbJoLK2PrfpIfqVJ5Nr8RPp/8qIp2UceBf6+0OKv3z UbK0kpWxO76pvDKNYbhKwWzqXqLhmt4ZwnV/ey85LrudtXIe1+OIE4OXUSKz00ad8h6e DjCePL/ck21ulap8Hxh9S1PYIzqdfna93XLatR25hSQ5BultZ6AWEduDOk1csrE201cJ 0ck0yt+1zuzij+FWF6PuwkyIBri2OD5Hj5gpuvANjoPx9cvOllkZDLyJ4NcCJxMsKPi8 JXyQ== MIME-Version: 1.0 Received: by 10.50.193.201 with SMTP id hq9mr13735939igc.48.1346764774762; Tue, 04 Sep 2012 06:19:34 -0700 (PDT) Received: by 10.64.38.130 with HTTP; Tue, 4 Sep 2012 06:19:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Sep 2012 15:19:34 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Request to update MANET-WG-Milestones X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 13:19:35 -0000 The below milestones don't include AODVv2 (or DYMO) please update to include this IETF WG draft replacing the "Reactive Protocol". I suggest AODVv2 to be submitted to IESG in this year 2012 because it seems ready, I recommend to add some other missing WG I-D to the milestones, as NHDP-Sec. +++++++++++++++++++++++++++++++++++ Jul 2012 Submit OLSRv2 to IESG Jul 2012 Submit NHDP MIB to IESG Nov 2012 Submit OLSRv2 MIB to IESG Nov 2012 Submit SMF MIB to IESG Mar 2013 Submit REPORT MIB to IESG Mar 2013 Submit DLEP to IESG Apr 2013 Submit Reactive Protocol to IESG ++++++++++++++++++++++++++++++++++++ Regards AB From sratliff@cisco.com Tue Sep 4 06:37:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9442221F862A for ; Tue, 4 Sep 2012 06:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u19YQtZ0fUS1 for ; Tue, 4 Sep 2012 06:37:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7C10021F851E for ; Tue, 4 Sep 2012 06:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2328; q=dns/txt; s=iport; t=1346765820; x=1347975420; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TmAkE3MMjwoD81h6D1t+cR+u+Ebp1DQ+/3/KYHjfa04=; b=koagpl/VgFp5NTdsnv7xhby2/r8TuVCmWR89JDgOncRAJnGyswUM5kRO urm4ukX1KrkXW0DdF0xcnDaL8BvialQ5qWy0aks7kF1PRrIdgu1N2EtVU Oi7/+HwwB0ozde+LAVq/4SjVLTFF88vLsUrzjVxsPUvmnFtU7Fd/b2V88 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAK0DRlCtJV2Z/2dsb2JhbABFuyqBB4IgAQEBAwESAWYFCwIBCBgnBzIUEQIEDgUih2UGmlOfcYsNhlJgA4gbjT6OM4FngmM X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="118096240" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 04 Sep 2012 13:37:00 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q84Dax7X017558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 13:37:00 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 08:36:58 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-03.txt Thread-Index: AQHNhuPxMHWnCTLQC0uhnhcOGhBZKgAGxsHgl3pPIgCAAAVmgA== Date: Tue, 4 Sep 2012 13:36:57 +0000 Message-ID: <6DD9D294-8F0C-416A-8C01-D3BADD9928A8@cisco.com> References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <1E8A1FA2B3AB6D48ACE4562C7E83553401875FF5@SUKNPT8107.cogent-dsn.local> <5045FF72.6070101@fkie.fraunhofer.de> In-Reply-To: <5045FF72.6070101@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19160.005 x-tm-as-result: No--36.173400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <36326BF05F2A4A4E8F7B6F19FB8A571A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Bo Berry \(boberry\)" , "Mercieca, Victoria" Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 13:37:04 -0000 On Sep 4, 2012, at 9:17 AM, Henning Rogge wrote: > On 09/04/2012 02:17 PM, Mercieca, Victoria wrote: >> Hi all, >>=20 >> I've also spent some time looking at the new DLEP draft and here are >> my thoughts. I have divided my comments into notes on DLEP >> functionality and notes on the document itself. >=20 > Hi, >=20 > triggered by your comment about the credit window system of DLEP I got > another question. >=20 > If I understand DLEP right it handles a credit window per neighbor. How > do we handle the common usecase where we have a radio with a "sender > window", which means we have credits for sending data, but not to a > specified receiver. I've never seen, nor dealt with, such a device, and we have the credit wind= owing of RFC4938/RFC5578 deployed with multiple radios. What you imply is = a credit scheme that would exist from router to modem, and the 03 DLEP spec= ifically precludes that.=20 >=20 > Lets say our radio (because of some TDMA waveform) has an outgoing > credit window of 1000 bytes. Sorry, but I can't envision a TDMA radio that doesn't have a "specified rec= eiver". After all, isn't that the point of TDMA? That being, that *someone*= "out there" is listening at the time you're sending? Now, there could be a= broadcast/multicast slot, but that would be handled in DLEP by using the c= orrect MAC address (e.g. for the broadcast/multicast) and creating a neighb= or. Regards, Stan >=20 > Do we set the credit window of every neighbor to 1000 bytes? This would > mean we might get 1000 bytes for every neighbor, which is too much. >=20 > Do we distribute the 1000 bytes among our neighbors? This would prevent > any outgoing traffic to use the full 1000 bytes. >=20 > I think this should be considered before we build a Credit Window Scheme = into DLEP that is not applicable for this use case. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >=20 From abdussalambaryun@gmail.com Tue Sep 4 06:40:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DB521F862A for ; Tue, 4 Sep 2012 06:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZDHY9VxOSKm for ; Tue, 4 Sep 2012 06:40:05 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF3B21F851E for ; Tue, 4 Sep 2012 06:40:05 -0700 (PDT) Received: by ieak13 with SMTP id k13so5536556iea.31 for ; Tue, 04 Sep 2012 06:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B0OAkDpyRCOwhkHriZfggl+Xtib0ZKRaLgk3XU39hhg=; b=ueGkTBMa2irOl6+/d0kP8P/X+bzte7twmqrUbFNqYkV73vN9+D3dWpLX+0BN8Pu3zZ P6937S/w8C2ZJ7v/oQICMlx4G56SfXdycurrPgu/LMRXAlI3UX4ouJE7ZiTRnpMRjNKH Q6/clrLmhJwsKE2F7gzEq3BjvuAqYCGNJc3FhUnDlamAZ8aG0RRScdtsl2jXuUUMHFdU P9VO2DadPMHb7s02ARuOCCusgA/7lK+0dHIYBd1zFmYvDsYBZixGPmtdFNbLrq7l85Z1 EI4ckWY3F1pDgnUpmbltI0TyUHXR1XxH3dD+PdtvDfsgnxir4ScAsS8K4ebyD+bu+4bT SmMg== MIME-Version: 1.0 Received: by 10.50.213.106 with SMTP id nr10mr13691403igc.58.1346765996013; Tue, 04 Sep 2012 06:39:56 -0700 (PDT) Received: by 10.64.38.130 with HTTP; Tue, 4 Sep 2012 06:39:55 -0700 (PDT) In-Reply-To: References: <4FB1E35F.6000903@computer.org> Date: Tue, 4 Sep 2012 15:39:55 +0200 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Comments For AODVv2 (manet-dymo-22) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 13:40:08 -0000 Hi Charlie, In the WG IETF 84 meeting, the discussion I understood that a comment mentioned that dymo was parked and there is a need for a reactive protocol to be worked on. Is there possibility that AODVv2 be submitted to IESG this year 2012 or did the authors decided to postpone? I think it is ready, not sure if the WG discussed this issue at Vancouver (nothing on the list so far), Best Regards AB From sratliff@cisco.com Tue Sep 4 06:58:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B27B21F852A for ; Tue, 4 Sep 2012 06:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f63tnvpbFHMR for ; Tue, 4 Sep 2012 06:58:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0858021F850C for ; Tue, 4 Sep 2012 06:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=9728; q=dns/txt; s=iport; t=1346767083; x=1347976683; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iwS9Z+H6QjhkQ5DoM4oc1ItT5ZD85Y5BC18cceQrQLE=; b=ewuwH7fV930HK4TE865qPLSky/vIh05yrtJl1Ond//4ctBOvqL+b5mL0 eBy8zAokoCUY1mQKiR2eb43MWh+k0eR3KqztU7/PbyO5q+zTvQ8IE+JIW pheWZkvxtnoZ03bCAYpSetg1EfXBZlRYImxVyYK9kb/m3ikeZ5lqAuMhR Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOwHRlCtJXG+/2dsb2JhbABFuyqBB4IgAQEBAwESAWYFCwIBCD8HMhQRAgQOBRsHh2UGmmKfcYsNhlJgA5VZjjOBZ4JjgVgj X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="118070301" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 04 Sep 2012 13:58:02 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q84Dw26n028553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 13:58:02 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 08:58:02 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-03.txt Thread-Index: AQHNhuPxMHWnCTLQC0uhnhcOGhBZKpd6PTkAgABTaIA= Date: Tue, 4 Sep 2012 13:58:01 +0000 Message-ID: References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <5045C2F2.9010808@fkie.fraunhofer.de> In-Reply-To: <5045C2F2.9010808@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19160.005 x-tm-as-result: No--46.930600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Bo Berry \(boberry\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 13:58:04 -0000 Henning,=20 Thanks for the review. We're going over it now, but it may take a day or tw= o=85 one comment inline:=20 On Sep 4, 2012, at 4:59 AM, Henning Rogge wrote: > Hi, >=20 > I spent time during the weekend to read through the new DLEP-03 draft a f= ew times. >=20 > I see that the DLEP-03 draft has changed a lot since the last draft, so I= will try to focus both on general issues and small comments. Especially th= e removal of the "Detached Peer Discovery" will safe a lot of time on this = draft, maybe we can talk about getting the "DLEP over radio" feature (or a = similar one) back as an extension draft. >=20 > I also think we should work on standardizing more optional metric values = (otherwise interoperability for additional metrics will be difficult), but = that can be done at a later time. >=20 > Here are my comments: >=20 >=20 > 1.) Bi-directional Discovery > ---------------------------- >=20 > In the current draft both the Modem/Radio and the Router can be the activ= e or the passive component of discovery. >=20 > I am not sure why this was even changed compared to draft 00-02. I cannot= remember anyone disagreeing with the former solution that the Radio/Modem = is the active component that sends discovery packets on its own and that th= e Router will react to them. >=20 > The new specification mentions the existence of a race condition when bot= h discovery packets are processed at the same time, but doesn't cleanly spe= cifies how this should be detected and how it is resolved. >=20 > It does not mention the possibility that someone buys a Modem/Radio and a= Router which BOTH only implement the passive/reactive Discovery method. In= this case the protocol will just do nothing, even with two standard compli= ant devices. >=20 >=20 > 2.) Semi-optional Acknowledgement Mechanism > ------------------------------------------- >=20 > DLEP-03 makes half of the Acknowledgment messages of DLEP-02 optional (th= e one for neighbor up/down message). But it still doesn't specify how their= are handled, except by a few rough examples in an appendix. >=20 > Is one of the peers allowed to send further messages before the last one = was acknowledged? What is happening if a message is not acknowledged by the= other side? >=20 > There is also a strange situation if the sender of a message expects an A= CK but the receiver does not support them. Does the receiver somehow recogn= ize the duplicate messages (if yes, how?) and do they need to be dropped? >=20 > The flow diagrams 30.2.1 and 30.2.2 suggest that Neighbor Updates are onl= y sent by the Modem after receiving a Neighbor Up ACK message. Which would = make tranfering metric data between an ACK-enabled radio and router without= ACK support impossible. >=20 >=20 > 3.) Mandatory Metric-TLVs with optional content > ----------------------------------------------- >=20 > Both Latency, Resources and Relative Link Quality are defined as mandator= y TLVs, but all of them specify that a certain value should be transmitted = if the radio cannot calculate the value. >=20 > Why? >=20 > If we use a TLV system and accept that a value cannot be calculated by a = radio, we should just make the TLV optional. Otherwise we force the DLEP-im= plementation to lie about the value. >=20 > This is especially problematic in the case of the Relative Link Quality T= LV, which defines the "not calculable" value as a perfect link. Which means= that the routing protocol suddenly optimize their paths to radios which ca= nnot measure their links. Not true. Or at least not true in all cases. It depends on *how* the routin= g protocol optimizes, which as we've said, is outside the scope of this doc= ument. For example, assume a routing protocol algorithm that "incrementally= penalizes" radio links for "less than perfect" metric values. For those ty= pes of algorithms, defaulting RLQ as "perfect link" simply means "don't pen= alize the link because the modem can't calculate the value". That being sai= d, I don't have an issue with making RLQ optional.=20 Regards, Stan >=20 >=20 > 4.) DLEP packet format > ---------------------- >=20 > I am still the opinion that stepping away from RFC5444 was a bad choice, = but we could talk for ages about this so I will focus on the new format def= ined in DLEP-03. The current format is definitely an improvement compared t= o the DLEP-02 "half-RFC5444" one. >=20 > As a general comment I think the description of the TLV values should be = either everywhere in the explaining text above the TLV graphcis or below. B= ut thats cleanup work which can be done later. >=20 > Section 2: > This section explains how the DLEP sequence number should be done. But th= ere is neither a sequence number in the packet format, nor is it mentioned = somewhere else in the draft. I am not sure if the sequence number is missin= g from the packet format description or if the description in section 2 sho= uld be removed. >=20 > Section 8/10: > Both section 8 and Section 10 specify the basic message format, this shou= ld be joined into a single section. >=20 > Section 9.1: > The Identification TLV is mandatory (what should happen if its missing?) = and must always be first in a DLEP message, right after the Signal TLV head= er. So why don't put the ID-fields into the header without a TLV around the= m? >=20 > In addition to this it would be a good idea to increase the length of Rou= ter-ID and Modem-ID to six octets each. Every DLEP-capable modem and router= has an ethernet device, which MAC-address can easily be used as a default = unique identification number (if no other number is configured). >=20 > I am not even sure why the Identification is necessary at all for the rou= ter. I see a reason for the Radio-ID, because a router can handle multiple = radios. But the way the DLEP-protocol is described, a radio can only commun= icate with a single router. >=20 > Section 9.2: > The Version TLV is optional, I am not sure this makes much sense. Either = make it mandatory (and maybe put it into the header) or drop it completely. >=20 > Section 9.7/9.8: > The Maximum/Current Data Rate TLVs only allow to specify a single link sp= eed, but there are a lot of radio devices which allow for asymmetric link s= peeds. Maybe there should be a data-value for incoming and outgoing link sp= eed in both TLVs. >=20 > Section 9.10: > The definition of the Latency TLV is pretty vague, especially for a manda= tory TLV. >=20 > Section 9.13: > The Status TLV says that the failure codes are message specific, but thes= e specific TLVs are nowhere in the whole draft. I would suggest adding at l= east a "generic failure" encoding. >=20 > Section 9.14: > The Heartbeat TLVs Threshold should be allowed to be zero if the Interval= is also zero. >=20 > Section 9.15: > The Link Characteristics ACK Timer TLV mentions a "default value", which = is nowhere defined. Maybe this draft should have a "default value" section? >=20 > Section 9.18: > The Credit Request TLV has length zero but an UNUSED 1 octet content. Eit= her the content should be removed or the length should be 1. I would sugges= t removing the content until there is an usage for it. >=20 > Section 11: > Heartbeat Interval and Heartbeat Threshold have been joined into a single= TLV. >=20 > Also the usage of the metric values within this message (when send from R= outer to Modem/Radio) is vague, because its unspecified how this 'defaults'= are used by the protocol. >=20 > Section 13: > This section allows to not use the Status TLV, but its still defined as m= andatory in the list. >=20 > Section 14: > How does one side "determines" that the other side does not implement Lay= er-3 address changes in Peer Updates? >=20 > Section 17: > What does a Peer Termination ACK with "Status: failure" mean? >=20 > Section 18: > This section mentions that Neighbor Up ACK Messages are required, but the= y were declared optional in section 7. >=20 > Section 19: > Shouldn't the Neighbor Up ACK Message contain a Status TLV too? >=20 > Section 22: > The Neighbor Update Message is not ACKed at all. Does the Radio need to r= epeat temporarily unchanging metric values from time to time to make sure t= hey were not lost? >=20 > Section 23: > It would be good to mention the use of Jitter for the Heartbeat Message. >=20 > This section also contains the default for the "Threshold" value if no He= artbeat TLV is received. This should go to a "Default Value" section. >=20 > Section 24/25: > The texts for "Current Data Rate" of both sections have been mixed up. >=20 >=20 > ----------------------- >=20 > My general feeling about the new draft is that it is a bit too vague and = underspecified. Even more than draft-02, it leaves a lot of things to "impl= ementation details" and "options", which create the situation that we might= get multiple standard compliant devices that are unable to talk to each ot= her. >=20 > DLEP specifies a protocol between Radio/Modems and Routers, so we should = work hard on making sure that independent implementations will be inter-ope= rable. There is still a lot of work to be done. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 >=20 From henning.rogge@fkie.fraunhofer.de Tue Sep 4 07:12:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1614B11E808A for ; Tue, 4 Sep 2012 07:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.18 X-Spam-Level: X-Spam-Status: No, score=-4.18 tagged_above=-999 required=5 tests=[AWL=2.068, BAD_CREDIT=0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBaaGvKm5UVv for ; Tue, 4 Sep 2012 07:12:45 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id E57F321F8471 for ; Tue, 4 Sep 2012 07:12:44 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T8tra-00024g-Eb; Tue, 04 Sep 2012 16:12:22 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1T8tra-0006j6-Bt; Tue, 04 Sep 2012 16:12:22 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Sep 2012 16:12:22 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Sep 2012 16:12:21 +0200 Message-ID: <50460C44.3070003@fkie.fraunhofer.de> Date: Tue, 4 Sep 2012 16:12:20 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <1E8A1FA2B3AB6D48ACE4562C7E83553401875FF5@SUKNPT8107.cogent-dsn.local> <5045FF72.6070101@fkie.fraunhofer.de> <6DD9D294-8F0C-416A-8C01-D3BADD9928A8@cisco.com> In-Reply-To: <6DD9D294-8F0C-416A-8C01-D3BADD9928A8@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050902070007030605030006" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 04 Sep 2012 14:12:22.0231 (UTC) FILETIME=[4D28E670:01CD8AA7] X-Virus-Scanned: yes (ClamAV 0.97.5/15310/Tue Sep 4 12:41:15 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 90edfc314e3c23e7293fd49106c104bf Cc: "" , "Bo Berry \(boberry\)" , "Mercieca, Victoria" Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 14:12:46 -0000 --------------ms050902070007030605030006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Am 04.09.2012 15:36, schrieb Stan Ratliff (sratliff): >> If I understand DLEP right it handles a credit window per neighbor. >> How do we handle the common usecase where we have a radio with a >> "sender window", which means we have credits for sending data, but >> not to a specified receiver. > > I've never seen, nor dealt with, such a device, I have seen a few of them... and a co-worker from our SDR research group = told me that both concepts ("allocating transmission time" vs.=20 "allocating link") exists. > and we have the > credit windowing of RFC4938/RFC5578 deployed with multiple radios. I don't say these devices do not exist, I just say they are not the only = use case for the credit window system. > What you imply is a credit scheme that would exist from router to > modem, and the 03 DLEP specifically precludes that. No, I am not. >> Lets say our radio (because of some TDMA waveform) has an outgoing >> credit window of 1000 bytes. > > Sorry, but I can't envision a TDMA radio that doesn't have a > "specified receiver". After all, isn't that the point of TDMA? The main point of TDMA is that no one else is transmitting when I want=20 to transmit. It guarantees me a collision free transmission. If the TDMA protocol distinguishs between unicast slots to different=20 targets or is just used for this transmission time allocation would be=20 implementation specific. I also would like to use DLEP together with consumer technologies like=20 WLAN and the credit scheme could be used to prevent the router from=20 overflowing the buffer on the WLAN-radio device. In this case I also=20 have no different credit windows for each destination, I have only a=20 single "outgoing queue" on the radio. > That > being, that *someone* "out there" is listening at the time you're > sending? Now, there could be a broadcast/multicast slot, but that > would be handled in DLEP by using the correct MAC address (e.g. for > the broadcast/multicast) and creating a neighbor. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms050902070007030605030006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA5MDQxNDEyMjBaMCMGCSqGSIb3DQEJBDEWBBTh25FI5lHEL0mkYd5zBo1SyJWRDDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAhuhR3L+I1w+s1KMX7cDSqzeZ4I49m5+K/NDpx0vjX/gH 8FR5cvcgNmcnXHSG0qgUO9FoDiLQGiOT63q+96OhJqaQd2CCSpOYlhkJOnuQ0WnbE+ScN+kl clJgIH9Y9JTkHWcwb+By++GNFzmaIPkt+Z9f5EljFBfb3cUbxEifEDxKvmVm6ebZJ18fn5Nh AEnkmQcGFpWGvNW41UxvZ4Qv4Tj9gWT8lmMkVlfGCP26NVxgAxhzEZpaFDUYAmMWkQYU5W8f 4t0MGchBicG5jDH3YxvdBUgNMnjq+44TP7RSK8LropIWhooggZTLED1chntD4/vPgDxbQRQL h05OjgBeKQAAAAAAAA== --------------ms050902070007030605030006-- From sratliff@cisco.com Tue Sep 4 10:54:17 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30D811E809A for ; Tue, 4 Sep 2012 10:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAD_CREDIT=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PSYohvTrgr6 for ; Tue, 4 Sep 2012 10:54:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 076E921F849D for ; Tue, 4 Sep 2012 10:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3306; q=dns/txt; s=iport; t=1346781255; x=1347990855; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=McBIeCBJGHZFpdDz/LrjXrNqwoEm8/5G6/+HlzPg/yU=; b=WJqvuGp0ZkfaCjmRbhT88r5jX5EeaaKS9A20BZGjIcLjFiyauh83lFwX P72pruIWC+7RKd5B7h4ADhuzda9O7tJhA0GKKhRY1H+dk8ynmRd0GWy5g k1etfKFn3NFafE5vcOUancGIfov7Tcs4EUKZzVf7QhGpZlj/JiiaCMHIO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHI/RlCtJV2c/2dsb2JhbABFuyKBB4IgAQEBAwESAWYFCwIBCD8HMhQRAgQOBSKHZQaaVqAFiwmGUmADlVmOM4FngmM X-IronPort-AV: E=Sophos;i="4.80,368,1344211200"; d="scan'208";a="115145112" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 04 Sep 2012 17:54:14 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q84HsEQD026160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 17:54:14 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Tue, 4 Sep 2012 12:54:14 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-03.txt Thread-Index: AQHNhuPxMHWnCTLQC0uhnhcOGhBZKgAGxsHgl3pPIgCAAAVmgIAACeMAgAA9/oA= Date: Tue, 4 Sep 2012 17:54:13 +0000 Message-ID: <29145501-82A2-400F-8381-C3AE4A81F492@cisco.com> References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <1E8A1FA2B3AB6D48ACE4562C7E83553401875FF5@SUKNPT8107.cogent-dsn.local> <5045FF72.6070101@fkie.fraunhofer.de> <6DD9D294-8F0C-416A-8C01-D3BADD9928A8@cisco.com> <50460C44.3070003@fkie.fraunhofer.de> In-Reply-To: <50460C44.3070003@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19160.005 x-tm-as-result: No--51.618300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Bo Berry \(boberry\)" , "Mercieca, Victoria" Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:54:17 -0000 On Sep 4, 2012, at 10:12 AM, Henning Rogge wrote: > Am 04.09.2012 15:36, schrieb Stan Ratliff (sratliff): >>> If I understand DLEP right it handles a credit window per neighbor. >>> How do we handle the common usecase where we have a radio with a >>> "sender window", which means we have credits for sending data, but >>> not to a specified receiver. >>=20 >> I've never seen, nor dealt with, such a device, >=20 > I have seen a few of them... and a co-worker from our SDR research group = told me that both concepts ("allocating transmission time" vs. "allocating = link") exists. >=20 > > and we have the >> credit windowing of RFC4938/RFC5578 deployed with multiple radios. >=20 > I don't say these devices do not exist, I just say they are not the only = use case for the credit window system. Then describe the use case - as of this point, I still haven't heard it (or= understood it).=20 >=20 >> What you imply is a credit scheme that would exist from router to >> modem, and the 03 DLEP specifically precludes that. >=20 > No, I am not. >=20 >>> Lets say our radio (because of some TDMA waveform) has an outgoing >>> credit window of 1000 bytes. >>=20 >> Sorry, but I can't envision a TDMA radio that doesn't have a >> "specified receiver". After all, isn't that the point of TDMA? >=20 > The main point of TDMA is that no one else is transmitting when I want to= transmit. It guarantees me a collision free transmission. Ahhh, I see. So as long as I transmit successfully, it doesn't matter that = no one hears it=85 good to know. >=20 > If the TDMA protocol distinguishs between unicast slots to different targ= ets or is just used for this transmission time allocation would be implemen= tation specific. >=20 > I also would like to use DLEP together with consumer technologies like WL= AN and the credit scheme could be used to prevent the router from overflowi= ng the buffer on the WLAN-radio device. In this case I also have no differe= nt credit windows for each destination, I have only a single "outgoing queu= e" on the radio. Which directly contradicts your earlier statement. You *do* imply a credit = scheme at the router/modem level. That's the scheme represented by the sing= le "outgoing queue" on the radio. Implicit in that single outgoing queue is= a single rate for traffic to be emitted towards the radio. So essentially,= I'd argue that's no different than what we have today - a radio attached t= o a router's interface, with the appropriate bandwidth set at the router.=20 Stan >=20 > > That >> being, that *someone* "out there" is listening at the time you're >> sending? Now, there could be a broadcast/multicast slot, but that >> would be handled in DLEP by using the correct MAC address (e.g. for >> the broadcast/multicast) and creating a neighbor. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >=20 From teco@inf-net.nl Tue Sep 4 22:15:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359E311E80BA for ; Tue, 4 Sep 2012 22:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[BAD_CREDIT=0.001, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7373ZFw7Ao3 for ; Tue, 4 Sep 2012 22:15:02 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 880A421F865D for ; Tue, 4 Sep 2012 22:15:01 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so78971wgb.13 for ; Tue, 04 Sep 2012 22:15:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=l9yQd5KlnC3Ts26Rol40p8CrXYxl544H5DjekYerT5s=; b=gG2OsZcxOMfO3r6CxjO3xbLYnvrgHDjzfxAUQVM51gxAWVQmI3960uNC34MUDGsIrC x1kIdihtwyWpwcEGoXNtOSr6ZY7DrgOnNtPOax2+5cF7E3fxGKAsWyDJsn7IYZ0Illl8 NXbE2KxQSar9xNTHkIV2OwFM0xzyK0SHYt6FNyH7/lM0ia+qNCD733ShEnq+sIUkaFa6 FxCbn7wsmvFzEFwT/Y2+Gx7zXp2kGtsIW/ES5fi4UxiNufJUkWMbX1BQtND2PNhMddDz 0zl0/49xSXK4Gzbphhv5VfXe7Vmmb6hgkHWqt6jPGftoYp3dSTvmKU/xuINpeRI8a98k CXNA== Received: by 10.180.81.193 with SMTP id c1mr35278496wiy.12.1346822100636; Tue, 04 Sep 2012 22:15:00 -0700 (PDT) Received: from [10.87.29.43] ([80.187.201.33]) by mx.google.com with ESMTPS id o2sm1337927wiz.11.2012.09.04.22.14.58 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 22:15:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <50460C44.3070003@fkie.fraunhofer.de> Date: Tue, 4 Sep 2012 17:17:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <1E8A1FA2B3AB6D48ACE4562C7E83553401875FF5@SUKNPT8107.cogent-dsn.local> <5045FF72.6070101@fkie.fraunhofer.de> <6DD9D294-8F0C-416A-8C01-D3BADD9928A8@cisco.com> <50460C44.3070003@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQm5b4vNNn2FEi/zYm7lowCpCI8rmxJpXCWzqLetFlTVtz6hMx9IK9ZVNh+KGAkwFsY/e5eU Cc: "" , "Mercieca, Victoria" , "Bo Berry \(boberry\)" , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 05:15:03 -0000 Op 4 sep. 2012, om 16:12 heeft Henning Rogge het volgende geschreven: >=20 > I also would like to use DLEP together with consumer technologies like = WLAN and the credit scheme could be used to prevent the router from = overflowing the buffer on the WLAN-radio device. In this case I also = have no different credit windows for each destination, I have only a = single "outgoing queue" on the radio. Current consumer WLAN gear should have MME. I expect the more advanced = stuff has something better. I don't get how DLEP credit windowing can = support this. Bufferbloat research showed overflowing the buffers gets harder and = harder, as memory gets cheaper and cheaper. So we face the task to = implement advanced packet dispatching on the bottleneck. Which is in the = radio/modem. IMHO transfer of the bottleneck to a router is not the = preferred solution. I know not everybody does agree here. Teco= From teco@inf-net.nl Tue Sep 4 22:15:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F3921E8053 for ; Tue, 4 Sep 2012 22:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.102 X-Spam-Level: X-Spam-Status: No, score=-3.102 tagged_above=-999 required=5 tests=[AWL=0.496, BAD_CREDIT=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGfMy-i2dfqM for ; Tue, 4 Sep 2012 22:15:08 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9AC21E8044 for ; Tue, 4 Sep 2012 22:15:08 -0700 (PDT) Received: by weyu54 with SMTP id u54so89331wey.31 for ; Tue, 04 Sep 2012 22:15:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=r4OJwnJFkR3Qih/r/b7X6d0y9CXZVDJaxhX6LZfzMno=; b=DB1D9tFV9jgzdc/yFzUf8Wx2dEV6yb8NWBYtUlMCIlLkVBo2ZDs5pxU5MPj5pgj9rX 67dN5kbhlE/lnjFYqZAbz95Dl+KK9qhlRKN9SW+1XT8cN1bl4Lvhopk1Ce1UgIGWlXOG L0MgxUyDs39bM46mxF1jv7hTJj6P+kNrMBrX0p2+B8AvT+6iqtmU9b558rWwEhqlinX5 3U5+NAIom8PUolWz3uEoHKue3usIt/MpfivE2JaJ13TwoGsqKjw6pRsFP7VOQoTVWj2N CLoMzeOn4vQ4mV6ZdaJd5prwDTjtuYD9FbEsQesdl617cGCbG4NIg4S3KVnA2UxwxpXL fl/w== Received: by 10.216.137.32 with SMTP id x32mr7714751wei.95.1346822107515; Tue, 04 Sep 2012 22:15:07 -0700 (PDT) Received: from [10.87.29.43] ([80.187.201.33]) by mx.google.com with ESMTPS id o2sm1337927wiz.11.2012.09.04.22.15.05 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 22:15:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <29145501-82A2-400F-8381-C3AE4A81F492@cisco.com> Date: Wed, 5 Sep 2012 07:05:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <237E2FEA-5752-46C3-AFC7-42331D4123CD@inf-net.nl> References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <1E8A1FA2B3AB6D48ACE4562C7E83553401875FF5@SUKNPT8107.cogent-dsn.local> <5045FF72.6070101@fkie.fraunhofer.de> <6DD9D294-8F0C-416A-8C01-D3BADD9928A8@cisco.com> <50460C44.3070003@fkie.fraunhofer.de> <29145501-82A2-400F-8381-C3AE4A81F492@cisco.com> To: Stan Ratliff (sratliff) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnDDEh2VyMBjXFxL4XMMvga/Ww/rxXRs97JYWWIlPeGRMWmcZmdAXPgu8U0doOZb6iMIAId Cc: "" , "Bo Berry \(boberry\)" , "Mercieca, Victoria" Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 05:15:10 -0000 Op 4 sep. 2012, om 19:54 heeft Stan Ratliff (sratliff) het volgende = geschreven: >=20 > On Sep 4, 2012, at 10:12 AM, Henning Rogge wrote: >=20 >> Am 04.09.2012 15:36, schrieb Stan Ratliff (sratliff): >>>> If I understand DLEP right it handles a credit window per neighbor. >>>> How do we handle the common usecase where we have a radio with a >>>> "sender window", which means we have credits for sending data, but >>>> not to a specified receiver. >>>=20 >>> I've never seen, nor dealt with, such a device, >>=20 >> I have seen a few of them... and a co-worker from our SDR research = group told me that both concepts ("allocating transmission time" vs. = "allocating link") exists. >>=20 >>> and we have the >>> credit windowing of RFC4938/RFC5578 deployed with multiple radios. >>=20 >> I don't say these devices do not exist, I just say they are not the = only use case for the credit window system. >=20 > Then describe the use case - as of this point, I still haven't heard = it (or understood it).=20 >=20 >>=20 >>> What you imply is a credit scheme that would exist from router to >>> modem, and the 03 DLEP specifically precludes that. >>=20 >> No, I am not. >>=20 >>>> Lets say our radio (because of some TDMA waveform) has an outgoing >>>> credit window of 1000 bytes. >>>=20 >>> Sorry, but I can't envision a TDMA radio that doesn't have a >>> "specified receiver". After all, isn't that the point of TDMA? >>=20 >> The main point of TDMA is that no one else is transmitting when I = want to transmit. It guarantees me a collision free transmission. >=20 > Ahhh, I see. So as long as I transmit successfully, it doesn't matter = that no one hears it=85 good to know. >=20 >>=20 >> If the TDMA protocol distinguishs between unicast slots to different = targets or is just used for this transmission time allocation would be = implementation specific. >>=20 >> I also would like to use DLEP together with consumer technologies = like WLAN and the credit scheme could be used to prevent the router from = overflowing the buffer on the WLAN-radio device. In this case I also = have no different credit windows for each destination, I have only a = single "outgoing queue" on the radio. >=20 > Which directly contradicts your earlier statement. You *do* imply a = credit scheme at the router/modem level. That's the scheme represented = by the single "outgoing queue" on the radio. Implicit in that single = outgoing queue is a single rate for traffic to be emitted towards the = radio. So essentially, I'd argue that's no different than what we have = today - a radio attached to a router's interface, with the appropriate = bandwidth set at the router.=20 Where does the single rate idea come from? WLAN media access is far more complex than single queue single rate. Teco=20 > Stan >=20 >=20 >>=20 >>> That >>> being, that *someone* "out there" is listening at the time you're >>> sending? Now, there could be a broadcast/multicast slot, but that >>> would be handled in DLEP by using the correct MAC address (e.g. for >>> the broadcast/multicast) and creating a neighbor. >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Wed Sep 5 04:36:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E6D21F865C for ; Wed, 5 Sep 2012 04:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6t27rpRWnVW for ; Wed, 5 Sep 2012 04:36:21 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id B44FD21F8658 for ; Wed, 5 Sep 2012 04:36:20 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T9Du3-0006Ub-6P; Wed, 05 Sep 2012 13:36:15 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1T9Du3-0002Bf-3l; Wed, 05 Sep 2012 13:36:15 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Sep 2012 13:36:14 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 5 Sep 2012 13:36:14 +0200 Message-ID: <50473926.5000808@fkie.fraunhofer.de> Date: Wed, 5 Sep 2012 13:36:06 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <1E8A1FA2B3AB6D48ACE4562C7E83553401875FF5@SUKNPT8107.cogent-dsn.local> <5045FF72.6070101@fkie.fraunhofer.de> <6DD9D294-8F0C-416A-8C01-D3BADD9928A8@cisco.com> <50460C44.3070003@fkie.fraunhofer.de> <29145501-82A2-400F-8381-C3AE4A81F492@cisco.com> In-Reply-To: <29145501-82A2-400F-8381-C3AE4A81F492@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000608040004030808010301" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 05 Sep 2012 11:36:14.0938 (UTC) FILETIME=[A83B2BA0:01CD8B5A] X-Virus-Scanned: yes (ClamAV 0.97.5/15315/Wed Sep 5 03:59:27 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ff5b53f4d81aecd7a6b2d230e03a1f9e Cc: "" , "Bo Berry \(boberry\)" , "Mercieca, Victoria" Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 11:36:22 -0000 --------------ms000608040004030808010301 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Am 04.09.2012 19:54, schrieb Stan Ratliff (sratliff): > Then describe the use case - as of this point, I still haven't heard > it (or understood it). > > Which directly contradicts your earlier statement. You *do* imply a > credit scheme at the router/modem level. That's the scheme > represented by the single "outgoing queue" on the radio. Implicit in > that single outgoing queue is a single rate for traffic to be emitted > towards the radio. So essentially, I'd argue that's no different than > what we have today - a radio attached to a router's interface, with > the appropriate bandwidth set at the router. The problem with your approach is the Shared Medium access on the radio. = Even if we assume a fixed radio link speed (which might be heavily=20 depend on the destination of the packet), there is no way to predict how = long it will take until the radio gets access to the medium. Without information when its packets have been sent over the radio, the=20 router doesn't know if it can sent further data over the ethernet link=20 or if its just stored in the outgoing queue on the radio. This is similar to the Bufferbloat problem. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms000608040004030808010301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA5MDUxMTM2MTJaMCMGCSqGSIb3DQEJBDEWBBR6Qgfgrb1O53tEapta3pt7HYt39jBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAvENzX8R2v4WGV3R0pfRXPNEt9Y5Fzt95lE+82mZdl9bT yLV+9fG7Rc8FtEICl9VobfpuZo4st3lkjeo4VWt0RGsGUJN3RWdAo5oza3itqnmOwNO1+0fb K5hyD41dq18ZW3Lld/q0JsYWPSahjzSpja3X58qLo/hjXrPIAo4Hoi+R7djNmKfJIk/TaluA FZd48qg6Ev1dUEDACoUeaqIrSh7b2meaKOs97ThwEUasylU8s9+hh7KyXeH0QP7R9oycHoMs EIRzfhR2VKM305IwjTDSm4Xb5ehQ74AJBo0zKisf4bmXrpQOLdArHbty9hdeT4wRGxdq5XiA X6LI5eNVzgAAAAAAAA== --------------ms000608040004030808010301-- From henning.rogge@fkie.fraunhofer.de Wed Sep 5 06:06:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D581121F8554 for ; Wed, 5 Sep 2012 06:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.517 X-Spam-Level: X-Spam-Status: No, score=-4.517 tagged_above=-999 required=5 tests=[AWL=1.732, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C1qSUnzip1p for ; Wed, 5 Sep 2012 06:06:25 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id D93F721F855A for ; Wed, 5 Sep 2012 06:06:24 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T9FIv-0001u9-Ux; Wed, 05 Sep 2012 15:06:01 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1T9FIv-0004Zt-SK; Wed, 05 Sep 2012 15:06:01 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Sep 2012 15:06:01 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 5 Sep 2012 15:06:01 +0200 Message-ID: <50474E32.5040403@fkie.fraunhofer.de> Date: Wed, 5 Sep 2012 15:05:54 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <20120830191552.13391.77341.idtracker@ietfa.amsl.com> <5045C2F2.9010808@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010408000204090908000001" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 05 Sep 2012 13:06:01.0691 (UTC) FILETIME=[32FC72B0:01CD8B67] X-Virus-Scanned: yes (ClamAV 0.97.5/15315/Wed Sep 5 03:59:27 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 63d11b563531d75ada9d42d73b6da78e Cc: "" , "Bo Berry \(boberry\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:06:32 -0000 --------------ms010408000204090908000001 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Am 04.09.2012 15:58, schrieb Stan Ratliff (sratliff): >> 3.) Mandatory Metric-TLVs with optional content >> ----------------------------------------------- >> >> Both Latency, Resources and Relative Link Quality are defined as >> mandatory TLVs, but all of them specify that a certain value should >> be transmitted if the radio cannot calculate the value. >> >> Why? >> >> If we use a TLV system and accept that a value cannot be calculated >> by a radio, we should just make the TLV optional. Otherwise we >> force the DLEP-implementation to lie about the value. >> >> This is especially problematic in the case of the Relative Link >> Quality TLV, which defines the "not calculable" value as a perfect >> link. Which means that the routing protocol suddenly optimize their >> paths to radios which cannot measure their links. > > Not true. Or at least not true in all cases. It depends on *how* the > routing protocol optimizes, which as we've said, is outside the scope > of this document. For example, assume a routing protocol algorithm > that "incrementally penalizes" radio links for "less than perfect" > metric values. For those types of algorithms, defaulting RLQ as > "perfect link" simply means "don't penalize the link because the > modem can't calculate the value". > That being said, I don't have an issue with making RLQ optional. Making Latency, Resources and RLQ optional would resolve the whole issue = I explained in my section 3. My issue was primarily that we are hiding=20 this "cannot calculate" state in an encoding that could also be a valid=20 data value. The current defaults could be still suggested as "the router MIGHT use=20 this value if TLV not exist" in the document, to keep the current=20 behaviour unless the router software is designed otherwise. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms010408000204090908000001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA5MDUxMzA1NTlaMCMGCSqGSIb3DQEJBDEWBBQk2NfidvlXkiElXOlnNBhMMwhZuDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAHHE4TDTJ8+kuGWcoQiERFqloFD2MZtVMgyMJGzeEgTV+ D4U6HDo1x1CFr4XcTZ2LivFHPBGiePg6bkXcLk3ZqiVsK3tStilFElfwGTw0R8IfhBGMmQrw Hh2Bg0dfgGjy4/M4qF0WMFrYAidHcCVfh2gb/ZNBoCkF14AREEaNFNrcz6Qj9wRb8H3nQJcq 2GYL36aSo4tNVogg18X6qW4UgYhWdHFpAIP5pAmEAM6kGHGGkRFb6mxbke4RURF4MdcherKt OHDMEIWoMRQPtA5Nl2OByjnxm4wM3poZ+o3b1NVZ33s3xjENfxYGsT4aQZor8Qe48HFsYdst +6OWHVXqxAAAAAAAAA== --------------ms010408000204090908000001-- From ietf@thomasclausen.org Wed Sep 5 08:04:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E94421F846D for ; Wed, 5 Sep 2012 08:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qi4i0Wz3R1DM for ; Wed, 5 Sep 2012 08:04:46 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id BDE9821F8468 for ; Wed, 5 Sep 2012 08:04:46 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 9D21D5583DC for ; Wed, 5 Sep 2012 08:04:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 763C21BD107E for ; Wed, 5 Sep 2012 08:04:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.6.148] (ip-64-134-96-189.public.wayport.net [64.134.96.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id F09F41BD1077 for ; Wed, 5 Sep 2012 08:04:43 -0700 (PDT) From: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=Apple-Mail-EC3CBCC3-407F-4574-B811-BEFB0095B6C0 X-Mailer: iPad Mail (9B206) Message-Id: <1D327B91-44C5-490C-842B-102FFDF7E62A@thomasclausen.org> Date: Wed, 5 Sep 2012 11:04:44 -0400 To: manet Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:04:47 -0000 --Apple-Mail-EC3CBCC3-407F-4574-B811-BEFB0095B6C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, As you know, http://tools.ietf.org/html/draft-dearlove-olsrv2-metrics-06 wa= s presented at the IETF'84 [MANET] meeting, and has been adopted by the WG a= s http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-00. T= he slides of the presentation from IETF'84 are, starting from page 9, here: h= ttp://www.ietf.org/proceedings/84/slides/slides-84-manet-2.pdf As a reminder, this document is derived from the document (already discussed= by the WG since 2007, as draft-dearlove-olsrv2-metrics) which originally de= scribed how to integrate metrics into OLSRv2, and for which consensus was es= tablished resulting in the metrics design of OLSRv2. =20 While OLSRv2 describes *how* metrics were integrated, draft-ietf-manet-olsrv= 2-metrics-rationale presents the *why* - the design rationale, and is intend= ed as publication as an Informational RFC. =20 The authors would like to see a WGLC of this document some time between now a= nd the next IETF.=20 We'd therefore like to ask the WG to review and give feedback so that we may= spin a new version soon. Respectfully, Thomas, Chris and Philippe --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees --Apple-Mail-EC3CBCC3-407F-4574-B811-BEFB0095B6C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Dear all,

As you know,  http://tools.ietf.org/html/draft-dearlove-olsrv2-me= trics-06 was presented at the IETF'84 [MANET] meeting, and has been= adopted by the WG as ht= tp://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-00. T= he slides of the presentation from IETF'84 are, starting from page 9, here:&= nbsp;h= ttp://www.ietf.org/proceedings/84/slides/slides-84-manet-2.pdf


As a reminder, this document is derived from the do= cument (already discussed by the WG since 2007, as draft-dearlove-olsrv2-met= rics) which originally described how to integrate metrics into OLSRv2, and f= or which consensus was established resulting in the metrics design of OLSRv2= .

 

While OLSRv2 de= scribes *how* metrics were integrated, draft-ietf-manet-olsrv2-metrics-ratio= nale presents the *why* - the design rationale, and is intended as publicati= on as an Informational RFC.

=  

The authors w= ould like to see a WGLC of this docume= nt some time between now and the next IETF. 


We'd there= fore like to ask the WG to review and give feedback so that we may spin= a new version soon.



Respectfully,


Thomas, Chris and= Philippe


-- 
Thomas Heide Cla= usen

"Any simple problem can be made insol= uble if enough meetings are held to
 discuss it."
&= nbsp;  -- Mitchell's Law of Committees
= --Apple-Mail-EC3CBCC3-407F-4574-B811-BEFB0095B6C0-- From sratliff@cisco.com Wed Sep 5 09:31:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F7321F84CE for ; Wed, 5 Sep 2012 09:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNKoS04V4ypE for ; Wed, 5 Sep 2012 09:31:42 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3F54E21F8685 for ; Wed, 5 Sep 2012 09:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7816; q=dns/txt; s=iport; t=1346862702; x=1348072302; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ErZ45Zp9TFNXWMBKhWD+CpQ7UQ1vLhBgi4idVSxD8Dg=; b=J5kHcUuJbJirAA61YM0hwn31s+MeLxS8ewlR0l09azXLRxKt2YUN76I+ em6UK97e6rupd8/L4oZj5FQh3dSbEyb8owQWB/r4HfZes+1LGhhjHoO98 uRFQyqY5OnFq2NjlhHD14dC9/1bicM8X2t5b1xU3u4hHcylTfOqlshYfh A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHx9R1CtJV2a/2dsb2JhbABFskcBiFyBB4IhAQECAgEBAQ8BFkULEAIBAgY/BycLFBECBA4FCRmHawuaTKAxixGGImADlVmBFI0fgWeCYw X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208,217";a="118559378" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 05 Sep 2012 16:31:39 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q85GVdEI018132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Sep 2012 16:31:39 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 11:31:39 -0500 From: "Stan Ratliff (sratliff)" To: Thomas Heide Clausen Thread-Topic: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale Thread-Index: AQHNi3fNwYzLC7DtLEyl6JwTPqbOiZd8RLoA Importance: high X-Priority: 1 Date: Wed, 5 Sep 2012 16:31:38 +0000 Message-ID: <328900A6-0B2F-40EE-9B02-104A6FD783C7@cisco.com> References: <1D327B91-44C5-490C-842B-102FFDF7E62A@thomasclausen.org> In-Reply-To: <1D327B91-44C5-490C-842B-102FFDF7E62A@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19164.001 x-tm-as-result: No--40.162000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_328900A60B2F40EE9B02104A6FD783C7ciscocom_" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:31:43 -0000 --_000_328900A60B2F40EE9B02104A6FD783C7ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Please find some time to review and comment on this doc, so that we may mov= e it along the path. Regards, Stan On Sep 5, 2012, at 11:04 AM, Thomas Heide Clausen wrote: Dear all, As you know, http://tools.ietf.org/html/draft-dearlove-olsrv2-metrics-06 w= as presented at the IETF'84 [MANET] meeting, and has been adopted by the WG= as http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-00= . The slides of the presentation from IETF'84 are, starting from page 9, he= re: http://www.ietf.org/proceedings/84/slides/slides-84-manet-2.pdf As a reminder, this document is derived from the document (already discusse= d by the WG since 2007, as draft-dearlove-olsrv2-metrics) which originally = described how to integrate metrics into OLSRv2, and for which consensus was= established resulting in the metrics design of OLSRv2. While OLSRv2 describes *how* metrics were integrated, draft-ietf-manet-olsr= v2-metrics-rationale presents the *why* - the design rationale, and is inte= nded as publication as an Informational RFC. The authors would like to see a WGLC of this document some time between now= and the next IETF. We'd therefore like to ask the WG to review and give feedback so that we ma= y spin a new version soon. Respectfully, Thomas, Chris and Philippe -- Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_328900A60B2F40EE9B02104A6FD783C7ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Folks, 

Please find some time to review and comment on this doc, so that we ma= y move it along the path.

Regards,
Stan

On Sep 5, 2012, at 11:04 AM, Thomas Heide Clausen wrote:

Dear all,

As you know,  http://tools.ietf.or= g/html/draft-dearlove-olsrv2-metrics-06 was presented at the IETF'= 84 [MANET] meeting, and has been adopted by the WG as http://tools.ie= tf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-00. The slides of= the presentation from IETF'84 are, starting from page 9, here: http://www.ietf.org/proceedings/84/slides/slides-84-ma= net-2.pdf

As a reminder, this document is derived from the document (already discusse= d by the WG since 2007, as draft-dearlove-olsrv2-metrics) which originally = described how to integrate metrics into OLSRv2, and for which consensus was= established resulting in the metrics design of OLSRv2.

 
The authors would like to see a WGLC of this document some time between now and the next IETF. =

We'd therefore like to ask the WG to = review and give feedback so that we may spin a new version soon.


Respectfully,

Thomas, Chris and Philippe

-- 
Thomas Heide Clausen

"Any simple problem can be made insoluble if enough meetings are held to
 discuss it."
   -- Mitchell's Law of Committees
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_328900A60B2F40EE9B02104A6FD783C7ciscocom_-- From ulrich@herberg.name Wed Sep 5 10:57:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BC421F8497 for ; Wed, 5 Sep 2012 10:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYANrXlbY2VP for ; Wed, 5 Sep 2012 10:57:29 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3C4821F84DE for ; Wed, 5 Sep 2012 10:57:29 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so430804vbb.31 for ; Wed, 05 Sep 2012 10:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g8BKgcEOg99LBU2vzfIc8R6oBVPQwtTKRVCMxZJ2KDo=; b=Kk7PR+qL5qWexFD5C7Mloe9JTkqCsvT5cWF/Q4isUR3XYYvAYd1vY3DWNzj8rNXSvL uIZfs+FoioSfZDjWotCc4oTfiUbGblD23uhxEcswPi98bWww4Uf6/pnup9JgUz5bZ8TN kodv9NwEyPWDxqUiQeIDrWrOJB6BSQMH9OD34= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=g8BKgcEOg99LBU2vzfIc8R6oBVPQwtTKRVCMxZJ2KDo=; b=GI1g68wRvizAGyoT1DvB1im8BpBz6re2dCgyg2ZAvdgsMyGGMVt9CBb5qk0C8cQn7a pVMfpBs9UMSTGSH0K4oPs204YLM0yHs1xst9UL+aJ2BB0+sX5kILdIe+EcGs9GSPev3k AqRWCZVDccOGnhzHvoRHD4sDftaDSiRyJR2T5wxrwMzZF3iVHhUK/dU9kLuSgYKz0n9p odmGsvQ5O5+NI8y3niyGC7Kcq+ip/c6aNL19O+d/hXPn6u0U6QrYqQ9rD+FX7FszAgjt HcnhwGtFTmbmRZFjypSfvRoNue61gWHYEv/WsPAOLK7J9s3JCP3BwB7SK60FF8BYsOlf NiUw== MIME-Version: 1.0 Received: by 10.221.10.148 with SMTP id pa20mr3341081vcb.26.1346867848882; Wed, 05 Sep 2012 10:57:28 -0700 (PDT) Received: by 10.58.187.78 with HTTP; Wed, 5 Sep 2012 10:57:28 -0700 (PDT) In-Reply-To: <328900A6-0B2F-40EE-9B02-104A6FD783C7@cisco.com> References: <1D327B91-44C5-490C-842B-102FFDF7E62A@thomasclausen.org> <328900A6-0B2F-40EE-9B02-104A6FD783C7@cisco.com> Date: Wed, 5 Sep 2012 10:57:28 -0700 Message-ID: From: Ulrich Herberg To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkzWHw1wdEadmPw/XF6VQQJBHqTYZG4SVJJIGlB6sShCpmUFaOYxPtGI7CRpxin9R044zuw Cc: manet Subject: Re: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 17:57:30 -0000 Hi, I have read the draft and think it is of high quality and value, and therefore I support to move forward. Some nits: - terminology: MANET *I*nterface vs. OLSRv2 *i*nterface (lower case) - section 4: "When the network topology is changing, and with possibly lossy messages"; rather "lossy channel" or "in cases where messages can be lost (frequently)" - section 5.2: "This does not directly take into account delays due to routers, rather than links, but these can be divided among incoming and outgoing links." Maybe it could be helpful to add an example what is meant by "delays due to routers". I assume that this could be internal processing of messages, handing over packets from one layer to the next etc. - bandwidth section: "high", "medium" and low" ; missing " before low The end of that section is a little hard to read (with the question in the parentheses "(and at times maybe better,...", and missing full stop after the sentence). - Section 5.5: there seems to be some redundancy between the first paragraph: "When a router reports a 1-hop neighbor in a HELLO message it may do so for the first time with link status HEARD. The receiving router will then immediately consider the link to be symmetric and thus will use it." and the beginning of the third paragraph: "Thus a router must be able to immediately decide on an incoming link metric once it has heard a 1-hop neighbor on an OLSRv2 interface for the first time. This is because, on receiving a HELLO message from this router, that 1-hop neighbor will (unless link quality indicates otherwise) immediately consider the link to be symmetric and use it." Also the latter paragraph, it is not quite clear to me that it will only add the neighbor as SYMMETRIC, if it finds one of its addresses advertised in the HELLO (with status other than LOST). Also, it is unclear what "and *use* it" means. Use it for what? - In that same section: "It will probably be best to...". Is that an implementation advice? - section 5.6: "this produced a 2"; produced or produces? - same section: "using normal network octet ordering (high first)". I think there was a better description in NHDP or OLSRv2 than "high first" ("most significant bits first" or something like like). - I will do a more thorough review of the rest during WGLC, but in general I like the proposed text, and believe it is useful for the community. Best Ulrich On Wed, Sep 5, 2012 at 9:31 AM, Stan Ratliff (sratliff) wrote: > Folks, > > Please find some time to review and comment on this doc, so that we may move > it along the path. > > Regards, > Stan > > On Sep 5, 2012, at 11:04 AM, Thomas Heide Clausen wrote: > > Dear all, > > As you know, http://tools.ietf.org/html/draft-dearlove-olsrv2-metrics-06 > was presented at the IETF'84 [MANET] meeting, and has been adopted by the WG > as http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-00. > The slides of the presentation from IETF'84 are, starting from page 9, here: > http://www.ietf.org/proceedings/84/slides/slides-84-manet-2.pdf > > As a reminder, this document is derived from the document (already discussed > by the WG since 2007, as draft-dearlove-olsrv2-metrics) which originally > described how to integrate metrics into OLSRv2, and for which consensus was > established resulting in the metrics design of OLSRv2. > > While OLSRv2 describes *how* metrics were integrated, > draft-ietf-manet-olsrv2-metrics-rationale presents the *why* - the design > rationale, and is intended as publication as an Informational RFC. > > The authors would like to see a WGLC of this document some time between now > and the next IETF. > > We'd therefore like to ask the WG to review and give feedback so that we may > spin a new version soon. > > > Respectfully, > > Thomas, Chris and Philippe > > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ > > "Any simple problem can be made insoluble if enough meetings are held to > discuss it." > -- Mitchell's Law of Committees > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From ietf@thomasclausen.org Wed Sep 5 11:06:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3927B21F86BD for ; Wed, 5 Sep 2012 11:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LzW3jOJLG3J for ; Wed, 5 Sep 2012 11:06:24 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 797B621F86BB for ; Wed, 5 Sep 2012 11:06:24 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 39189558839 for ; Wed, 5 Sep 2012 11:06:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9FD7E1C0362F; Wed, 5 Sep 2012 11:06:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.6.148] (ip-64-134-96-189.public.wayport.net [64.134.96.189]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 21B181C03449; Wed, 5 Sep 2012 11:06:22 -0700 (PDT) References: <1D327B91-44C5-490C-842B-102FFDF7E62A@thomasclausen.org> <328900A6-0B2F-40EE-9B02-104A6FD783C7@cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Wed, 5 Sep 2012 14:06:22 -0400 To: Ulrich Herberg Cc: manet , "Stan Ratliff \(sratliff\)" Subject: Re: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 18:06:25 -0000 Dear Ulrich, Thank you for your prompt review. We will consider your feedback, most of which seems easy enough to address, i= n a coming revision. This email just to acknowledge receipt of your comments= . Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 5 Sep 2012, at 13:57, Ulrich Herberg wrote: > Hi, >=20 > I have read the draft and think it is of high quality and value, and > therefore I support to move forward. >=20 > Some nits: > - terminology: MANET *I*nterface vs. OLSRv2 *i*nterface (lower case) > - section 4: "When the network topology is changing, and with > possibly lossy messages"; rather "lossy channel" or "in cases where > messages can be lost (frequently)" > - section 5.2: "This does not directly take into account delays due to > routers, rather than links, but these can be divided among > incoming and outgoing links." > Maybe it could be helpful to add an example what is meant by "delays > due to routers". I assume that this could be internal processing of > messages, handing over packets from one layer to the next etc. > - bandwidth section: "high", "medium" and low" ; missing " before low > The end of that section is a little hard to read (with the question > in the parentheses "(and at times maybe better,...", and missing full > stop after the sentence). > - Section 5.5: there seems to be some redundancy between the first > paragraph: "When a router reports a 1-hop neighbor in a HELLO message > it may do so for the first time with link status HEARD. The > receiving router > will then immediately consider the link to be symmetric and thus will > use it." > and the beginning of the third paragraph: > "Thus a router must be able to immediately decide on an incoming link > metric once it has heard a 1-hop neighbor on an OLSRv2 interface for > the first time. This is because, on receiving a HELLO message from > this router, that 1-hop neighbor will (unless link quality indicates > otherwise) immediately consider the link to be symmetric and use it." >=20 > Also the latter paragraph, it is not quite clear to me that it will > only add the neighbor as SYMMETRIC, if it finds one of its addresses > advertised in the HELLO (with status other than LOST). Also, it is > unclear what "and *use* it" means. Use it for what? >=20 > - In that same section: "It will probably be best to...". Is that an > implementation advice? >=20 > - section 5.6: "this produced a 2"; produced or produces? > - same section: "using normal network octet ordering (high first)". I > think there was a better description in NHDP or OLSRv2 than "high > first" ("most significant bits first" or something like like). > - I will do a more thorough review of the rest during WGLC, but in > general I like the proposed text, and believe it is useful for the > community. >=20 > Best > Ulrich >=20 >=20 >=20 > On Wed, Sep 5, 2012 at 9:31 AM, Stan Ratliff (sratliff) > wrote: >> Folks, >>=20 >> Please find some time to review and comment on this doc, so that we may m= ove >> it along the path. >>=20 >> Regards, >> Stan >>=20 >> On Sep 5, 2012, at 11:04 AM, Thomas Heide Clausen wrote: >>=20 >> Dear all, >>=20 >> As you know, http://tools.ietf.org/html/draft-dearlove-olsrv2-metrics-06= >> was presented at the IETF'84 [MANET] meeting, and has been adopted by the= WG >> as http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-0= 0. >> The slides of the presentation from IETF'84 are, starting from page 9, he= re: >> http://www.ietf.org/proceedings/84/slides/slides-84-manet-2.pdf >>=20 >> As a reminder, this document is derived from the document (already discus= sed >> by the WG since 2007, as draft-dearlove-olsrv2-metrics) which originally >> described how to integrate metrics into OLSRv2, and for which consensus w= as >> established resulting in the metrics design of OLSRv2. >>=20 >> While OLSRv2 describes *how* metrics were integrated, >> draft-ietf-manet-olsrv2-metrics-rationale presents the *why* - the design= >> rationale, and is intended as publication as an Informational RFC. >>=20 >> The authors would like to see a WGLC of this document some time between n= ow >> and the next IETF. >>=20 >> We'd therefore like to ask the WG to review and give feedback so that we m= ay >> spin a new version soon. >>=20 >>=20 >> Respectfully, >>=20 >> Thomas, Chris and Philippe >>=20 >> -- >> Thomas Heide Clausen >> http://www.thomasclausen.org/ >>=20 >> "Any simple problem can be made insoluble if enough meetings are held to >> discuss it." >> -- Mitchell's Law of Committees >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 From abdussalambaryun@gmail.com Thu Sep 6 12:19:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4268221F86DF for ; Thu, 6 Sep 2012 12:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79pFHX8isqSh for ; Thu, 6 Sep 2012 12:19:31 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41C3221F86D8 for ; Thu, 6 Sep 2012 12:19:31 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3131550vcb.31 for ; Thu, 06 Sep 2012 12:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QTcKoyyyrFz3pfWcBl9KxmS2VbE+L5iHBsIfaSdNWKw=; b=AAw5mJNUQZUCo6KVRt/zcVRDgnp76m2G2ovX0tK/lKFt2TMFrDtXud2yQ4hfHlKTIb 9fOWQAcAFFAbvMZXpoh4UZgMuE+myBNicSHZIU6CVKeGxo+x29TaaS366Ndvf2yGzACt F5qJNm7gCBNicIHztoO4FM7b8yu98W0ggjlbqvV3eLkh7CUqLQVItxo6Xp73U5huGkKR QeMkyq1ufQGCh+vpIQdgkqwVcfQL7bm0Y7UiaMAJ2NndhZjh2FfWmxGgvm324C8xanMX mDwUoO3jmB5MW5u9ZumQgL0wWEjUg3ji22xqDV+JNcsVs4/yYbSEnLbBsPO7fbdo+jSB yOcQ== MIME-Version: 1.0 Received: by 10.58.89.168 with SMTP id bp8mr4236150veb.20.1346959170688; Thu, 06 Sep 2012 12:19:30 -0700 (PDT) Received: by 10.220.2.83 with HTTP; Thu, 6 Sep 2012 12:19:30 -0700 (PDT) In-Reply-To: <1D327B91-44C5-490C-842B-102FFDF7E62A@thomasclausen.org> References: <1D327B91-44C5-490C-842B-102FFDF7E62A@thomasclausen.org> Date: Thu, 6 Sep 2012 20:19:30 +0100 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=047d7b33c750e5575804c90d5e6e Cc: manet Subject: Re: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 19:19:32 -0000 --047d7b33c750e5575804c90d5e6e Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, I commented before on the work metric-06 [*], with no reply on the list, even in the meeting 84 there was no comment on what was in the list (which I recommend to be done in future) related to such document. My comment on the new WG draft (rationale-00) is that the draft is excellent, and I support to WGLC, I will try to find time to overview and comment (minor suggestion), [*] http://www.ietf.org/mail-archive/web/manet/current/msg13204.html AB === On Wed, Sep 5, 2012 at 4:04 PM, Thomas Heide Clausen wrote: > Dear all, > > As you know, http://tools.ietf.org/html/draft-dearlove-olsrv2-metrics-06 was > presented at the IETF'84 [MANET] meeting, and has been adopted by the WG as > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-00. > The slides of the presentation from IETF'84 are, starting from page 9, > here: http://www.ietf.org/proceedings/84/slides/slides-84-manet-2.pdf**** > > > As a reminder, this document is derived from the document (already > discussed by the WG since 2007, as draft-dearlove-olsrv2-metrics) which > originally described how to integrate metrics into OLSRv2, and for which > consensus was established resulting in the metrics design of OLSRv2.**** > > > While OLSRv2 describes *how* metrics were integrated, > draft-ietf-manet-olsrv2-metrics-rationale presents the *why* - the design > rationale, and is intended as publication as an Informational RFC. > > **** > > ** ** > > The authors would like to see a WGLC of this document some time between > now and the next IETF. **** > > > **** > > We'd therefore like to ask the WG to review and give feedback so that we > may spin a new version soon.**** > > > > **** > > Respectfully, > > > **** > > Thomas, Chris and Philippe > > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ > > "Any simple problem can be made insoluble if enough meetings are held to > discuss it." > -- Mitchell's Law of Committees > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b33c750e5575804c90d5e6e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,
=A0
I commented before on the work metric-06=A0[*], with no reply on the l= ist, even in the meeting 84 there was no comment on what was in the list (w= hich I recommend to be=A0done in future) related to such document.
=A0
My comment on the new WG draft (rationale-00)=A0is that the draft is e= xcellent,=A0and I support to WGLC, I will try to find time to overview and = comment (minor suggestion),
=A0
AB
=3D=3D=3D
=A0
On Wed, Sep 5, 2012 at 4:04 PM, Thomas Heide Cla= usen <ietf@thomasclausen.org> wrote:

Dear all,

As you= know, =A0http://tools.i= etf.org/html/draft-dearlove-olsrv2-metrics-06=A0was presented at the IE= TF'84 [MANET] meeting, and has been adopted by the WG as=A0http://tools.ietf.org/ht= ml/draft-ietf-manet-olsrv2-metrics-rationale-00. The slides of the pres= entation from IETF'84 are, starting from page 9, here:=A0http://www.ietf.org/proceedi= ngs/84/slides/slides-84-manet-2.pdf


As a reminder, this doc= ument is derived from the document (already discussed by the WG since 2007,= as draft-dearlove-olsrv2-metrics) which originally described how to integr= ate metrics into OLSRv2, and for which consensus was established resulting = in the metrics design of OLSRv2.

=A0=20

While OLSRv2 desc= ribes *how* metrics were integrated, draft-ietf-manet-olsrv2-metrics-ration= ale presents the *why* - the design rationale, and is intended as publicati= on as an Informational RFC.

=A0

The authors would like = to see a WGLC of this=A0document some time between now and the next I= ETF.=A0


<= /div>

We'd therefor= e like to ask the WG to=A0review and give feedback so that we may spin a ne= w version soon.



<= /p>

Respectfully,


<= /div>

Thomas, Chris and= Philippe


--=A0
Thomas Heide Clausen

"Any simple problem can be made inso= luble if enough meetings are held to=20
=A0discuss it."=20
=A0 =A0-- Mitchell's Law of Committees

_______________________________________________
man= et mailing list
manet@ietf.org
= h= ttps://www.ietf.org/mailman/listinfo/manet


--047d7b33c750e5575804c90d5e6e-- From abdussalambaryun@gmail.com Thu Sep 6 12:41:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E7921F8780 for ; Thu, 6 Sep 2012 12:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeapwGfg9nhU for ; Thu, 6 Sep 2012 12:41:39 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF7521F86F1 for ; Thu, 6 Sep 2012 12:41:38 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3160434vcb.31 for ; Thu, 06 Sep 2012 12:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xQpYkhZoJW2Xo5HhSmC7xVhPUrBtVsDeVTsg2ucO8VY=; b=ieyXMuH/mzorbx0fq9A2FrZdRhSWLuNt8MBTymBbJGNj8DYO0T3sORJxSfwiQcYnvL 8jedS9h/OMy1XA5CA98TJnhzosDAKArJngS8q1KJvozbEJFI8Tw9w4XjSYVlT0zPzz3O ey5QRSgVa1GTtz3l+yiNqRLnLt6DJRGIuKkAoOpx3J9MC+yw+RGZ4O15q9uhNGfmqIKx oqOi6WB/zryVq5+73ATlNaFZb/edsXmfwgBCr5T3v3oQ3AbWomUremG7AMf3DRRTDwbj eb+mWZOl714HdP+TSw9w6y9DfO0FzT7Bzd+zlSoTGJ4pbMm3sZYQXAnN7YAQsWxjtqsT UgfA== MIME-Version: 1.0 Received: by 10.52.174.82 with SMTP id bq18mr3180774vdc.25.1346960498284; Thu, 06 Sep 2012 12:41:38 -0700 (PDT) Received: by 10.220.2.83 with HTTP; Thu, 6 Sep 2012 12:41:38 -0700 (PDT) In-Reply-To: <328900A6-0B2F-40EE-9B02-104A6FD783C7@cisco.com> References: <1D327B91-44C5-490C-842B-102FFDF7E62A@thomasclausen.org> <328900A6-0B2F-40EE-9B02-104A6FD783C7@cisco.com> Date: Thu, 6 Sep 2012 20:41:38 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=bcaec51ba61b06d8a104c90dae1a Cc: manet Subject: Re: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 19:41:40 -0000 --bcaec51ba61b06d8a104c90dae1a Content-Type: text/plain; charset=ISO-8859-1 Hi Stan, I agree with you that we need to comment on this document for *progress*, but I also recommend that any comment related to be replied to by authors in both the list and abstracted at the next meeting 85. Furthermore, I recommend that authors should reply to comments/discussions related to their document not later than 90 days. There were many comments/suggestions on the list but were not even mentioned in the meeting which I felt no progress. AB On Wed, Sep 5, 2012 at 5:31 PM, Stan Ratliff (sratliff) wrote: > Folks, > > Please find some time to review and comment on this doc, so that we may > move it along the path. > > Regards, > Stan > > On Sep 5, 2012, at 11:04 AM, Thomas Heide Clausen wrote: > > Dear all, > > As you know, http://tools.ietf.org/html/draft-dearlove-olsrv2-metrics-06 was > presented at the IETF'84 [MANET] meeting, and has been adopted by the WG as > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-00. > The slides of the presentation from IETF'84 are, starting from page 9, > here: http://www.ietf.org/proceedings/84/slides/slides-84-manet-2.pdf**** > > As a reminder, this document is derived from the document (already > discussed by the WG since 2007, as draft-dearlove-olsrv2-metrics) which > originally described how to integrate metrics into OLSRv2, and for which > consensus was established resulting in the metrics design of OLSRv2.**** > > While OLSRv2 describes *how* metrics were integrated, > draft-ietf-manet-olsrv2-metrics-rationale presents the *why* - the design > rationale, and is intended as publication as an Informational RFC. > **** > ** ** > The authors would like to see a WGLC of this document some time between > now and the next IETF. **** > > **** > We'd therefore like to ask the WG to review and give feedback so that we > may spin a new version soon.**** > > > **** > Respectfully, > > **** > Thomas, Chris and Philippe > > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ > > "Any simple problem can be made insoluble if enough meetings are held to > discuss it." > -- Mitchell's Law of Committees > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --bcaec51ba61b06d8a104c90dae1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stan,
=A0
I agree with you that we need to comment on this document for *progres= s*, but I also recommend that any comment related=A0to be replied to by aut= hors in both the list and=A0abstracted at the next meeting 85. Furthermore,= I recommend that authors should reply to comments/discussions related to t= heir document not later than 90 days.
=A0
There were many comments/suggestions on the list but were not even men= tioned in the meeting which I felt=A0no progress.
=A0
AB

On Wed, Sep 5, 2012 at 5:31 PM, Stan Ratliff (sr= atliff) <sratliff@cisco.com> wrote:
Folks,=A0=20

Please find some time to review and comment on this doc, so that we ma= y move it along the path.

Regards,
Stan

On Sep 5, 2012, at 11:04 AM, Thomas Heide Clausen wrote:

Dear all,

As you know, =A0http://tools.ietf.org/html/draft= -dearlove-olsrv2-metrics-06=A0was presented at the IETF'84 [MANET] = meeting, and has been adopted by the WG as=A0http://tools.ietf.org/html/draft-ietf-mane= t-olsrv2-metrics-rationale-00. The slides of the presentation from IETF= '84 are, starting from page 9, here:=A0http://www.ietf.org/proceedings/84/slides/slid= es-84-manet-2.pdf

As a reminder, this document is derived f= rom the document (already discussed by the WG since 2007, as draft-dearlove= -olsrv2-metrics) which originally described how to integrate metrics into O= LSRv2, and for which consensus was established resulting in the metrics des= ign of OLSRv2.

While OLSRv2 describes *how* metric= s were integrated, draft-ietf-manet-olsrv2-metrics-rationale presents the *= why* - the design rationale, and is intended as publication as an Informati= onal RFC.
=A0
The authors would like to see a WGLC of t= his=A0document some time between now and the next IETF.=A0<= /u>

We'd therefore like to ask the = WG to=A0review and give feedback so that we may spin a new version soon.


Respectfully,

Thomas, Chris and Philippe

--=A0
Thomas Heide Clausen

"Any simple problem can be made inso= luble if enough meetings are held to=20
=A0discuss it."=20
=A0 =A0-- Mitchell's Law of Committees
______________________________________________= _
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet


____________________________________= ___________
manet mailing list
mane= t@ietf.org
https://www.ietf.org/mailman/listinfo/manet


--bcaec51ba61b06d8a104c90dae1a-- From Chris.Dearlove@baesystems.com Fri Sep 7 01:55:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B64821F8736 for ; Fri, 7 Sep 2012 01:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjK2yThtdeNS for ; Fri, 7 Sep 2012 01:55:43 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 924C221F871E for ; Fri, 7 Sep 2012 01:55:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,384,1344207600"; d="scan'208,217";a="269075420" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 07 Sep 2012 09:55:41 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q878tfM8007412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Sep 2012 09:55:41 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.208]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0309.002; Fri, 7 Sep 2012 09:55:40 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , Thomas Heide Clausen Thread-Topic: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale Thread-Index: AQHNi3fPaN1BbxVf+U+p9GFbVinAwpd9oWAAgADzp9A= Date: Fri, 7 Sep 2012 08:55:40 +0000 Message-ID: References: <1D327B91-44C5-490C-842B-102FFDF7E62A@thomasclausen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24F4FFB3GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:55:44 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24F4FFB3GLKXM0002VGREEN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Those comments misunderstood the nature of the document. They suggested that it should introduce rules for this and that. This is an informative draft that describes rationale, not a protocol specification. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: 06 September 2012 20:20 To: Thomas Heide Clausen Cc: manet Subject: Re: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. Hi Thomas, I commented before on the work metric-06 [*], with no reply on the list, even in the meeting 84 there was no comment on what was in the list (which I recommend to be done in future) related to such document. My comment on the new WG draft (rationale-00) is that the draft is excellent, and I support to WGLC, I will try to find time to overview and comment (minor suggestion), [*] http://www.ietf.org/mail-archive/web/manet/current/msg13204.html AB === On Wed, Sep 5, 2012 at 4:04 PM, Thomas Heide Clausen > wrote: Dear all, As you know, http://tools.ietf.org/html/draft-dearlove-olsrv2-metrics-06 was presented at the IETF'84 [MANET] meeting, and has been adopted by the WG as http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-00. The slides of the presentation from IETF'84 are, starting from page 9, here: http://www.ietf.org/proceedings/84/slides/slides-84-manet-2.pdf As a reminder, this document is derived from the document (already discussed by the WG since 2007, as draft-dearlove-olsrv2-metrics) which originally described how to integrate metrics into OLSRv2, and for which consensus was established resulting in the metrics design of OLSRv2. While OLSRv2 describes *how* metrics were integrated, draft-ietf-manet-olsrv2-metrics-rationale presents the *why* - the design rationale, and is intended as publication as an Informational RFC. The authors would like to see a WGLC of this document some time between now and the next IETF. We'd therefore like to ask the WG to review and give feedback so that we may spin a new version soon. Respectfully, Thomas, Chris and Philippe -- Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24F4FFB3GLKXM0002VGREEN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Those comments misunderstood the nature of the document. They suggested that it should introduce rules for this and that. This is an informative draft that describes rationale, not a protocol specification.

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 06 September 2012 20:20
To: Thomas Heide Clausen
Cc: manet
Subject: Re: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

Hi Thomas,

 

I commented before on the work metric-06 [*], with no reply on the list, even in the meeting 84 there was no comment on what was in the list (which I recommend to be done in future) related to such document.

 

My comment on the new WG draft (rationale-00) is that the draft is excellent, and I support to WGLC, I will try to find time to overview and comment (minor suggestion),

 

AB
===

 

On Wed, Sep 5, 2012 at 4:04 PM, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:

Dear all,

As you know,  http://tools.ietf.org/html/draft-dearlove-olsrv2-metrics-06 was presented at the IETF'84 [MANET] meeting, and has been adopted by the WG as http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-00. The slides of the presentation from IETF'84 are, starting from page 9, here: http://www.ietf.org/proceedings/84/slides/slides-84-manet-2.pdf

 

As a reminder, this document is derived from the document (already discussed by the WG since 2007, as draft-dearlove-olsrv2-metrics) which originally described how to integrate metrics into OLSRv2, and for which consensus was established resulting in the metrics design of OLSRv2.

 

While OLSRv2 describes *how* metrics were integrated, draft-ietf-manet-olsrv2-metrics-rationale presents the *why* - the design rationale, and is intended as publication as an Informational RFC.

 

The authors would like to see a WGLC of this document some time between now and the next IETF. 

 

We'd therefore like to ask the WG to review and give feedback so that we may spin a new version soon.

 

Respectfully,

 

Thomas, Chris and Philippe

 

-- 

Thomas Heide Clausen

 

"Any simple problem can be made insoluble if enough meetings are held to

 discuss it."

   -- Mitchell's Law of Committees


_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

 


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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D24F4FFB3GLKXM0002VGREEN_-- From internet-drafts@ietf.org Sun Sep 9 05:59:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025CB21F8503; Sun, 9 Sep 2012 05:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM9ozgs+bJa8; Sun, 9 Sep 2012 05:59:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496AD21F84EE; Sun, 9 Sep 2012 05:59:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120909125904.27907.21792.idtracker@ietfa.amsl.com> Date: Sun, 09 Sep 2012 05:59:04 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-mib-18.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 12:59:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Definition of Managed Objects for the Neighborhood Disco= very Protocol Author(s) : Ulrich Herberg Robert G. Cole Ian D Chakeres Filename : draft-ietf-manet-nhdp-mib-18.txt Pages : 67 Date : 2012-09-09 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-mib-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Sep 9 09:54:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3581521F8539; Sun, 9 Sep 2012 09:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTE--B2zQjQ0; Sun, 9 Sep 2012 09:54:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9225F21F853F; Sun, 9 Sep 2012 09:54:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> Date: Sun, 09 Sep 2012 09:54:21 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 16:54:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Definition of Managed Objects for the Neighborhood Disco= very Protocol Author(s) : Ulrich Herberg Robert G. Cole Ian D Chakeres Filename : draft-ietf-manet-nhdp-mib-19.txt Pages : 67 Date : 2012-09-09 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-mib-19 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abdussalambaryun@gmail.com Sun Sep 9 13:59:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102B421F8564 for ; Sun, 9 Sep 2012 13:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxaP+sJ4PUmx for ; Sun, 9 Sep 2012 13:59:00 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1CCC21F8551 for ; Sun, 9 Sep 2012 13:58:59 -0700 (PDT) Received: by vbal1 with SMTP id l1so2031553vba.31 for ; Sun, 09 Sep 2012 13:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=o8212hnf/fLvcUwAZEOpubSfgkGcxhgNpa22rJlIygU=; b=xPrrTpHDrtDDCLx74oseey8ut7HC5dO0jAwRFK1nnHS0Y+/RiKbDulawczjfLRqwEo 1/El3EYVvx2pjcmoaQxLToUKGQpJLsRxShrMmz7G2gB370BX6FYtCRBd59kC9QOOq5Es 6bATelv+tInFfC38ThcAT/VcJi2eRLF8Hk8uf8F53aP5SY/BVWPxY/CJ7yHHdFVLJql9 TH4WKzQ/7zEZRQ5QAxeTa0i6MM8j8jaPelWPjZOf81YWZ1iJG8sQqPIGT4KptfDurJAM qcAb0HFaMSvT/7hPrlIPaP26LD+2YyeblNOWoqv+kfcY2qoX6/ZZhkS+4Frnnt1VsODL b0qg== MIME-Version: 1.0 Received: by 10.220.119.198 with SMTP id a6mr16663512vcr.23.1347224339343; Sun, 09 Sep 2012 13:58:59 -0700 (PDT) Received: by 10.220.2.83 with HTTP; Sun, 9 Sep 2012 13:58:59 -0700 (PDT) In-Reply-To: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> References: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> Date: Sun, 9 Sep 2012 22:58:59 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 20:59:01 -0000 Could we know as a WG, why this WG draft is changing many times while submitted? Please advise, AB On 9/9/12, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > Title : Definition of Managed Objects for the Neighborhood > Discovery Protocol > Author(s) : Ulrich Herberg > Robert G. Cole > Ian D Chakeres > Filename : draft-ietf-manet-nhdp-mib-19.txt > Pages : 67 > Date : 2012-09-09 > > Abstract: > This document defines a portion of the Management Information Base > (MIB) for use with network management protocols in the Internet > community. In particular, it describes objects for configuring > parameters of the Neighborhood Discovery Protocol (NHDP) process on a > router. The MIB module defined in this document, denoted NHDP-MIB, > also reports state, performance information and notifications about > NHDP. This additional state and performance information is useful to > troubleshoot problems and performance issues during neighbor > discovery. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-19 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-mib-19 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From abdussalambaryun@gmail.com Sun Sep 9 14:14:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772F621F857E for ; Sun, 9 Sep 2012 14:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKGfLxqt8TiQ for ; Sun, 9 Sep 2012 14:14:58 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3A421F8594 for ; Sun, 9 Sep 2012 14:14:58 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so498991vcb.31 for ; Sun, 09 Sep 2012 14:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R5qif4jDWBW1y+XMx3crzSs/T5W1gg9pGoxiaVHuZhI=; b=hZVP1FKBhsdlBGOgUEjQ8MNuliNJbovLJSk9EAugA3qj7WcORfXpqyHG7XHBrdU43/ HgQ89k6C8/cMfROGV9QJ/tlrJU+m/HSDSEIx+TZbvZcHGGz+6E2aKUZpSRKRaYd7Dbbc LgiwPG9AaLw3bp19ruWF+vIb4E6Ffu0WLixs1qG9Oqz5MvuQs3rrKwfTbsPvurshB98m oirAtJjHb5y+0+AAG2iRHWrDs4sLuDUeyDwgEmpR/KVW9QPXVXS1/b5GLsDp795U/y2b 8ShaOTu396fwfXPKkxc3t9NAc6d24T4Hi6qRoexUwa6w2BYRiNtnuBEqt5/ffOLstPrg tQ+g== MIME-Version: 1.0 Received: by 10.220.16.12 with SMTP id m12mr4963259vca.14.1347225293188; Sun, 09 Sep 2012 14:14:53 -0700 (PDT) Received: by 10.220.2.83 with HTTP; Sun, 9 Sep 2012 14:14:52 -0700 (PDT) In-Reply-To: References: <1D327B91-44C5-490C-842B-102FFDF7E62A@thomasclausen.org> Date: Sun, 9 Sep 2012 23:14:52 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Progressing on draft-ietf-manet-olsrv2-metrics-rationale X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 21:14:59 -0000 I don't think it was misunderstood and I think it was related to the subject and was in title for getting a reply from authors at least for progress in two direction not only one. Progress for drafts needs equal discussion by the WG and authors, I recommend all authors of any draft (individual or wg) to reply to related comments/suggestions. I will reply in details to the below message in another place, thanking you for your reply. AB On 9/7/12, Dearlove, Christopher (UK) wrote: > Those comments misunderstood the nature of the document. They suggested that > it should introduce rules for this and that. This is an informative draft > that describes rationale, not a protocol specification. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 06 September 2012 20:20 > To: Thomas Heide Clausen > Cc: manet > Subject: Re: [manet] Progressing on > draft-ietf-manet-olsrv2-metrics-rationale > > > *** WARNING *** > This message originates from outside our organisation, either from an > external partner or the internet. > Keep this in mind if you answer this message. > Please see this > process > on how to deal with suspicious emails. > Hi Thomas, > > I commented before on the work metric-06 [*], with no reply on the list, > even in the meeting 84 there was no comment on what was in the list (which I > recommend to be done in future) related to such document. > > My comment on the new WG draft (rationale-00) is that the draft is > excellent, and I support to WGLC, I will try to find time to overview and > comment (minor suggestion), > > [*] http://www.ietf.org/mail-archive/web/manet/current/msg13204.html > AB > === > > On Wed, Sep 5, 2012 at 4:04 PM, Thomas Heide Clausen > > wrote: > Dear all, > > As you know, http://tools.ietf.org/html/draft-dearlove-olsrv2-metrics-06 > was presented at the IETF'84 [MANET] meeting, and has been adopted by the WG > as http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-00. > The slides of the presentation from IETF'84 are, starting from page 9, here: > http://www.ietf.org/proceedings/84/slides/slides-84-manet-2.pdf > > As a reminder, this document is derived from the document (already discussed > by the WG since 2007, as draft-dearlove-olsrv2-metrics) which originally > described how to integrate metrics into OLSRv2, and for which consensus was > established resulting in the metrics design of OLSRv2. > > While OLSRv2 describes *how* metrics were integrated, > draft-ietf-manet-olsrv2-metrics-rationale presents the *why* - the design > rationale, and is intended as publication as an Informational RFC. > > The authors would like to see a WGLC of this document some time between now > and the next IETF. > > We'd therefore like to ask the WG to review and give feedback so that we may > spin a new version soon. > > Respectfully, > > Thomas, Chris and Philippe > > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ > > "Any simple problem can be made insoluble if enough meetings are held to > discuss it." > -- Mitchell's Law of Committees > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > 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 ietf@thomasclausen.org Sun Sep 9 16:37:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484EA21F84D2 for ; Sun, 9 Sep 2012 16:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRNx6yulDv1t for ; Sun, 9 Sep 2012 16:37:15 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE5221F85D5 for ; Sun, 9 Sep 2012 16:37:15 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 612E9558067 for ; Sun, 9 Sep 2012 16:37:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C1C281A3F27; Sun, 9 Sep 2012 16:37:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.137] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 72B2F1A3F26; Sun, 9 Sep 2012 16:37:11 -0700 (PDT) References: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <040AA819-E123-4814-8B49-F3A37D80EDD7@thomasclausen.org> X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Mon, 10 Sep 2012 01:37:10 +0200 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 23:37:16 -0000 See: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf= -manet-nhdp-mib-19.txt --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 9 Sep 2012, at 22:58, Abdussalam Baryun wrot= e: > Could we know as a WG, why this WG draft is changing many times while > submitted? Please advise, >=20 > AB >=20 > On 9/9/12, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group of >> the IETF. >>=20 >> Title : Definition of Managed Objects for the Neighborhood >> Discovery Protocol >> Author(s) : Ulrich Herberg >> Robert G. Cole >> Ian D Chakeres >> Filename : draft-ietf-manet-nhdp-mib-19.txt >> Pages : 67 >> Date : 2012-09-09 >>=20 >> Abstract: >> This document defines a portion of the Management Information Base >> (MIB) for use with network management protocols in the Internet >> community. In particular, it describes objects for configuring >> parameters of the Neighborhood Discovery Protocol (NHDP) process on a >> router. The MIB module defined in this document, denoted NHDP-MIB, >> also reports state, performance information and notifications about >> NHDP. This additional state and performance information is useful to >> troubleshoot problems and performance issues during neighbor >> discovery. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-19 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-mib-19 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Sun Sep 9 19:25:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5B621F8593 for ; Sun, 9 Sep 2012 19:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pKRvWiW8Va6 for ; Sun, 9 Sep 2012 19:25:15 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08F4021F856D for ; Sun, 9 Sep 2012 19:25:14 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so702177vcb.31 for ; Sun, 09 Sep 2012 19:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JprE0Bz7q0sQ7TVdjP+lJiyPbZs+l9tKwdFM/XjAS1k=; b=Ue4fipaqu4wKL5aYF6WYrEm8OBcadNqSktMjoRUFthuU3BOapa8KrleGpF29X9JleH k31KZm4dqowWSdSie9pwYbc07GVVUj8w9ay/yTpoUhhwtzByFwbb7fhPt6ekyoZo+zCq eqwlVc1JPgqPmhlPHk8yL1rbkJvcUSO5pAgM4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=JprE0Bz7q0sQ7TVdjP+lJiyPbZs+l9tKwdFM/XjAS1k=; b=i5PRkN78az3AZ1lriCVadIAvxYMr3i0IfC37gmL88NYxgmmPmvdMO8FI0UvxgGWzQr cJffiiK96rPJ9EXGZ4zpTVMaY5y2SAnb53hc2nWW1vyRCCFV9bd54OZep3tPBGJpwZ19 4KOAVhvCBKjoLdp6tVgukPHNLORciZJ8cdfHCQk37PJotOCT0WWdFfw6cf8hime6G9iV TnspkRuRQ7jpoE/0ZUqAD58/aZwR06SQvhMlL0g0Pby3x9YzgHoL9m3JjVgMzbhT8r6e gF8uwCrcA//NhrjsERQOIpiJdqlg8m0IEfkKa7/2dyRbkC6gdGbYyC7bW3U9TznhvqNd WDKg== MIME-Version: 1.0 Received: by 10.221.10.148 with SMTP id pa20mr17201681vcb.26.1347243914391; Sun, 09 Sep 2012 19:25:14 -0700 (PDT) Received: by 10.58.187.78 with HTTP; Sun, 9 Sep 2012 19:25:14 -0700 (PDT) In-Reply-To: <040AA819-E123-4814-8B49-F3A37D80EDD7@thomasclausen.org> References: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> <040AA819-E123-4814-8B49-F3A37D80EDD7@thomasclausen.org> Date: Sun, 9 Sep 2012 19:25:14 -0700 Message-ID: From: Ulrich Herberg To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmVLh/V9jZVNC0APptJI5OZUikCkOPbNfw2twuEMQaOiZfuQ4hO6HgcGDLbgSTCGdfYA7Xo Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 02:25:16 -0000 Abdussalam, the reason for the latest revision was a simple glitch in our versioning, where we un-did some changes we already submitted in an earlier version. The last three revisions were addressing the DISCUSS from Benoit (and in particular some of the requests of Thomas Nadeau, the MIB doctor). As you can see in the diff, the changes were minimal and mostly editorial. Best regards Ulrich On Sun, Sep 9, 2012 at 4:37 PM, Thomas Heide Clausen wrote: > See: > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-manet-nhdp-mib-19.txt > > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ > > "Any simple problem can be made insoluble if enough meetings are held to > discuss it." > -- Mitchell's Law of Committees > > > On 9 Sep 2012, at 22:58, Abdussalam Baryun wrote: > >> Could we know as a WG, why this WG draft is changing many times while >> submitted? Please advise, >> >> AB >> >> On 9/9/12, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Mobile Ad-hoc Networks Working Group of >>> the IETF. >>> >>> Title : Definition of Managed Objects for the Neighborhood >>> Discovery Protocol >>> Author(s) : Ulrich Herberg >>> Robert G. Cole >>> Ian D Chakeres >>> Filename : draft-ietf-manet-nhdp-mib-19.txt >>> Pages : 67 >>> Date : 2012-09-09 >>> >>> Abstract: >>> This document defines a portion of the Management Information Base >>> (MIB) for use with network management protocols in the Internet >>> community. In particular, it describes objects for configuring >>> parameters of the Neighborhood Discovery Protocol (NHDP) process on a >>> router. The MIB module defined in this document, denoted NHDP-MIB, >>> also reports state, performance information and notifications about >>> NHDP. This additional state and performance information is useful to >>> troubleshoot problems and performance issues during neighbor >>> discovery. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-19 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-mib-19 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Mon Sep 10 02:59:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7414921F8619 for ; Mon, 10 Sep 2012 02:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2sHTjiKdHWW for ; Mon, 10 Sep 2012 02:59:15 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71C2421F8617 for ; Mon, 10 Sep 2012 02:59:15 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1104433vcb.31 for ; Mon, 10 Sep 2012 02:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oXt9Ev3V0KqTCKj7rRutnYj7h2DNpSHCMwTmlXPsGJI=; b=mfnGdGHN/hNNzSUW5xbY+bFCB6czHA7SQAEkyXRFIFqCSZM+9139Etch/Ly3bdiC43 lbaPZlS/k7vJSPL0u9lWZpwz1x14J2E5uxDSc0Jqc2BzEOqhudIZPOQNnv1PRvB4hMit UGPMD7ztwZACAW95R+3yqbLrcw8WDMTBGb3R0IkPgDcV8LN8ygCPNJ4sXj5bvpI6C0Es RuxtAl2UJUmSW02OzEvIrB+dya4r307A/kILIqcJbQ0fOYKI4wuGnfVVoLioMpzJduOB sz387m8+6XAB3E3IMijhAioiZRdzOFGTSAFhyqPqLS6YDE7ObwKO0Axb1Sc4lqo6dTGL iHaw== MIME-Version: 1.0 Received: by 10.58.89.168 with SMTP id bp8mr20476538veb.20.1347271154556; Mon, 10 Sep 2012 02:59:14 -0700 (PDT) Received: by 10.220.2.83 with HTTP; Mon, 10 Sep 2012 02:59:14 -0700 (PDT) In-Reply-To: References: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> <040AA819-E123-4814-8B49-F3A37D80EDD7@thomasclausen.org> Date: Mon, 10 Sep 2012 11:59:14 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 09:59:16 -0000 Hi Ulrich, I just wanted to know why the DISCUSS is still there from July until now? I think you done well in the versions as adding [*], and why we still are making changes after -17 in many versions why not one only. I am interested that it goes through with known progress or known delay reasons. Furthermore, I will hope the draft will not stay in DISCUSS for more than 28 days, if it does I think the WG should know why. Thanking you, [*] http://www.ietf.org/mail-archive/web/manet/current/msg13168.html AB +++ On 9/10/12, Ulrich Herberg wrote: > Abdussalam, > > the reason for the latest revision was a simple glitch in our > versioning, where we un-did some changes we already submitted in an > earlier version. The last three revisions were addressing the DISCUSS > from Benoit (and in particular some of the requests of Thomas Nadeau, > the MIB doctor). As you can see in the diff, the changes were minimal > and mostly editorial. > > Best regards > Ulrich > > On Sun, Sep 9, 2012 at 4:37 PM, Thomas Heide Clausen > wrote: >> See: >> >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-manet-nhdp-mib-19.txt >> >> -- >> Thomas Heide Clausen >> http://www.thomasclausen.org/ >> >> "Any simple problem can be made insoluble if enough meetings are held to >> discuss it." >> -- Mitchell's Law of Committees >> >> >> On 9 Sep 2012, at 22:58, Abdussalam Baryun >> wrote: >> >>> Could we know as a WG, why this WG draft is changing many times while >>> submitted? Please advise, >>> >>> AB >>> >>> On 9/9/12, internet-drafts@ietf.org wrote: >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Mobile Ad-hoc Networks Working Group >>>> of >>>> the IETF. >>>> >>>> Title : Definition of Managed Objects for the Neighborhood >>>> Discovery Protocol >>>> Author(s) : Ulrich Herberg >>>> Robert G. Cole >>>> Ian D Chakeres >>>> Filename : draft-ietf-manet-nhdp-mib-19.txt >>>> Pages : 67 >>>> Date : 2012-09-09 >>>> >>>> Abstract: >>>> This document defines a portion of the Management Information Base >>>> (MIB) for use with network management protocols in the Internet >>>> community. In particular, it describes objects for configuring >>>> parameters of the Neighborhood Discovery Protocol (NHDP) process on a >>>> router. The MIB module defined in this document, denoted NHDP-MIB, >>>> also reports state, performance information and notifications about >>>> NHDP. This additional state and performance information is useful to >>>> troubleshoot problems and performance issues during neighbor >>>> discovery. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-19 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-mib-19 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > From ietf@thomasclausen.org Mon Sep 10 03:18:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD65921F862B for ; Mon, 10 Sep 2012 03:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id turrIQsfsMCA for ; Mon, 10 Sep 2012 03:18:59 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 11F2121F85A3 for ; Mon, 10 Sep 2012 03:18:59 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 8CD745582C8 for ; Mon, 10 Sep 2012 03:18:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 88C281C0128; Mon, 10 Sep 2012 03:18:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [172.20.10.10] (unknown [37.160.0.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2D6211C0042; Mon, 10 Sep 2012 03:18:56 -0700 (PDT) References: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> <040AA819-E123-4814-8B49-F3A37D80EDD7@thomasclausen.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <25FB442A-F2A5-4382-9D8B-06CFF8C04728@thomasclausen.org> X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Mon, 10 Sep 2012 12:18:50 +0200 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 10:18:59 -0000 Abdussalam, 1) A DISCUSS is held on a document, for as long as is needed for an AD= to verify that the=20 subject of his/her discuss is resolved. Note that this includes (of= ten) exchanging emails=20 between the AD and the authors (often, with these being in differen= t time-zones) so as=20 to understand how to resolve the discuss, for the authors to implem= ent whatever necessary changes, for the AD to review the changes (and possibly i= terations over this for=20 as long as is needed). Occasionally, a DISCUSS is held for only hou= rs, at other times for years - commonly, a DISCUSS lasts somewhere in between, depending o= n the issue. 2) Often, but not always, authors work on one issue, resolve that one i= ssue in a revised version=20 of the document, then proceed to work on resolving the next issue (= etc.) - depending on their available time, work-practices, when they manage to corner an= AD, etc. 3) ADs are not paid by the IETF either (just like everybody else aren'= t), and have day-jobs to=20 attend to also. Rather than stress them, you should encourage them a= nd express=20 appreciation for their efforts. 4) I suggest taking a good long look at http://www.ietf.org/edu/tutori= als.html especially (but not exclusively) at http://www.ietf.org/edu/process-oriented-t= utorials.html Best, Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 10 Sep 2012, at 11:59, Abdussalam Baryun wro= te: > Hi Ulrich, >=20 > I just wanted to know why the DISCUSS is still there from July until > now? I think you done well in the versions as adding [*], and why we > still are making changes after -17 in many versions why not one only. > I am interested that it goes through with known progress or known > delay reasons. Furthermore, I will hope the draft will not stay in > DISCUSS for more than 28 days, if it does I think the WG should know > why. Thanking you, >=20 > [*] http://www.ietf.org/mail-archive/web/manet/current/msg13168.html >=20 > AB > +++ > On 9/10/12, Ulrich Herberg wrote: >> Abdussalam, >>=20 >> the reason for the latest revision was a simple glitch in our >> versioning, where we un-did some changes we already submitted in an >> earlier version. The last three revisions were addressing the DISCUSS >> from Benoit (and in particular some of the requests of Thomas Nadeau, >> the MIB doctor). As you can see in the diff, the changes were minimal >> and mostly editorial. >>=20 >> Best regards >> Ulrich >>=20 >> On Sun, Sep 9, 2012 at 4:37 PM, Thomas Heide Clausen >> wrote: >>> See: >>>=20 >>> http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-mane= t-nhdp-mib-19.txt >>>=20 >>> -- >>> Thomas Heide Clausen >>> http://www.thomasclausen.org/ >>>=20 >>> "Any simple problem can be made insoluble if enough meetings are held to= >>> discuss it." >>> -- Mitchell's Law of Committees >>>=20 >>>=20 >>> On 9 Sep 2012, at 22:58, Abdussalam Baryun >>> wrote: >>>=20 >>>> Could we know as a WG, why this WG draft is changing many times while >>>> submitted? Please advise, >>>>=20 >>>> AB >>>>=20 >>>> On 9/9/12, internet-drafts@ietf.org wrote: >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Mobile Ad-hoc Networks Working Group >>>>> of >>>>> the IETF. >>>>>=20 >>>>> Title : Definition of Managed Objects for the Neighborhood= >>>>> Discovery Protocol >>>>> Author(s) : Ulrich Herberg >>>>> Robert G. Cole >>>>> Ian D Chakeres >>>>> Filename : draft-ietf-manet-nhdp-mib-19.txt >>>>> Pages : 67 >>>>> Date : 2012-09-09 >>>>>=20 >>>>> Abstract: >>>>> This document defines a portion of the Management Information Base >>>>> (MIB) for use with network management protocols in the Internet >>>>> community. In particular, it describes objects for configuring >>>>> parameters of the Neighborhood Discovery Protocol (NHDP) process on a= >>>>> router. The MIB module defined in this document, denoted NHDP-MIB, >>>>> also reports state, performance information and notifications about >>>>> NHDP. This additional state and performance information is useful to= >>>>> troubleshoot problems and performance issues during neighbor >>>>> discovery. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-19 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-mib-19 >>>>>=20 >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 From abdussalambaryun@gmail.com Mon Sep 10 05:35:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E488C21F8680 for ; Mon, 10 Sep 2012 05:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAtwzvxxm7Qt for ; Mon, 10 Sep 2012 05:35:43 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1290221F867E for ; Mon, 10 Sep 2012 05:35:42 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1304931vcb.31 for ; Mon, 10 Sep 2012 05:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=k2kuhYW5RD4k3fPMOtLami8DagjdxD1xZbTkzhxgQoU=; b=BVedBpje7rSdd/GYhT4DexfuQaKGiQ1bKRcRXqOifm6bHNUnd1Wx3TEcuFhLBiOxAN Q0hHI8QGWgLDOqW+dCZmlupWt0tBJOFh1gCfdlhVR6VPcqd9UgDOsYYrctkj9UPV7an3 3ssBcaMe/puZHDybaCV6d6+KTOqa8CLxQ7IlproK1cTgHp8p6a/Ouf+JycMqMYqMq1pi JtBQQg/sHSvuNXKF6VpTaD7bKq5DBqyCwDDyxzxqFLBrIqleGFLS0VeWXFFFSgl/fI1t Kuq+SOYUmweISzqYMJHeZptW2bQh/0+Wn6V9JT3PLr9ySW5tDqetc/K4G6u68BEyV8Ms TUqw== MIME-Version: 1.0 Received: by 10.52.174.82 with SMTP id bq18mr15466979vdc.25.1347280542454; Mon, 10 Sep 2012 05:35:42 -0700 (PDT) Received: by 10.220.2.83 with HTTP; Mon, 10 Sep 2012 05:35:42 -0700 (PDT) In-Reply-To: <25FB442A-F2A5-4382-9D8B-06CFF8C04728@thomasclausen.org> References: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> <040AA819-E123-4814-8B49-F3A37D80EDD7@thomasclausen.org> <25FB442A-F2A5-4382-9D8B-06CFF8C04728@thomasclausen.org> Date: Mon, 10 Sep 2012 14:35:42 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 12:35:44 -0000 Hi Thomas, I don't think it is efficient to have a draft in IESG for years, I don't accept that, however, comments below: On 9/10/12, Thomas Heide Clausen wrote: > Abdussalam, > > 1) A DISCUSS is held on a document, for as long as is needed for an AD to > verify that the > subject of his/her discuss is resolved. Note that this includes (often) > exchanging emails > between the AD and the authors (often, with these being in different > time-zones) so as > to understand how to resolve the discuss, for the authors to implement > whatever > necessary changes, for the AD to review the changes (and possibly > iterations over this for > as long as is needed). Occasionally, a DISCUSS is held for only hours, at > other times for > years - commonly, a DISCUSS lasts somewhere in between, depending on the > issue. A DISCUSS position should not be more that 90 days or maximum two ietf meeting periods. I recommend they create a new position named HOLD. > > 2) Often, but not always, authors work on one issue, resolve that one issue > in a revised version > of the document, then proceed to work on resolving the next issue (etc.) - > depending on > their available time, work-practices, when they manage to corner an AD, > etc. > That is fine and I think authors done well for NHDP-MIB, but I see the delay from IESG, that was the reason of my reply to the new version 19 post. > 3) ADs are not paid by the IETF either (just like everybody else aren't), > and have day-jobs to > attend to also. Rather than stress them, you should encourage them and > express > appreciation for their efforts. I always appreciate any effort we are equal in IETF, we all have full responsibilities and we all have taken our choice to participate and volunteer. If we cannot continue to volunteer more than 90 days then we should mention that and help to progress the work force not delay the work force more than 90 days (period of meetings) or maximum 180 days (the maximum is the period for expired drafts). I encourage all to respond as soon as possible so we don't forget issues or change our mind, I encourage both sides submitters and reviewers. > > 4) I suggest taking a good long look at > http://www.ietf.org/edu/tutorials.html especially > (but not exclusively) at > http://www.ietf.org/edu/process-oriented-tutorials.html I already done that before, I joined this organisation. Now I am trying to participate to make things go forward not just watch things happen without comments, -AB +++ > On 10 Sep 2012, at 11:59, Abdussalam Baryun > wrote: > >> Hi Ulrich, >> >> I just wanted to know why the DISCUSS is still there from July until >> now? I think you done well in the versions as adding [*], and why we >> still are making changes after -17 in many versions why not one only. >> I am interested that it goes through with known progress or known >> delay reasons. Furthermore, I will hope the draft will not stay in >> DISCUSS for more than 28 days, if it does I think the WG should know >> why. Thanking you, >> >> [*] http://www.ietf.org/mail-archive/web/manet/current/msg13168.html >> >> AB From ietf@thomasclausen.org Mon Sep 10 07:17:34 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF8221F84A2 for ; Mon, 10 Sep 2012 07:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K-T77I6xKZF for ; Mon, 10 Sep 2012 07:17:34 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBDD21F849D for ; Mon, 10 Sep 2012 07:17:34 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id E0CE5A62F9 for ; Mon, 10 Sep 2012 07:17:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 441721C076C; Mon, 10 Sep 2012 07:17:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.88.27.32] (unknown [37.160.36.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 3A2E71C9F3D; Mon, 10 Sep 2012 07:17:31 -0700 (PDT) References: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> <040AA819-E123-4814-8B49-F3A37D80EDD7@thomasclausen.org> <25FB442A-F2A5-4382-9D8B-06CFF8C04728@thomasclausen.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Mon, 10 Sep 2012 16:17:28 +0200 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:17:35 -0000 Abdussalam, I think that this mailing-list is the wrong forum for discussing IETF/IESG p= rocedural matters. Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 10 Sep 2012, at 14:35, Abdussalam Baryun wro= te: > Hi Thomas, >=20 > I don't think it is efficient to have a draft in IESG for years, I > don't accept that, however, comments below: >=20 > On 9/10/12, Thomas Heide Clausen wrote: >> Abdussalam, >>=20 >> 1) A DISCUSS is held on a document, for as long as is needed for an AD= to >> verify that the >> subject of his/her discuss is resolved. Note that this includes (o= ften) >> exchanging emails >> between the AD and the authors (often, with these being in different >> time-zones) so as >> to understand how to resolve the discuss, for the authors to implement= >> whatever >> necessary changes, for the AD to review the changes (and possibly >> iterations over this for >> as long as is needed). Occasionally, a DISCUSS is held for only hours,= at >> other times for >> years - commonly, a DISCUSS lasts somewhere in between, depending on t= he >> issue. >=20 > A DISCUSS position should not be more that 90 days or maximum two ietf > meeting periods. I recommend they create a new position named HOLD. >=20 >>=20 >> 2) Often, but not always, authors work on one issue, resolve that one i= ssue >> in a revised version >> of the document, then proceed to work on resolving the next issue (etc= .) - >> depending on >> their available time, work-practices, when they manage to corner an AD= , >> etc. >>=20 > That is fine and I think authors done well for NHDP-MIB, but I see the > delay from IESG, that was the reason of my reply to the new version 19 > post. >=20 >> 3) ADs are not paid by the IETF either (just like everybody else aren'= t), >> and have day-jobs to >> attend to also. Rather than stress them, you should encourage them and= >> express >> appreciation for their efforts. >=20 > I always appreciate any effort we are equal in IETF, we all have full > responsibilities and we all have taken our choice to participate and > volunteer. If we cannot continue to volunteer more than 90 days then > we should mention that and help to progress the work force not delay > the work force more than 90 days (period of meetings) or maximum 180 > days (the maximum is the period for expired drafts). I encourage all > to respond as soon as possible so we don't forget issues or change our > mind, I encourage both sides submitters and reviewers. >=20 >>=20 >> 4) I suggest taking a good long look at >> http://www.ietf.org/edu/tutorials.html especially >> (but not exclusively) at >> http://www.ietf.org/edu/process-oriented-tutorials.html >=20 > I already done that before, I joined this organisation. Now I am > trying to participate to make things go forward not just watch things > happen without comments, >=20 > -AB > +++ >> On 10 Sep 2012, at 11:59, Abdussalam Baryun >> wrote: >>=20 >>> Hi Ulrich, >>>=20 >>> I just wanted to know why the DISCUSS is still there from July until >>> now? I think you done well in the versions as adding [*], and why we >>> still are making changes after -17 in many versions why not one only. >>> I am interested that it goes through with known progress or known >>> delay reasons. Furthermore, I will hope the draft will not stay in >>> DISCUSS for more than 28 days, if it does I think the WG should know >>> why. Thanking you, >>>=20 >>> [*] http://www.ietf.org/mail-archive/web/manet/current/msg13168.html >>>=20 >>> AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Sep 10 08:33:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5408521F86F0 for ; Mon, 10 Sep 2012 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0AH3bMpTmMb for ; Mon, 10 Sep 2012 08:33:54 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26EC921F86F2 for ; Mon, 10 Sep 2012 08:33:54 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so826946vbb.31 for ; Mon, 10 Sep 2012 08:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2R27i+VyBWfnylvSk+k9oNs/rz6tpv6Iko9XDmD2SZs=; b=REC2qieswYnuiUBaJXKNNeyh+uZPZ69tuX9BHPgyjZbbUkPoSkZ+0k1nLSOXyrxshw /n69H7ujuPfhEZsD4zM4Rcje0BHUYiQbCTZLqcb9WSw63ydDCDaGwa8nSTt1Y+H5TDUT jiKT4eBEyDMmtVsmD1Co8G5uY0c15zBmrDyDE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=2R27i+VyBWfnylvSk+k9oNs/rz6tpv6Iko9XDmD2SZs=; b=hs1FOjnJqy9jdPCQM6fxgGM+8nQG1mXORra4OS8BndN+cAwGATDl++v90BJ0YG6WZ+ f30TqYZQSxlNT06LSwn6Q83nyrWsFCpoE4mqxowf2fjSKbh9e12bG2lYb7EcT5N8kb/K PfNpNaTufvH6wOUNyiQYsuPoyshgqfsV98wxwrRqoDHM0FgOH7Xhy7Dk3mVDLUFDN1lO 0IbySqG0ZBsfKoi06dnM+OIl76/O4o87zRvCUcvrxsWK2rR4fXNjznPocfFKjj6etOIE 0Yx+Tl3d6GZiz2mtqJCDCQtt1bu0hHuG0HJmkSsLfyBR02kAR9Z2KqbebMr5obM/wX4A lh+w== MIME-Version: 1.0 Received: by 10.58.94.44 with SMTP id cz12mr22081271veb.34.1347291232052; Mon, 10 Sep 2012 08:33:52 -0700 (PDT) Received: by 10.58.187.78 with HTTP; Mon, 10 Sep 2012 08:33:51 -0700 (PDT) In-Reply-To: References: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> <040AA819-E123-4814-8B49-F3A37D80EDD7@thomasclausen.org> Date: Mon, 10 Sep 2012 08:33:51 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlkU0rfoLmhYBfOR5ylMOXMeOT0F+weSLDUEVEbJev/sjn7cJWqRmbWxL1pbCMRccTsUrIm Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:33:55 -0000 Hi Abdussalam, as Thomas explained to you, there was some back and forth between and Benoit and us. Plus, we have clicked the "submit" button too early, so there could have been fewer versions, but well, that's life. The document has improved with the help of Benoit, Thomas Nadeau and Adrian, and so I think the time was well spent. As soon as we submitted a new revision that addressed the DISCUSS, Benoit has lifted his DISCUSS, so I think the process was smooth. I appreciate their help, and I am glad that the document is approved now. Best regards Ulrich On Mon, Sep 10, 2012 at 2:59 AM, Abdussalam Baryun wrote: > Hi Ulrich, > > I just wanted to know why the DISCUSS is still there from July until > now? I think you done well in the versions as adding [*], and why we > still are making changes after -17 in many versions why not one only. > I am interested that it goes through with known progress or known > delay reasons. Furthermore, I will hope the draft will not stay in > DISCUSS for more than 28 days, if it does I think the WG should know > why. Thanking you, > > [*] http://www.ietf.org/mail-archive/web/manet/current/msg13168.html > > AB > +++ > On 9/10/12, Ulrich Herberg wrote: >> Abdussalam, >> >> the reason for the latest revision was a simple glitch in our >> versioning, where we un-did some changes we already submitted in an >> earlier version. The last three revisions were addressing the DISCUSS >> from Benoit (and in particular some of the requests of Thomas Nadeau, >> the MIB doctor). As you can see in the diff, the changes were minimal >> and mostly editorial. >> >> Best regards >> Ulrich >> >> On Sun, Sep 9, 2012 at 4:37 PM, Thomas Heide Clausen >> wrote: >>> See: >>> >>> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-manet-nhdp-mib-19.txt >>> >>> -- >>> Thomas Heide Clausen >>> http://www.thomasclausen.org/ >>> >>> "Any simple problem can be made insoluble if enough meetings are held to >>> discuss it." >>> -- Mitchell's Law of Committees >>> >>> >>> On 9 Sep 2012, at 22:58, Abdussalam Baryun >>> wrote: >>> >>>> Could we know as a WG, why this WG draft is changing many times while >>>> submitted? Please advise, >>>> >>>> AB >>>> >>>> On 9/9/12, internet-drafts@ietf.org wrote: >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Mobile Ad-hoc Networks Working Group >>>>> of >>>>> the IETF. >>>>> >>>>> Title : Definition of Managed Objects for the Neighborhood >>>>> Discovery Protocol >>>>> Author(s) : Ulrich Herberg >>>>> Robert G. Cole >>>>> Ian D Chakeres >>>>> Filename : draft-ietf-manet-nhdp-mib-19.txt >>>>> Pages : 67 >>>>> Date : 2012-09-09 >>>>> >>>>> Abstract: >>>>> This document defines a portion of the Management Information Base >>>>> (MIB) for use with network management protocols in the Internet >>>>> community. In particular, it describes objects for configuring >>>>> parameters of the Neighborhood Discovery Protocol (NHDP) process on a >>>>> router. The MIB module defined in this document, denoted NHDP-MIB, >>>>> also reports state, performance information and notifications about >>>>> NHDP. This additional state and performance information is useful to >>>>> troubleshoot problems and performance issues during neighbor >>>>> discovery. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-manet-nhdp-mib-19 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-mib-19 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> From ulrich@herberg.name Mon Sep 10 08:35:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BEA21F872A for ; Mon, 10 Sep 2012 08:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQEjyUhYviVc for ; Mon, 10 Sep 2012 08:35:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D809421F8723 for ; Mon, 10 Sep 2012 08:35:56 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so829855vbb.31 for ; Mon, 10 Sep 2012 08:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ROb/05DYEeGA1gRnPX4NfYBXZc9TTTMyEaSE13YHKpU=; b=ziy5b/DMshsAVyEUD9QO/75JgNGzqcVA4vdVnWjph4LfoY97x45X3QlKkHcTm68Dak x7c8wDVYFV8Idza8laNZ3KMJ6t2AP99HOmKIGw6Pku99RE4he0zFQuC2ADN+iLKtmrvk Vui4F0wi/jbBCuqr5RRK7ONreJRHLF8NdvOQ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ROb/05DYEeGA1gRnPX4NfYBXZc9TTTMyEaSE13YHKpU=; b=h01CKoY2p733SUupCO6xo2FFg+vBH9Xh090Aw6FfO9hzefHyoik4X509TGe9oktSCZ GVGUCA1TxE2S47RWNKwwU7/WkLdX1vvP8yOH9te3VZ1ExHerrc828Bm3O87xyCLcagiE 6OgBnlrCgI9U48OIAgwQg/22XJ/oDr27JL7XPqWRAexezIEpy7aVTLCcH9oqeXK2u+eb EuV1t8XuSraHqgxOMTNXKbAUsRGzdVyIzRsliYzhQiue9Jt9DPStidfZ5wlDqVLETV+J fm+X242N/h6vDLZDl4iPrurcRuOna/sjLPvOLexGUuzYAmDogW8vo2EngP65ZL2GKsd1 m+Dw== MIME-Version: 1.0 Received: by 10.58.12.7 with SMTP id u7mr21757965veb.8.1347291356513; Mon, 10 Sep 2012 08:35:56 -0700 (PDT) Received: by 10.58.187.78 with HTTP; Mon, 10 Sep 2012 08:35:56 -0700 (PDT) In-Reply-To: References: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> <040AA819-E123-4814-8B49-F3A37D80EDD7@thomasclausen.org> <25FB442A-F2A5-4382-9D8B-06CFF8C04728@thomasclausen.org> Date: Mon, 10 Sep 2012 08:35:56 -0700 Message-ID: From: Ulrich Herberg To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkot8o+XUV4lELbGUYyfPBH7HHI2Ki8A0YSUEwJZ+B7NMenp4py3bg3oPrifGsL2pf7+Bzk Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:35:57 -0000 +1 These discussions that concern the IETF process or the IESG really do not belong here. Best regards Ulrich On Mon, Sep 10, 2012 at 7:17 AM, Thomas Heide Clausen wrote: > Abdussalam, > > I think that this mailing-list is the wrong forum for discussing IETF/IESG procedural matters. > > Thomas > > -- > Thomas Heide Clausen > http://www.thomasclausen.org/ > > "Any simple problem can be made insoluble if enough meetings are held to > discuss it." > -- Mitchell's Law of Committees > > > On 10 Sep 2012, at 14:35, Abdussalam Baryun wrote: > >> Hi Thomas, >> >> I don't think it is efficient to have a draft in IESG for years, I >> don't accept that, however, comments below: >> >> On 9/10/12, Thomas Heide Clausen wrote: >>> Abdussalam, >>> >>> 1) A DISCUSS is held on a document, for as long as is needed for an AD to >>> verify that the >>> subject of his/her discuss is resolved. Note that this includes (often) >>> exchanging emails >>> between the AD and the authors (often, with these being in different >>> time-zones) so as >>> to understand how to resolve the discuss, for the authors to implement >>> whatever >>> necessary changes, for the AD to review the changes (and possibly >>> iterations over this for >>> as long as is needed). Occasionally, a DISCUSS is held for only hours, at >>> other times for >>> years - commonly, a DISCUSS lasts somewhere in between, depending on the >>> issue. >> >> A DISCUSS position should not be more that 90 days or maximum two ietf >> meeting periods. I recommend they create a new position named HOLD. >> >>> >>> 2) Often, but not always, authors work on one issue, resolve that one issue >>> in a revised version >>> of the document, then proceed to work on resolving the next issue (etc.) - >>> depending on >>> their available time, work-practices, when they manage to corner an AD, >>> etc. >>> >> That is fine and I think authors done well for NHDP-MIB, but I see the >> delay from IESG, that was the reason of my reply to the new version 19 >> post. >> >>> 3) ADs are not paid by the IETF either (just like everybody else aren't), >>> and have day-jobs to >>> attend to also. Rather than stress them, you should encourage them and >>> express >>> appreciation for their efforts. >> >> I always appreciate any effort we are equal in IETF, we all have full >> responsibilities and we all have taken our choice to participate and >> volunteer. If we cannot continue to volunteer more than 90 days then >> we should mention that and help to progress the work force not delay >> the work force more than 90 days (period of meetings) or maximum 180 >> days (the maximum is the period for expired drafts). I encourage all >> to respond as soon as possible so we don't forget issues or change our >> mind, I encourage both sides submitters and reviewers. >> >>> >>> 4) I suggest taking a good long look at >>> http://www.ietf.org/edu/tutorials.html especially >>> (but not exclusively) at >>> http://www.ietf.org/edu/process-oriented-tutorials.html >> >> I already done that before, I joined this organisation. Now I am >> trying to participate to make things go forward not just watch things >> happen without comments, >> >> -AB >> +++ >>> On 10 Sep 2012, at 11:59, Abdussalam Baryun >>> wrote: >>> >>>> Hi Ulrich, >>>> >>>> I just wanted to know why the DISCUSS is still there from July until >>>> now? I think you done well in the versions as adding [*], and why we >>>> still are making changes after -17 in many versions why not one only. >>>> I am interested that it goes through with known progress or known >>>> delay reasons. Furthermore, I will hope the draft will not stay in >>>> DISCUSS for more than 28 days, if it does I think the WG should know >>>> why. Thanking you, >>>> >>>> [*] http://www.ietf.org/mail-archive/web/manet/current/msg13168.html >>>> >>>> AB >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From iesg-secretary@ietf.org Mon Sep 10 09:05:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F70421F875A; Mon, 10 Sep 2012 09:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-tcqesskvrH; Mon, 10 Sep 2012 09:05:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351BE21F876E; Mon, 10 Sep 2012 09:05:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120910160544.23815.48554.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2012 09:05:44 -0700 Cc: manet chair , manet mailing list , RFC Editor Subject: [manet] Protocol Action: 'Definition of Managed Objects for the Neighborhood Discovery Protocol' to Proposed Standard (draft-ietf-manet-nhdp-mib-19.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:05:45 -0000 The IESG has approved the following document: - 'Definition of Managed Objects for the Neighborhood Discovery Protocol' (draft-ietf-manet-nhdp-mib-19.txt) as Proposed Standard This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ Technical Summary This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information and notifications about NHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. Working Group Summary The process for reaching working group consensus on this was smooth; no controversy existed. Working Group consensus behind the document is solid. Document Quality This document shepherd is not aware of existing implementations of this MIB although seveal implementers have indicated interest in the work. The responsible AD performed a detailed MIB review at publication request. A MIB Doctor review was requested in parallel to IETF last call, but was not forthcoming. The GenArt review by Joel Halpern was addressed in a new revision after IETF last call. The MIB Doctor review during IESG evaluationproduced a significant number of issues that were fixed in late revisions. Personnel Stan Ratliff (sratliff@cisco.com) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD From ietf@thomasclausen.org Mon Sep 10 09:32:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5AE21E8049 for ; Mon, 10 Sep 2012 09:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHG5UTonFp4b for ; Mon, 10 Sep 2012 09:32:36 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6956021E8047 for ; Mon, 10 Sep 2012 09:32:36 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 2447055835C for ; Mon, 10 Sep 2012 09:32:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 785DB1BDCA9F; Mon, 10 Sep 2012 09:32:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.10.10] (unknown [37.160.33.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8E48B1BDC61A; Mon, 10 Sep 2012 09:32:34 -0700 (PDT) References: <20120910160544.23815.48554.idtracker@ietfa.amsl.com> In-Reply-To: <20120910160544.23815.48554.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <129E1570-8899-45F1-929A-46BE7047C75E@thomasclausen.org> X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Mon, 10 Sep 2012 18:32:25 +0200 To: manet Cc: "Cole Robert G." Subject: Re: [manet] Protocol Action: 'Definition of Managed Objects for the Neighborhood Discovery Protocol' to Proposed Standard (draft-ietf-manet-nhdp-mib-19.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:32:41 -0000 Congrats, Bob, Ian and Ulrich - good job! Thomas On 10 Sep 2012, at 18:05, The IESG wrote: > The IESG has approved the following document: > - 'Definition of Managed Objects for the Neighborhood Discovery Protocol' > (draft-ietf-manet-nhdp-mib-19.txt) as Proposed Standard > > This document is the product of the Mobile Ad-hoc Networks Working Group. > > The IESG contact persons are Adrian Farrel and Stewart Bryant. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ > > > > > Technical Summary > > This document defines a portion of the Management Information Base > (MIB) for use with network management protocols in the Internet > community. > > In particular, it describes objects for configuring parameters of the > Neighborhood Discovery Protocol (NHDP) process on a router. The > MIB module defined in this document, denoted NHDP-MIB, also > reports state, performance information and notifications about NHDP. > This additional state and performance information is useful to > troubleshoot problems and performance issues during neighbor > discovery. > > Working Group Summary > > The process for reaching working group consensus on this > was smooth; no controversy existed. Working Group consensus > behind the document is solid. > > Document Quality > > This document shepherd is not aware of existing implementations > of this MIB although seveal implementers have indicated interest > in the work. > > The responsible AD performed a detailed MIB review at publication > request. A MIB Doctor review was requested in parallel to IETF last > call, but was not forthcoming. The GenArt review by Joel Halpern > was addressed in a new revision after IETF last call. > > The MIB Doctor review during IESG evaluationproduced a significant > number of issues that were fixed in late revisions. > > Personnel > > Stan Ratliff (sratliff@cisco.com) is the Document Shepherd. > Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jpmacker@gmail.com Mon Sep 10 13:26:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C0311E80D1 for ; Mon, 10 Sep 2012 13:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Lp4yCiNrJyN for ; Mon, 10 Sep 2012 13:26:50 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A58211E80CC for ; Mon, 10 Sep 2012 13:26:50 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2106134vcb.31 for ; Mon, 10 Sep 2012 13:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3NPI4rOOPu82Q8fxZ8owcMHUZcc2EyNZ9EW1CbXip+A=; b=b1H/elaYzfYDSYbEf1TPSxMOlrosN68HI6nJ2hRec5FgBAoJrySXF4aIgnYJh6yV/y XYKnedDfeByysu7ECZ30kRPv1qMXzLemSBuOZUJeAKaQ+9DvpRcPN+rdeqYFymXGMgYH BOSNS5S1Nrmz+UluUKOe/PPwcjIj6tneyBaqbRLsPcS7e7LN2vWXTvjWXpewljM7Dkff hY8T4nv8kcJHAe/vMroMVjb8Y1PepLc8AG9bHAf5xw+k3vBin1JeTRK9fQ+Log0K/vBv RVVhXYxuXBptSv0klc6t3UdTsVo3m2ok3w6F60zFWBxcxbVLTC20oOiU76mZGXlVvjW0 0Hmw== MIME-Version: 1.0 Received: by 10.52.24.139 with SMTP id u11mr17256563vdf.15.1347308809658; Mon, 10 Sep 2012 13:26:49 -0700 (PDT) Received: by 10.59.5.6 with HTTP; Mon, 10 Sep 2012 13:26:49 -0700 (PDT) In-Reply-To: <129E1570-8899-45F1-929A-46BE7047C75E@thomasclausen.org> References: <20120910160544.23815.48554.idtracker@ietfa.amsl.com> <129E1570-8899-45F1-929A-46BE7047C75E@thomasclausen.org> Date: Mon, 10 Sep 2012 16:26:49 -0400 Message-ID: From: Joseph Macker To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=bcaec501c57200a07904c95ec73b Cc: "Cole Robert G." , manet Subject: Re: [manet] Protocol Action: 'Definition of Managed Objects for the Neighborhood Discovery Protocol' to Proposed Standard (draft-ietf-manet-nhdp-mib-19.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 20:26:51 -0000 --bcaec501c57200a07904c95ec73b Content-Type: text/plain; charset=ISO-8859-1 Ditto. Well Done. On Mon, Sep 10, 2012 at 12:32 PM, Thomas Heide Clausen < ietf@thomasclausen.org> wrote: > Congrats, Bob, Ian and Ulrich - good job! > > Thomas > > On 10 Sep 2012, at 18:05, The IESG wrote: > > > The IESG has approved the following document: > > - 'Definition of Managed Objects for the Neighborhood Discovery Protocol' > > (draft-ietf-manet-nhdp-mib-19.txt) as Proposed Standard > > > > This document is the product of the Mobile Ad-hoc Networks Working Group. > > > > The IESG contact persons are Adrian Farrel and Stewart Bryant. > > > > A URL of this Internet Draft is: > > http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ > > > > > > > > > > Technical Summary > > > > This document defines a portion of the Management Information Base > > (MIB) for use with network management protocols in the Internet > > community. > > > > In particular, it describes objects for configuring parameters of the > > Neighborhood Discovery Protocol (NHDP) process on a router. The > > MIB module defined in this document, denoted NHDP-MIB, also > > reports state, performance information and notifications about NHDP. > > This additional state and performance information is useful to > > troubleshoot problems and performance issues during neighbor > > discovery. > > > > Working Group Summary > > > > The process for reaching working group consensus on this > > was smooth; no controversy existed. Working Group consensus > > behind the document is solid. > > > > Document Quality > > > > This document shepherd is not aware of existing implementations > > of this MIB although seveal implementers have indicated interest > > in the work. > > > > The responsible AD performed a detailed MIB review at publication > > request. A MIB Doctor review was requested in parallel to IETF last > > call, but was not forthcoming. The GenArt review by Joel Halpern > > was addressed in a new revision after IETF last call. > > > > The MIB Doctor review during IESG evaluationproduced a significant > > number of issues that were fixed in late revisions. > > > > Personnel > > > > Stan Ratliff (sratliff@cisco.com) is the Document Shepherd. > > Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --bcaec501c57200a07904c95ec73b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ditto. Well Done.

On Mon, Sep 10, 2012 at= 12:32 PM, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:
Congrats, Bob, Ian and Ulrich - good job!
Thomas

On 10 Sep 2012, at 18:05, The IESG <iesg-secretary@ietf.org> wrote:

> The IESG has approved the following document:
> - 'Definition of Managed Objects for the Neighborhood Discovery Pr= otocol'
> =A0(draft-ietf-manet-nhdp-mib-19.txt) as Proposed Standard
>
> This document is the product of the Mobile Ad-hoc Networks Working Gro= up.
>
> The IESG contact persons are Adrian Farrel and Stewart Bryant.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mi= b/
>
>
>
>
> Technical Summary
>
> =A0 This document defines a portion of the Management Information Base=
> =A0 (MIB) for use with network management protocols in the Internet > =A0 community.
>
> =A0 In particular, it describes objects for configuring parameters of = the
> =A0 Neighborhood Discovery Protocol (NHDP) process on a router. =A0The=
> =A0 MIB module defined in this document, denoted NHDP-MIB, also
> =A0 reports state, performance information and notifications about NHD= P.
> =A0 This additional state and performance information is useful to
> =A0 troubleshoot problems and performance issues during neighbor
> =A0 discovery.
>
> Working Group Summary
>
> =A0 The process for reaching working group consensus on this
> =A0 was smooth; no controversy existed. Working Group consensus
> =A0 behind the document is solid.
>
> Document Quality
>
> =A0 This document shepherd is not aware of existing implementations > =A0 of this MIB although seveal implementers have indicated interest > =A0 in the work.
>
> =A0 The responsible AD performed a detailed MIB review at publication<= br> > =A0 request. A MIB Doctor review was requested in parallel to IETF las= t
> =A0 call, but was not forthcoming. The GenArt review by Joel Halpern > =A0 was addressed in a new revision after IETF last call.
>
> =A0 The MIB Doctor review during IESG evaluationproduced a significant=
> =A0 number of issues that were fixed in late revisions.
>
> Personnel
>
> =A0 Stan Ratliff (sratliff@cisco= .com) is the Document Shepherd.
> =A0 Adrian Farrel (adrian@olddo= g.co.uk) is the Responsible AD
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--bcaec501c57200a07904c95ec73b-- From abdussalambaryun@gmail.com Tue Sep 11 03:09:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41D21F8769 for ; Tue, 11 Sep 2012 03:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7M3yuPEZYRw for ; Tue, 11 Sep 2012 03:09:26 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFBC921F875B for ; Tue, 11 Sep 2012 03:09:25 -0700 (PDT) Received: by ieak13 with SMTP id k13so640443iea.31 for ; Tue, 11 Sep 2012 03:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fPkRrf5T1PeRcV+sQFa+lsIf8X3m6+/s8DWiMVRSFKY=; b=DOItQXraE5ko3ffhVWOV3mzf4iguwyPY9bqJ17j1I3IuGuEqbVmKclmAlxpjrap8sd h/BwkbZxrGHnX1ADT+r320XxuJAKMvls1Edjt9jJdEjwY8qkfCSzn8YQRELxsSbCgY7g UIPexPaPGeNkj5eZ2kpRZwTpyXZRY5aUaMjcvJfoW3YP7yBbf2HCtztq7o931y97pHAW migLe917TPte4i9J6TTQ5EbW9ca+0AFWNyFnXOi97WLuGLHsuighHCtABL896zQ+zIBJ qxffz2RZ3oyZCtirkFxto9QvOP4kHQFDiVfZYPZFUC9Ua0+/v6BSGFquqbl94m4gd3he G4WA== MIME-Version: 1.0 Received: by 10.50.152.243 with SMTP id vb19mr16290413igb.4.1347358165545; Tue, 11 Sep 2012 03:09:25 -0700 (PDT) Received: by 10.64.37.9 with HTTP; Tue, 11 Sep 2012 03:09:25 -0700 (PDT) In-Reply-To: References: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> <040AA819-E123-4814-8B49-F3A37D80EDD7@thomasclausen.org> <25FB442A-F2A5-4382-9D8B-06CFF8C04728@thomasclausen.org> Date: Tue, 11 Sep 2012 12:09:25 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 10:09:26 -0000 Happy to know that the DISCUSS position was changed now after my comments/reminder. Please note that I can comment on the draft process as long as you posted it to the list or as long as it has a DISCUSS position to follow up with the authors maybe they need help/volunteers. My comment was on the progress of the NHDP-MIB draft process which it is a WG draft, so I am involved and following up with the draft, if there is a mistake in that I advise the chair to inform me of such mistake not any participant. AB From abdussalambaryun@gmail.com Tue Sep 11 03:32:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9AC21F87AD for ; Tue, 11 Sep 2012 03:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+w1YJ2NSag0 for ; Tue, 11 Sep 2012 03:32:17 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C80EE21F87A8 for ; Tue, 11 Sep 2012 03:32:17 -0700 (PDT) Received: by ieak13 with SMTP id k13so675832iea.31 for ; Tue, 11 Sep 2012 03:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wgg4Rmbl+N2iaC15CDZ7hZnO17zKnb19rF6sNO1dc1E=; b=C7CE3Rphlm2yGEdE3kWkd6/eZxEf33qpuxgd9pwA3I3GQS3UeCZg4s4NGs5+Z9JNVF GhYIxmjRLpQvdMhIgoo21IsHVJtBr0BT36u0Cl++I6eAvIq3/EPGN+pThqddp7EmtIFJ 9MfjgGzxcBOxMIUhC4QE8YclDlgE99Rb51BbpW9/XzUXvymDrzBKb6N25md/lwGOgZAr 73GIXi9/fukX6Ofg7Oj/iS49c9trfUpISAhggeD6Cfs5AvVOU2YbhwsPzfgv3Xelm8pL PKJgaIEe2ghba/gs1Toy0CBkMO/x08GzfIOVCF4t4IOHr663Oba85bATm+Mg46PfDd1r ud2A== MIME-Version: 1.0 Received: by 10.50.41.169 with SMTP id g9mr16451242igl.4.1347359537409; Tue, 11 Sep 2012 03:32:17 -0700 (PDT) Received: by 10.64.37.9 with HTTP; Tue, 11 Sep 2012 03:32:17 -0700 (PDT) In-Reply-To: References: <20120910160544.23815.48554.idtracker@ietfa.amsl.com> <129E1570-8899-45F1-929A-46BE7047C75E@thomasclausen.org> Date: Tue, 11 Sep 2012 12:32:17 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Protocol Action: 'Definition of Managed Objects for the Neighborhood Discovery Protocol' to Proposed Standard (draft-ietf-manet-nhdp-mib-19.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 10:32:18 -0000 Congratulations to Ulrich, Robert, Ian, and the MANET WG, Regards AB From sratliff@cisco.com Tue Sep 11 06:51:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C3621F85F7 for ; Tue, 11 Sep 2012 06:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-vjdj2xX4uA for ; Tue, 11 Sep 2012 06:51:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7F85821F84AF for ; Tue, 11 Sep 2012 06:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=849; q=dns/txt; s=iport; t=1347371504; x=1348581104; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y2wohTDoLJwgFqwl3iFSLh164KM5tB4JDAFgGC1TxfM=; b=I82TdaYjLGfY4gaLNYr/Y3xk+UsSydC5wXcqXSoDjwfXsYAHo8Ql9d8h y0su2d627YAKYwOmRhD4zv/d/qbMOU/7VRm1L9eItX6dKWuW/IDD6khhh l4pCrLw0x3npQYwezFVyMrJLBNOpaFIpq1YMkHiitfwuX8wiOpfgANff5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAF9BT1CtJXG8/2dsb2JhbABFhUC2EIEHgiABAQEDAQEBAQ8BJzQLBQsCAQg2ECcLJQIEDgUih2gGC5s5oEYEixCFRmADlV2ONoFngmY X-IronPort-AV: E=Sophos;i="4.80,404,1344211200"; d="scan'208";a="120391773" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 11 Sep 2012 13:51:43 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8BDphBQ032197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Sep 2012 13:51:43 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.113]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Tue, 11 Sep 2012 08:51:43 -0500 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt Thread-Index: AQHNkAWFRCwEXl4Dq0SGsbNYlqF8A5eFfO4A Date: Tue, 11 Sep 2012 13:51:43 +0000 Message-ID: <8125C09A-E940-4AFB-A3F5-24CCB293A92B@cisco.com> References: <20120909165421.30559.9494.idtracker@ietfa.amsl.com> <040AA819-E123-4814-8B49-F3A37D80EDD7@thomasclausen.org> <25FB442A-F2A5-4382-9D8B-06CFF8C04728@thomasclausen.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.110] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19176.006 x-tm-as-result: No--28.400500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-mib-19.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 13:51:47 -0000 On Sep 11, 2012, at 6:09 AM, Abdussalam Baryun wrote: > Happy to know that the DISCUSS position was changed now after my > comments/reminder. Please note that I can comment on the draft process > as long as you posted it to the list or as long as it has a DISCUSS > position to follow up with the authors maybe they need > help/volunteers. >=20 > My comment was on the progress of the NHDP-MIB draft process which it > is a WG draft, so I am involved and following up with the draft, if > there is a mistake in that I advise the chair to inform me of such > mistake not any participant. OK, from a co-chair: This is the wrong list for issues on the IESG process.= =20 Stan >=20 > AB > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From jorgenavarro@ugr.es Wed Sep 12 09:50:00 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F42721F85A3 for ; Wed, 12 Sep 2012 09:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-Sv0uUQfK8Q for ; Wed, 12 Sep 2012 09:49:59 -0700 (PDT) Received: from mail4.ugr.es (mail4.ugr.es [150.214.35.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA9E21F85A2 for ; Wed, 12 Sep 2012 09:49:58 -0700 (PDT) Received: from smtp3.ugr.es (smtp3.ugr.es [150.214.20.71]) by mail4.ugr.es (Postfix) with ESMTP id 4CDD59A for ; Wed, 12 Sep 2012 18:49:51 +0200 (CEST) Received: from JorgePC (lawn-143-215-118-105.lawn.gatech.edu [143.215.118.105]) by smtp3.ugr.es (Postfix) with ESMTP id 89BDA3C806 for ; Wed, 12 Sep 2012 18:49:49 +0200 (MEST) From: "Jorge Navarro Ortiz" To: Date: Wed, 12 Sep 2012 12:49:45 -0400 Message-ID: <005601cd9106$9ebde9d0$dc39bd70$@ugr.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01CD90E5.17B06880" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2RBpzYmUWBQ60fSwuwFXarjFFbrg== Content-Language: es Subject: [manet] CALL FOR WORKSHOP PROPOSALS WoWMoM 2013 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:50:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0057_01CD90E5.17B06880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ------------------------------------------------------------------------ CALL FOR WORKSHOP PROPOSALS WoWMoM 2013 Fourteenth International Symposium on a World of Wireless, Mobile and Multimedia Networks http://www.ieee-wowmom.org/ sponsored by IEEE Computer Society, University of Texas at Arlington, IEEE Computer Society TC on Computer Communications (TCCC) June 4-7, 2013 (tentative) Madrid, Spain ------------------------------------------------------------------------ The next IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (IEEE WoWMoM 2013) will be the 14th event in its series. This symposium intends to provide a definitive forum for networking, software systems and multimedia research in the wireless/mobile area involving both computer science and electrical engineering communities. The WoWMoM Organizing Committee invites proposals for *one-day* workshops affiliated with the conference. The purpose of these workshops is to provide a platform for presenting novel ideas in a less formal and possibly more focused way than at the conference itself. All papers included in the WoWMoM 2013 Workshops will appear in the conference proceedings published by IEEE. We expect all selected workshops to adhere to a common paper submission and reviewing schedule as outlined in the dates indicated below. Workshops Proposals are solicited in all areas and topics pertaining to wireless mobile and multimedia networking. Workshops addressing emerging research directions in these areas are highly welcome. Each workshop proposal must include: * The name of the workshop. * The names, addresses, and a short bio of the organizers. * A brief description (up to 1 page) of the technical issues that the workshop will address, and the reasons why the workshop is of interest at this time. * The names of potential program committee members. * The planned format of the workshop, including a strategy to facilitate lively discussions and attendees involvement. * The names of the potential keynote speakers, if a keynote speech is included in the planned format of the workshop. * If applicable, a description of past versions of the workshop, including dates, organizers, number of submitted and accepted papers, number of attendees. * If the workshop does not have any past editions, an estimate of the expected number of submitted and accepted papers, and of the expected number of attendees. * A tentative call for papers. * A description of the plans for publicity and workshop web site. * * Workshop proposals should be submitted, no later than October 20, 2012, by e-mail (in PDF format) with "WoWMoM 2013 Workshop Proposal" in the subject, to *both* WoWMoM 2013 Workshop Co-Chairs (WSCC) at the addresses: mlabrador@usf.edu polk@telecom.tuc.gr For any additional information please refer to us at the addresses above. Workshops Co-chairs Miguel A. Labrador Dept. of Computer Science and Engineering University of South Florida Tampa, Florida and Polychronis Koutsakis ECE Dept. Technical University of Crete Chania, Greece ---------------- IMPORTANT DATES ---------------- Workshop proposals submission deadline: October 20, 2012 Notification: November 05, 2012 Suggested dates for the workshops schedule: Papers due by: February 28, 2013 Paper selections due by: April 08, 2013 ------=_NextPart_000_0057_01CD90E5.17B06880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

------------------------------------------------------------= ------------

 

CALL = FOR WORKSHOP PROPOSALS

 

WoWMoM = 2013

 

Fourteenth International Symposium on a World of Wireless, = Mobile and Multimedia Networks

 

http://www.ieee-wowmom.org/=

 

sponsored by

 

IEEE = Computer Society,

University of Texas at = Arlington,

IEEE Computer Society = TC on Computer Communications (TCCC)

 

June = 4-7, 2013 (tentative)

 

Madrid, = Spain

 

------------------------------------------------------------= ------------

 

 

The next IEEE International = Symposium on a World of Wireless, Mobile and Multimedia Networks (IEEE = WoWMoM 2013) will be the 14th event in its series. This = symposium intends to provide a definitive forum for networking, software = systems and multimedia research in the wireless/mobile area involving = both computer science and electrical engineering = communities.

 

The WoWMoM Organizing Committee = invites proposals for *one-day* workshops affiliated with the = conference. The purpose of these workshops is to provide a platform for = presenting novel ideas in a less formal and possibly more focused way = than at the conference itself. All papers included in the WoWMoM 2013 = Workshops will appear in the conference proceedings published by IEEE. = We expect all selected workshops to adhere to a common paper submission = and reviewing schedule as outlined in the dates indicated = below.

 

Workshops Proposals are = solicited in all areas and topics pertaining to wireless mobile and = multimedia networking.

 

Workshops addressing emerging = research directions in these areas are highly = welcome.

 

Each workshop proposal must = include:

 

  • The name of the = workshop.
  • The names, = addresses, and a short bio of the = organizers.
  • A brief = description (up to 1 page) of the technical issues that the workshop = will address, and the reasons why the workshop is of interest at this = time.
  • The names of = potential program committee members.
  • The planned format of the workshop, including a strategy to = facilitate lively discussions and attendees = involvement.
  • The names of the = potential keynote speakers, if a keynote speech is included in the = planned format of the workshop.
  • If applicable, a description of past versions of the = workshop, including dates, organizers, number of submitted and accepted = papers, number of attendees.
  • If the workshop does not have any past editions, an = estimate of the expected number of submitted and accepted papers, and of = the expected number of attendees.
  • A tentative call for papers.
  • A description of the plans for publicity and workshop web = site.
  •  
  •  

Workshop proposals should be = submitted, no later than October 20, 2012, by e-mail (in PDF format) = with "WoWMoM 2013 Workshop Proposal" in the subject, to *both* = WoWMoM 2013 Workshop Co-Chairs (WSCC) at the = addresses:

 

mlabrador@usf.edu=

polk@telecom.tuc.gr

 

 

For any additional information = please refer to us at the addresses above.

 

 

Workshops Co-chairs =

 

Miguel A. = Labrador

Dept. of Computer Science and = Engineering

University of South Florida

Tampa, = Florida

 

and

 

Polychronis = Koutsakis

ECE Dept.

Technical University of = Crete

Chania, Greece

 

 

----------------

 

IMPORTANT = DATES

 

----------------

 

 

Workshop proposals submission = deadline:  October 20, 2012

 

Notification: November 05, = 2012

 

 

Suggested dates for the = workshops schedule:

 

Papers due by:  February = 28, 2013

 

Paper selections due = by:       April 08, = 2013

 

 

 

------=_NextPart_000_0057_01CD90E5.17B06880-- From alessandra.depaola@unipa.it Fri Sep 14 03:29:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7B21F8587 for ; Fri, 14 Sep 2012 03:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.097 X-Spam-Level: X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHtY9VO69ytb for ; Fri, 14 Sep 2012 03:29:45 -0700 (PDT) Received: from smtp-out.unipa.it (smtp-out.unipa.it [147.163.2.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9966421F8585 for ; Fri, 14 Sep 2012 03:29:43 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (authenticated bits=0) by smtp-out.unipa.it (8.14.4/8.14.4) with ESMTP id q8EATeWq011765 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 14 Sep 2012 12:29:41 +0200 Received: by qcac10 with SMTP id c10so3130261qca.31 for ; Fri, 14 Sep 2012 03:29:40 -0700 (PDT) Received: by 10.229.105.100 with SMTP id s36mr1441765qco.88.1347618580271; Fri, 14 Sep 2012 03:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.131.40 with HTTP; Fri, 14 Sep 2012 03:29:20 -0700 (PDT) From: Alessandra De Paola Date: Fri, 14 Sep 2012 12:29:20 +0200 Message-ID: To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] PerSeNS 2013: Call for Paper X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 10:29:45 -0000 ------------------------------------------------------------------------------------ ----------Apologies for multiple copies of this announcement--------- ------------------------------------------------------------------------------------ The Ninth IEEE PerCom International Workshop on Sensor Networks and Systems for Pervasive Computing (PerSeNS 2013) http://www.dicgim.unipa.it/~networks/persens2013/ in conjunction with IEEE PerCom 2013 (http://www.percom.org) March 18-22, 2013 San Diego, California ---------------------------------------------------------------------- CALL FOR PAPERS Wireless sensor networks collect sensing measurements or detect special events, perform node-level processing, and export the combined data from their sensing nodes to the outside world. Sensing, processing and communication are three key elements whose combination in one small device is instrumental to pervasive computing and gives rise to countless applications. This workshop will provide a forum to exchange ideas, discuss solutions, and share experiences among researchers and professionals from industry and academia. Papers describing original research on both theoretical and practical aspects of sensor networks for pervasive computing are solicited. We particularly welcome submissions that present implementation and deployment results. Particular topics of interest include, but are not limited to: - Sensor-based systems and applications - Operating systems for Sensor Networks - Middleware and software tools - Networking architectures and protocols - Data gathering, aggregation and dissemination - Topology control - Power Management and energy-efficient design - Time synchronization - Location management - Sensor networks with mobile elements - Cross-layer architectures - Intelligent sensor nodes - Security and dependability issues - Modeling and performance evaluation - Measurements EDITORIAL FOLLOW UP Papers of particular merit will be considered for a possible special issue in an international journal. PAPER SUBMISSION Papers should contain original material and not be previously published, or currently submitted for consideration elsewhere. Papers must be submitted in PDF format. Maximum length: 6 pages. Papers must be prepared using the template available at the following page: http://www.computer.org/portal/web/cscps/formatting/ All submissions will be handled via EDAS. Accepted papers will be published by the IEEE Computer Society Press in the combined PerCom 2013 workshops proceedings. At least one author of each accepted paper must register and attend the workshop to present the paper. There is no workshop-only registration. Failure to present the paper at the workshop will result in the withdrawal of the paper from the Proceedings as well as from IEEE Xplore. IMPORTANT DATES Paper submission deadline: October 30, 2012 Notification of acceptance: December 21, 2012 Camera-ready papers due: January 25, 2013 GENERAL CO-CHAIRS Giuseppe Anastasi, University of Pisa, Italy Silvia Giordano, University of Applied Sciences of Southern Switzerland (SUPSI), Switzerland PROGRAM CHAIR Giuseppe Lo Re, University of Palermo, Italy PUBLICITY CHAIR Alessandra De Paola, University of Palermo, Italy TECHNICAL PROGRAM COMMITTEE TBA From abdussalambaryun@gmail.com Thu Sep 20 09:46:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F7821F86AA for ; Thu, 20 Sep 2012 09:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVRCxNr5i-60 for ; Thu, 20 Sep 2012 09:46:17 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8405F21F847C for ; Thu, 20 Sep 2012 09:46:17 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so3049644vbb.31 for ; Thu, 20 Sep 2012 09:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9LJiGusJsogYyCWTDr8aTYYnTDzuX5dNAtijPPFe2QM=; b=hNm9bis4GE9FH7NBSu+IHB+AsA5SAIFFD7vjeP6BreKKQP1iIoRo44O61lwMoVXytH 3wZjvpJNQQhygiCGC3zlN7/+gyWVWYfEZnLQU2Tt0L8IHG03xHjciagmWrbm2dsfXjug vckbGaDepNFsG7ulEYnSo9PPtDIGgEckWxZrSamWSJD5dXfUp2Np0mwcffudfiAZfLcy 0SaoLxmjjJisBdYDwyyBWrYwxzGvRqy4knNrJH9w15udLOooQ5OwKYlOqt6Zkfs2KUzZ Bqek/W+M+4Enxm+Y854k4fTxsPHQ9FfsxswzI+Mq6GYFw3Qg0B8Yr7AYuzTbr3gfHeIr Q2lw== MIME-Version: 1.0 Received: by 10.52.93.1 with SMTP id cq1mr1087460vdb.125.1348159576936; Thu, 20 Sep 2012 09:46:16 -0700 (PDT) Received: by 10.220.2.83 with HTTP; Thu, 20 Sep 2012 09:46:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Sep 2012 17:46:16 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=20cf307cfbbcaf126904ca24dc2d Subject: Re: [manet] Route Metric Type Consideration for MANET Routers X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 16:46:18 -0000 --20cf307cfbbcaf126904ca24dc2d Content-Type: text/plain; charset=ISO-8859-1 The reply to the subject comments; http://www.ietf.org/mail-archive/web/manet/current/msg13415.html --20cf307cfbbcaf126904ca24dc2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The reply to the subject comments;
=A0
=A0
--20cf307cfbbcaf126904ca24dc2d-- From abdussalambaryun@gmail.com Fri Sep 21 10:30:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6890521F875C for ; Fri, 21 Sep 2012 10:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unPmBkpJ+nXv for ; Fri, 21 Sep 2012 10:30:15 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C080B21F84FA for ; Fri, 21 Sep 2012 10:30:15 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4561952vcb.31 for ; Fri, 21 Sep 2012 10:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z5IB9qDH0U2yeEbzRuqWlBp5GrGzzOSvC67ZiypuDyg=; b=c1FPVvLlUJ+N5G1lxjjJhPfjdabtGVy1Kk9UL8S4brLhGQYeS22Zq/VdP9Dlt/8nyB xPRboHq9OwlrnuVAkNhF/kMX6X7+5G7Bb7yaoZcOFuzZIC6YlBnNnFOEmm8QoB/HWJav uphElWaPnbANxp6ZwNCEO8ME0aO1lnKVC9+j3cosbE3l+bkz1qYvsyKpO0nwznzBpXM+ EjJ0sAOUfbuZQXSohvcftxAJlqvpkjx2APOYqbplKbW2W7sVK/MHzy4Bl6a0wPDCGKDA OCaw1jWqQMAq5KBMVvi+k7Tdy31GiNa+I6ewi1fMYfp14kVue5Hnd4c+Rksgb7crBsvY nRfQ== MIME-Version: 1.0 Received: by 10.220.119.198 with SMTP id a6mr3409563vcr.23.1348248615158; Fri, 21 Sep 2012 10:30:15 -0700 (PDT) Received: by 10.220.2.83 with HTTP; Fri, 21 Sep 2012 10:30:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Sep 2012 18:30:15 +0100 Message-ID: From: Abdussalam Baryun To: ietf@jiaziyi.com Content-Type: multipart/alternative; boundary=bcaec54fb624c682ac04ca39976a Cc: manet@ietf.org Subject: Re: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 17:30:16 -0000 --bcaec54fb624c682ac04ca39976a Content-Type: text/plain; charset=ISO-8859-1 AB On Tue, Jul 31, 2012 at 5:40 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Jiazi > > I already send my feedback before [1 -2] which had no respond/comment > from authors. I think any comment should be responded to by authors of > I-Ds or RFCs. I think that we need more discussions responds/comments > from the group before last call regarding this I-D. > > Regards > AB > > [1] http://www.ietf.org/mail-archive/web/manet/current/msg12899.html > [2] http://www.ietf.org/mail-archive/web/manet/current/msg13234.html > =================================================== > > > I apologize to Jiazi and co-authors as we accidentally skipped one of > > the slide sets at this afternoon's meeting. > > > > Please review the slides for NHDP-sec-threats located at > > http://tools.ietf.org/wg/manet/agenda > > and see draft-ietf-manet-nhdp-sec-threats-00 > > > > The authors are asking for consideration of WG LAST CALL on this > > document so please comment. > > > > -Joe > > > --bcaec54fb624c682ac04ca39976a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<second reminder>
AB
On Tue, Jul 31, 2012 at 5:40 AM, Abdussalam Bary= un <abdussalambaryun@gmail.com> wrote:
Hi Jiazi

I already send my fee= dback before [1 -2] which had no respond/comment
from authors. I think a= ny comment should be responded to by authors of
I-Ds or RFCs. I think that we need more discussions responds/comments
fr= om the group before last call regarding this I-D.

Regards
AB
<= br>[1] http://www.ietf.org/mail-archive/web/manet/curre= nt/msg12899.html
[2] http://www.ietf.org/mail-archive/web/manet/current/= msg13234.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

> I apologize to Jiazi and co-authors as we accidentally skipped one= of
> the slide sets at this afternoon's meeting.
>
>= Please review the slides for NHDP-sec-threats located at
> http://tools.i= etf.org/wg/manet/agenda
> and see draft-ietf-manet-nhdp-sec-threats-00
>
> The autho= rs are asking for consideration of WG LAST CALL on this
> document so= please comment.
>
> -Joe
>

--bcaec54fb624c682ac04ca39976a-- From yi.jiazi@gmail.com Fri Sep 21 22:46:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED18C21F880F for ; Fri, 21 Sep 2012 22:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqlEVQIYXG5d for ; Fri, 21 Sep 2012 22:46:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0474F21F87E6 for ; Fri, 21 Sep 2012 22:46:03 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so6592180pbb.31 for ; Fri, 21 Sep 2012 22:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=uc+skdSfVxfdeYlwMNQ82cGSpUy0wN2Xo1o+r1kQymM=; b=Nd3yIsoj5cKo9l1apWeWdP3b4a0LbTVmaN+3LEE9Nm5BU4XqtuckSVz1/MBSd6MmZV ndYc36byf3CBOkaDeB3nobAWvNo8X41x8LhVxSdExzMhYd1ZNX7/7vSDjGDd743pTeVs pKvqTfzQcb8TRcBxyPaqjybCfLNB104w/af+x629Yrbgkj2v64At13RtgQolNL7DP2ig x0Pf6UlN7rDG7rA7Z5hvLpV12/Z4213m6gG2YUfLUBOnU9yFvzFjNSCeiHQui3TR6ETO wvI7Y2x2GHxyHDv4jgCFF2Fg6NE0FmdWA6yGhRQwqnoOnfeUL7S0IJJUdYu9eTKorT75 gMsg== Received: by 10.68.242.10 with SMTP id wm10mr20862827pbc.61.1348292762616; Fri, 21 Sep 2012 22:46:02 -0700 (PDT) Received: from [172.31.12.38] ([218.242.163.130]) by mx.google.com with ESMTPS id ox5sm6187006pbc.75.2012.09.21.22.46.00 (version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 22:46:01 -0700 (PDT) Sender: Jiazi YI Content-Type: multipart/alternative; boundary="Apple-Mail=_CB962F7F-A933-455B-98D2-2A3A3D8998EA" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Jiazi YI In-Reply-To: Date: Sat, 22 Sep 2012 13:46:02 +0800 Message-Id: <35BC7EAA-345B-46B4-A18B-8F1D27E61BD1@jiaziyi.com> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1486) Cc: manet@ietf.org Subject: Re: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 05:46:10 -0000 --Apple-Mail=_CB962F7F-A933-455B-98D2-2A3A3D8998EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi,=20 regarding your previous comments: > In general, both common and interaction attacks need to be documented > per protocol, it is more useful to have the scope of protocol's > vulnerability without excluding common network attacks and issues. Any > additional attacks should be considered, otherwise the document scope > section should specify if it excludes something. I don't see the need of including all the common threats to network in = this nhdp-sec-threat document is necessary, except the threats that have = particular impact to the ndhp mechanism. The redundancy should be = reduced.=20 We can have some text on the scope at the beginning.=20 > I RECOMMEND that the draft [nhdp-threats] includes [nhdp-sec] in its > normative references and to include abstract information of > discussions [1- 3] into [nhdp-threats] and/or [nhdp-sec]. No. It's the nhdp-sec that has a reference to nhdp-sec-threats.=20 best Jiazi On Sep 22, 2012, at 1:30 AM, Abdussalam Baryun = wrote: > > AB > On Tue, Jul 31, 2012 at 5:40 AM, Abdussalam Baryun = wrote: > Hi Jiazi >=20 > I already send my feedback before [1 -2] which had no respond/comment > from authors. I think any comment should be responded to by authors of > I-Ds or RFCs. I think that we need more discussions responds/comments > from the group before last call regarding this I-D. >=20 > Regards > AB >=20 > [1] http://www.ietf.org/mail-archive/web/manet/current/msg12899.html > [2] http://www.ietf.org/mail-archive/web/manet/current/msg13234.html > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > > I apologize to Jiazi and co-authors as we accidentally skipped one = of > > the slide sets at this afternoon's meeting. > > > > Please review the slides for NHDP-sec-threats located at > > http://tools.ietf.org/wg/manet/agenda > > and see draft-ietf-manet-nhdp-sec-threats-00 > > > > The authors are asking for consideration of WG LAST CALL on this > > document so please comment. > > > > -Joe > > >=20 --Apple-Mail=_CB962F7F-A933-455B-98D2-2A3A3D8998EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 regarding = your previous comments:
In general, both common and interaction =
attacks need to be documented
per protocol, it is more useful to have the scope of protocol's
vulnerability without excluding common network attacks and issues. Any
additional attacks should be considered, otherwise the document scope
section should specify if it excludes =
something.
I don't see the need of including all = the common threats to network in this nhdp-sec-threat document is = necessary, except the threats that have particular impact to the ndhp = mechanism. The redundancy should be reduced. 
We can have = some text on the scope at the = beginning. 

abdussalambaryun@gmail.com&=
gt; wrote:

<second reminder>
AB
On Tue, Jul 31, 2012 at 5:40 AM, Abdussalam = Baryun <abdussalambaryun@gmail.com> wrote:
Hi Jiazi

I already = send my feedback before [1 -2] which had no respond/comment
from = authors. I think any comment should be responded to by authors of
I-Ds or RFCs. I think that we need more discussions = responds/comments
from the group before last call regarding this = I-D.

Regards
AB

[1] http://www.ietf.org/mail-archive/web/manet/current/msg12= 899.html
[2] http://www.ietf.org/mail-archive/web/manet/current/msg13= 234.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

> I apologize to Jiazi and co-authors as we accidentally skipped = one of
> the slide sets at this afternoon's = meeting.
>
> Please review the slides for NHDP-sec-threats = located at
> http://tools.ietf.org/wg/manet/agenda
> and see draft-ietf-manet-nhdp-sec-threats-00
>
> The = authors are asking for consideration of WG LAST CALL on this
> = document so please comment.
>
> = -Joe
>


= --Apple-Mail=_CB962F7F-A933-455B-98D2-2A3A3D8998EA-- From henning.rogge@fkie.fraunhofer.de Mon Sep 24 06:00:47 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B2C21F84F3 for ; Mon, 24 Sep 2012 06:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[AWL=-2.216, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgB+GxhjfBWQ for ; Mon, 24 Sep 2012 06:00:46 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 2770421F8686 for ; Mon, 24 Sep 2012 06:00:46 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TG8HF-0006mK-0V for manet@ietf.org; Mon, 24 Sep 2012 15:00:45 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1TG8HE-000339-U7 for manet@ietf.org; Mon, 24 Sep 2012 15:00:44 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Sep 2012 15:00:44 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 24 Sep 2012 15:00:44 +0200 Message-ID: <50605977.5080006@fkie.fraunhofer.de> Date: Mon, 24 Sep 2012 15:00:39 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080707040008040409010001" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 24 Sep 2012 13:00:44.0754 (UTC) FILETIME=[9BECF320:01CD9A54] X-Virus-Scanned: yes (ClamAV 0.97.5/15395/Mon Sep 24 12:59:29 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2373b5e69b5e37e3efcc60d711afffcb Subject: [manet] Looking for NHDP open source implementation for interop test X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 13:00:47 -0000 --------------ms080707040008040409010001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I am currently testing my NHDP implementation and looking for another=20 open source implementation for a small interop test. Does someone has a=20 link to an implementation that compiles with Linux and is RFC6130 complia= nt? Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms080707040008040409010001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA5MjQxMzAwNDJaMCMGCSqGSIb3DQEJBDEWBBRRni8XC591ksgGdtfT+kJP2Mj06jBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAKeKQHuXhgj66T4et9qev+jMOM742+0EhX4pj9fXN/kNr soL0gcA2f8dmFY/8xSbn1MKJ6oIoFwBeubq8yKE0av+YyCVaeBe+sSKBHJY+f3dWvCXCm0i9 PEVYqHF4TQovjgmbzkyamKyzTy+Ca7LSDNlskGjku8qtbba4p1s9yYCxly/dkSeDckPlUune BgbcMJgeeE7Mm0aOtkM+dz9aSN3NAS86CtNhio63Jtfv3Kt5dhX1JsxxDDqRdsHiUe5gXmm5 Rj2nHSeQRShgipbdKzMpq8x9X9pd8eL/luuY7YbgVWVEggGjO5b+pQWoFFF1uT6M1+CQaIt7 6Nx4YWp2JgAAAAAAAA== --------------ms080707040008040409010001-- From ulrich@herberg.name Mon Sep 24 10:08:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5557021F881E for ; Mon, 24 Sep 2012 10:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmnquy9vl69f for ; Mon, 24 Sep 2012 10:08:41 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F80821F881A for ; Mon, 24 Sep 2012 10:08:41 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so6985000vbb.31 for ; Mon, 24 Sep 2012 10:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8qKJcl2TahwhiyT4+1+SvtgEMvF1liHGYG7/XN9lM9A=; b=JPZGdJLaQE3ajmBlFEu7Z0jCgdcXaot/ChWYcyHWdHJZVVD3TPqB5fOJiOTduBLnZF KIbaNIwXIfpDbjyZmQY2xo52Ql4po44FlI6IfZsUCCx2PdqQZkyWRbjxEjGkG3l7cFWu vqIPbm7TbpdJCNluUcHRbJfUPcKw9QSHeWzWo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=8qKJcl2TahwhiyT4+1+SvtgEMvF1liHGYG7/XN9lM9A=; b=YdEoo7rdENitmNhscwL2vinM5BRX0/suCqEmZTJoAWl+DeRsZOWvSfDPV8lTPrQ+dG sdi5jsEGPHIZEztnQgqCzTsuIsuB8aGF+k0ToTDyQ10FNdNRobGVkYcXdskaUqLFhn7/ LTG3uMqpb3hHHGikxby+bUiXEtq4QXV3Ra0G5VJm5usGp8qiMeDg/oeAlSKF/0W5CLny GEav505qh+Ws6TNH8YCjYJRjAg1hQ+aLsFrevRTdCQrfiPx+JADeov+pUeavicIKWIPm xRl0rQYwKle7qU06LtI7KftHf6nDJU1uZ312O3f4PGWKjv6QXvRsCqsoCv3vrFK/IUDW OOgw== MIME-Version: 1.0 Received: by 10.58.35.166 with SMTP id i6mr8060761vej.10.1348506520566; Mon, 24 Sep 2012 10:08:40 -0700 (PDT) Received: by 10.58.102.102 with HTTP; Mon, 24 Sep 2012 10:08:40 -0700 (PDT) In-Reply-To: <35BC7EAA-345B-46B4-A18B-8F1D27E61BD1@jiaziyi.com> References: <35BC7EAA-345B-46B4-A18B-8F1D27E61BD1@jiaziyi.com> Date: Mon, 24 Sep 2012 10:08:40 -0700 Message-ID: From: Ulrich Herberg To: Jiazi YI Content-Type: multipart/alternative; boundary=047d7b5d4c4022b9be04ca75a46c X-Gm-Message-State: ALoCoQmg4ly8QT3itE2UataQbpPNBgoa59aTAknZMDDa7mYUNPigZZPaAArXoVVbYh3r0nvOSVMU Cc: manet@ietf.org Subject: Re: [manet] NHDP-sec-threats feedback X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 17:08:42 -0000 --047d7b5d4c4022b9be04ca75a46c Content-Type: text/plain; charset=ISO-8859-1 I agree with Jiazi. Best Ulrich On Fri, Sep 21, 2012 at 10:46 PM, Jiazi YI wrote: > Hi, > > regarding your previous comments: > > In general, both common and interaction attacks need to be documented > per protocol, it is more useful to have the scope of protocol's > vulnerability without excluding common network attacks and issues. Any > additional attacks should be considered, otherwise the document scope > section should specify if it excludes something. > > I don't see the need of including all the common threats to network in > this nhdp-sec-threat document is necessary, except the threats that have > particular impact to the ndhp mechanism. The redundancy should be reduced. > We can have some text on the scope at the beginning. > > I RECOMMEND that the draft [nhdp-threats] includes [nhdp-sec] in its > normative references and to include abstract information of > discussions [1- 3] into [nhdp-threats] and/or [nhdp-sec]. > > > No. It's the nhdp-sec that has a reference to nhdp-sec-threats. > > best > > Jiazi > > On Sep 22, 2012, at 1:30 AM, Abdussalam Baryun > wrote: > > > AB > On Tue, Jul 31, 2012 at 5:40 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Jiazi >> >> I already send my feedback before [1 -2] which had no respond/comment >> from authors. I think any comment should be responded to by authors of >> I-Ds or RFCs. I think that we need more discussions responds/comments >> from the group before last call regarding this I-D. >> >> Regards >> AB >> >> [1] http://www.ietf.org/mail-archive/web/manet/current/msg12899.html >> [2] http://www.ietf.org/mail-archive/web/manet/current/msg13234.html >> =================================================== >> >> > I apologize to Jiazi and co-authors as we accidentally skipped one of >> > the slide sets at this afternoon's meeting. >> > >> > Please review the slides for NHDP-sec-threats located at >> > http://tools.ietf.org/wg/manet/agenda >> > and see draft-ietf-manet-nhdp-sec-threats-00 >> > >> > The authors are asking for consideration of WG LAST CALL on this >> > document so please comment. >> > >> > -Joe >> > >> > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b5d4c4022b9be04ca75a46c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Jiazi.

Best
Ulrich

On Fri, Sep 21, 2012 at 10:46 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
Hi,=A0

regardin= g your previous comments:

In g=
eneral, both common and interaction attacks need to be documented
per protocol, it is more useful to have the scope of protocol's
vulnerability without excluding common network attacks and issues. Any
additional attacks should be considered, otherwise the document scope
section should specify if it excludes something.
I d= on't see the need of including all the common threats to network in thi= s nhdp-sec-threat document is necessary, except the threats that have parti= cular impact to the ndhp mechanism. The redundancy should be reduced.=A0
We can have some text on the scope at the beginning.=A0

= 
I RECOMMEND that the draft [nhdp-threats] =
includes [nhdp-sec] in its
normative references and to include abstract information of
discussions [1- 3] into [nhdp-threats] and/or [nhdp-sec].

No. It's the nhdp-sec that has a reference= to nhdp-sec-threats.=A0

best

Jiazi

On Sep 22, 2012, at 1:30 AM, Abdussalam Baryun <abdussalambaryun@gmai= l.com> wrote:

<second rem= inder>
AB
On Tue, Jul 31, 2012 at 5:40 AM, Abdussalam Bary= un <abdussalambaryun@gmail.com> wrote:
Hi Jiazi

I already send my fee= dback before [1 -2] which had no respond/comment
from authors. I think a= ny comment should be responded to by authors of
I-Ds or RFCs. I think that we need more discussions responds/comments
fr= om the group before last call regarding this I-D.

Regards
AB
<= br>[1] http://www.ietf.org/mail-archive/web/manet/curre= nt/msg12899.html
[2] http://www.ietf.org/mail-archive/web/manet/current/= msg13234.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

> I apologize to Jiazi and co-authors as we accidentally skipped one= of
> the slide sets at this afternoon's meeting.
>
>= Please review the slides for NHDP-sec-threats located at
> http://tools.i= etf.org/wg/manet/agenda
> and see draft-ietf-manet-nhdp-sec-threats-00
>
> The autho= rs are asking for consideration of WG LAST CALL on this
> document so= please comment.
>
> -Joe
>



______________________________= _________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


--047d7b5d4c4022b9be04ca75a46c-- From valerio.arnaboldi@iit.cnr.it Tue Sep 25 05:07:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2BF21F8866 for ; Tue, 25 Sep 2012 05:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.081 X-Spam-Level: *** X-Spam-Status: No, score=3.081 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_25=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwo5bNuoYV8m for ; Tue, 25 Sep 2012 05:07:35 -0700 (PDT) Received: from irina.iit.cnr.it (irina-lan.iit.cnr.it [146.48.96.79]) by ietfa.amsl.com (Postfix) with ESMTP id 03BD321F885E for ; Tue, 25 Sep 2012 05:07:34 -0700 (PDT) Received: by irina.iit.cnr.it (Postfix, from userid 1001) id 9A5CD3D8A68; Tue, 25 Sep 2012 14:07:01 +0200 (CEST) Date: Tue, 25 Sep 2012 14:07:01 +0200 From: Valerio Arnaboldi To: manet@ietf.org Message-ID: <50619e65.2aWEVo6uF4KYuLTL%valerio.arnaboldi@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [manet] SustainIT 2012 - Call for Participation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 12:07:36 -0000 [Apologies for possible multiple copies of this announcement] ======================================================================== CALL FOR PARTICIPATION Second IFIP/IEEE International Conference on Sustainable Internet & ICT for Sustainability SustainIT 2012 http://cnd.iit.cnr.it/sustainit2012/ Pisa, Tuscany, Italy October 4-5, 2012 Sponsored by: IFIP TC6 WG 6.3 - Performance of Communication Systems Co-sponsored by: IEEE Computer Society - TC on Computer Communications ======================================================================== MAIN FEATURES: *** Five Technical Sessions *** Two Keynote Speeches *** Two Special Sessions with Panel Discussion on Major On-going Projects *** WiP/Demo Session *** Ph.D. Forum *** Best Papers Award ======================================================================== PRELIMINARY PROGRAM ------------------------------------------------------------------------ Day 1 - October 4, 2012 ------------------------------------------------------------------------ 8:45 - 9:00 Opening Remarks 9:00 - 10:00 Keynote Speech TITLE: Transforming ICT Networks for a Sustainable Future SPEAKER: Thierry Klein, Head of Green Research at Bell Labs and Chair of Technical Committee, GreenTouch. 10:00 - 11:00 Session 1: Energy Efficiency in Data Centers Modelling and Analysing the Power Consumption of Idle Servers Robert Basmadjian, Florian Niedermeier, Hermann de Meer (University of Passau, Germany) Optimizing the Use of Request Distribution and Stored Energy for Cost Reduction in Multi-Site Internet Services Maja Etinski (Technical University of Catalunya, Spain); Margaret Martonosi (Princeton University, USA); Kien Le, Ricardo Bianchini, Thu Nguyen (Rutgers University, USA) 11:00 - 11:30 Coffee Break 11:30 - 12:50 Session 2: Energy Intelligence in Buildings & Enterprises (Concise Papers) Performance Evaluation of Mobility-Based Energy-Saving to Control Air-conditioning and Lighting Equipments Akihito Hiromori, Takumi Kanaya, Hirozumi Yamaguchi, Teruo Higashino (Osaka University, Japan) An Algorithm based on Finite State Machines with Fuzzy Transitions for Non-intrusive Load Disaggregation Pietro Ducange, Francesco Marcelloni, Dario Marinari (University of Pisa, Italy) Neural network-based forecasting of energy consumption due to electric lighting in office buildings Eleonora D'Andrea, Beatrice Lazzerini (University of Pisa, Italy); Sonia Leon Del Rosario (Universidad de Las Palmas de Gran Canaria, Spain) Enterprise Energy Management using a Linked Dataspace for Energy Intelligence Edward Curry, Souleiman Hasan, Sean O'Riain (National University of Ireland, Galway, Ireland) 12:50 - 14:00 Lunch Break 14:00 - 16:00 Poster Session (WiP + Demo papers) 14:00 - 16:00 PhD Forum 15:30 - 16:00 Coffee Break 16:00 - 18:00 Project Presentations and Panel: Sustainable Computing and Networking CoolEmAll - Models and Tools for Optimization of Data Center Energy-efficiency Micha vor dem Berge, Wolfgang Christmann (Christmann Informationstechnik + Medien, Germany); Eugen Volk (High Performance Computing Center Stuttgart, Germany); Stefan Wesner (University of Stuttgart, Germany); Ariel Oleksiak, Tomasz Piontek (Poznan Supercomputing and Networking Center, Poland); Georges Da Costa (University of Toulouse, France); Jean-Marc Pierson (Univerty Paul Sabatier, Toulouse, France) The low Energy COnsumption NETworks (ECONET) Project Raffaele Bolla (University of Genoa, Italy); Roberto Bruschi (CNIT, Italy); Franco R Davoli (University of Genoa, Italy); Lorenzo Di Gregorio (Lantiq Deutschland GmbH, Germany); Luca Giacomello (Telecom Italia, Italy); Chiara Lombardo (University of Genoa, Italy); Giorgio Parladori (Alcatel-Lucent, Italy); Nir Strugo (Mellanox Technologies, Israel); Anastasios Zafeiropoulos (GRNET, Greece) TREND: Toward Real Energy-efficient Network Design Marco G. Ajmone Marsan (Politecnico di Torino, Italy); Stefano Buzzi (University of Cassino, Italy); Luca Chiaraviglio, Michela Meo (Politecnico di Torino, Italy); Carmen Guerrero (University Carlos III of Madrid, Spain); Filip Idzikowski (Technical University of Berlin, Germany); Yabin Ye,Jorge Lopez Vizcaino (Huawei Technologies Duesseldorf GmbH, Germany) Rethinking Cellular System Architecture for Breaking Current Energy Efficiency Limits Barth Ulrich (Bell Labs, Alcatel-Lucent, Germany); Antonio Capone, Ilario Filippini (Politecnico di Milano, Italy); Bernd Gloss (Alcatel-Lucent, Germany) 20:00 - 23:00 Social Dinner ------------------------------------------------------------------------ Day 2 - October 5, 2012 ------------------------------------------------------------------------ 9:00 - 10:00 Keynote Speech TITLE: Smart Consumption: the Energy@home Approach SPEAKER: Fabio Bellifemmine, Director at Energy@home Association, Telecom Italia Lab, Italy 10:00 - 11:00 Project Presentations and Panel: ICT for Sustainability EcoGrid EU - An Efficient ICT Approach for a Sustainable Power System Dieter Gantenbein, Carl Binding, Bernhard Jansen (IBM Zurich Research Laboratory, Switzerland); Aditya Kr Mishra (University of Massachusetts Amherst, USA); Olle Sundstrom (IBM Research GmbH, Switzerland) Green Move: towards Next Generation Sustainable Smartphone-based Vehicle Sharing Giovanni Alli; Luciano Baresi, Andrea Bianchessi, Gianpaolo Cugola, Alessandro Margara; Angelo Morzenti, Carlo Ongini, Emanuele Panigati, Matteo Rossi, Sante Rotondi, Sergio Savaresi, Fabio A. Schreiber, Alessandro Sivieri, Letizia Tanca, Edoardo Vannutelli Depoli (Politecnico di Milano, Italy) 11:00 - 11:30 Coffee Break 11:30 12:50 Session 3: Modeling and Analysis of Energy Consumptions in Networks A Markov model to control heat dissipation in Open Multi-Frequency Green Routers Alfio Lombardo, Diego Reforgiato, Vincenzo Riccobene, Giovanni Schembra (University of Catania, Italy) Energy Efficient PONs with Service Delay Guarantees Luca Valcarenghi (Scuola Superiore Sant'Anna, Italy); Michele Chincoli (CNIT, Italy); Paolo Monti (Royal Institute of Technology (KTH), Sweden); Lena Wosinska (Royal Institute of Technology KTH, Sweden); Piero Castoldi (Scuola Superiore Sant'Anna, Italy) Analysis of the overall energy savings achieved by green cell-breathing mechanisms (concise paper) Luis Suarez, Loutfi Nuaymi, Jean-Marie Bonnin (Telecom Bretagne, France) 12:50 - 14:00 Lunch Break 14:00 - 15:00 Session 4: Advanced Energy Metering Systems On the Accuracy of Appliance Identification Based on Distributed Load Metering Data Andreas Reinhardt, Paul Baumann, Daniel Burgstahler, Matthias Hollick, Hristo Chonov, Marc Werner, Ralf Steinmetz (Technische Universitat Darmstadt, Germany) RPL Routing Protocol in Advanced Metering Infrastructures: an Analysis of the Unreliability Problems Emilio Ancillotti, Raffaele Bruno, Marco Conti (IIT-CNR, Italy) 15:00 - 15:15 Coffee Break 15:15 - 16:45 Session 5: Optimizing Energy Consumptions in Networks Energy saving heuristics in Backbone Networks Rosario G. Garroppo), Stefano Giordano, Gianfranco Nencioni, Michele Pagano, Maria Grazia Scutella (University of Pisa, Italy) Enabling Energy Efficient and Resilient Networks using Dynamic Topologies Alexander A. Kist, Abdelnour Aldraho (University of Southern Queensland, Australia) Energy aware management of resilient networks with shared protection Bernardetta Addis (Universita degli Studi di Torino, Italy); Antonio Capone, Giuliana Carello, Luca Gianoli (Politecnico di Milano, Italy); Brunilde Sanso (Ecole Polytechnique de Montreal, Canada) 16:45 - 17:00 Closing Session and Best Paper Award Announcement 17:00 - 17:30 Final Coffee Break ======================================================================== REGISTRATION: Online registration is available from the conference website (http://cnd.iit.cnr.it/sustainit2012/) until Oct. 2, 2012. Registration Fees: IEEE Member: EUR 260 Non IEEE Member: EUR 310 Student: EUR 210 ======================================================================== From jorgenavarro@ugr.es Wed Sep 26 08:27:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B3721F8697 for ; Wed, 26 Sep 2012 08:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE2LWlc06bpG for ; Wed, 26 Sep 2012 08:27:45 -0700 (PDT) Received: from mail3.ugr.es (mail3.ugr.es [150.214.35.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2F00921F8682 for ; Wed, 26 Sep 2012 08:27:45 -0700 (PDT) Received: from smtp2.ugr.es (smtp2.ugr.es [150.214.20.70]) by mail3.ugr.es (Postfix) with ESMTP id D371813EEB for ; Wed, 26 Sep 2012 17:27:38 +0200 (CEST) Received: from JorgePC (ct5158f-06.ece.gatech.edu [143.215.148.112]) by smtp2.ugr.es (Postfix) with ESMTP id 30E7C3C803 for ; Wed, 26 Sep 2012 17:27:37 +0200 (MEST) From: "Jorge Navarro Ortiz" To: Date: Wed, 26 Sep 2012 11:27:33 -0400 Message-ID: <001b01cd9bfb$75350d00$5f9f2700$@ugr.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2b+2v1VIjn8DkpSHeamN8iJvQ8tQ== Content-Language: es Subject: [manet] WoWMoM 2013 - Call For Papers X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 15:27:46 -0000 ------------------------------------------------------------------------ - Our apologies if you receive multiple copies of this CFP - ------------------------------------------------------------------------ CALL FOR PAPERS WoWMoM 2013 Fourteenth International Symposium on a World of Wireless, Mobile and Multimedia Networks http://wowmom2013.tmit.bme.hu/ sponsored by IEEE Computer Society, University of Texas at Arlington, IEEE Computer Society TC on Computer Communications (TCCC) June 4-7, 2013 Madrid, Spain ------------------------------------------------------------------------ **** ABSTRACT SUBMISSION DEADLINE: NOVEMBER 23, 2012 ******* **** FULL MANUSCRIPT DUE: NOVEMBER 30, 2012 ******* ------------------------------------------------------------------------ IEEE WoWMoM 2013 is soliciting original and previously unpublished papers addressing research challenges and advances towards a world of wireless, mobile, and multimedia pervasive communications. The evolution of wireless networking technologies and their key role in future Internet scenarios offer an increasing wealth of opportunities for distributing multimedia contents over wireless networks, enabling dissemination of professional contents to mobile users as well as sharing user-generated contents among them. Users will be able to retrieve, publish, and manage information, communicate with other users or devices, access and author services, create and exploit context- awareness and so on. Papers that present original work, validated by experimentation, simulation, or analysis, are solicited. Practical experiences and experimental efforts from both industry and academy, duly documenting the lessons learned from testbeds, field-trials, or real deployments, are also welcome. Topics of interest include, but are not limited to: - Wireless multimedia systems, services and applications - Opportunistic and delay-tolerant networks - Ad-hoc, sensor, mesh and vehicular wireless networks - Wireless BAN, PAN, LAN, MAN and WAN - Machine-to-machine (M2M) communications and the Internet of Things - Middleware services for wireless, mobile and multimedia networks - Context-awareness in wireless, mobile and multimedia networks - Content-centric architectures, multimedia content management and distribution for mobile networks - Localization mechanisms and services - Participatory and urban sensing - Mobile social networking - Resource management and QoS/QoE provisioning - Multicasting and broadcasting issues - Handoff and mobility management - Network management and control - Dependability, reliability and survivability issues for wireless, mobile and multimedia networks - Security and privacy issues for wireless, mobile and multimedia networks - Energy-efficient protocols and power management - Seamless internetworking and self-organization - System prototypes, measurements, real deployment, and experiences - Modeling, analysis, and performance evaluation AWARDS AND EDITORIAL FOLLOW-UP ------------------------------------------------------------------------ Papers presented at the Symposium will be considered for a Best Paper Award. Papers of particular merit will be considered for a fast track publication in the Elsevier Pervasive and Mobile Computing Journal. PAPER SUBMISSION AND PUBLICATION ------------------------------------------------------------------------ All submissions must describe original research, not published or currently under review for another workshop, conference, or journal. Papers must be submitted electronically through EDAS. You can find detailed submission instructions at: http://wowmom2013.tmit.bme.hu/submission.html ************************************************************************ *Submission implies the willingness of at least one author to attend * *the conference and present the paper. Accepted papers will be included* *in the proceedings of IEEE WoWMoM 2013 and published in the * *IEEE Digital Library. WoWMoM organizers reserve the right to exclude * *a paper from distribution after the conference (e.g., removal from * *IEEE Xplore) if the paper is not presented at the conference. * ************************************************************************ IMPORTANT DATES ------------------------------------------------------------------------ - Abstract submission deadline: November 23, 2012. - Full manuscript due: November 30, 2012. - Acceptance notification: March 15, 2013. CONTACTS ------------------------------------------------------------------------ For further information, please visit the conference website at http://wowmom2013.tmit.bme.hu/, or contact the PC Chairs at wowmom2013-pcchairs@iet.unipi.it WORKSHOPS AND AFFILIATED EVENTS: ------------------------------------------------------------------------ Several workshops will be held in conjunction with the main conference. Workshop papers will be included and indexed in the IEEE Digital Library (Xplore), showing their affiliation with IEEE WoWMoM. WoWMoM 2013 will also feature an Industry Track, PhD Forum and a Demonstrations Session. Please visit the conference website for details. ORGANIZING COMMITTEE ------------------------------------------------------------------------ GENERAL CHAIR - Sergey Gorinsky, Institute IMDEA Networks, Spain TPC CHAIRS - Yonghe Liu, University of Texas at Arlington, USA - Enzo Mingozzi, University of Pisa, Italy WORKSHOP CHAIRS - Miguel A. Labrador, University of South Florida, USA - Polychronis Koutsakis, Technical University of Crete, Greece INDUSTRY-TRACK CHAIRS - Claudio Cicconetti, Intecs, Italy - Vania Conan, Thales Communications & Security, France PUBLICATIONS CHAIRS - Angelos Lazaris, University of Southern California, USA - Balaji Rengarajan, Institute IMDEA Networks,Spain PhD FORUM CHAIRS - Marilia Curado, University of Coimbra, Portugal - Silvia Giordano, SUPSI, Switzerland DEMO CHAIRS - Omer Gurewitz, Ben Gurion University, Israel - Andres Marin Lopez, Carlos III University of Madrid, Spain PANEL CHAIR - Albert Banchs, Institute IMDEA Networks and Carlos III University of Madrid, Spain PUBLICITY CHAIRS - Michela Becchi, University of Missouri, USA - Yaping Lin, Hunan University, China - Jorge Navarro Ortiz, University of Granada, Spain - Maxim Podlesny, University of Waterloo, Canada LOCAL ORGANIZATION CHAIRS - Vincenzo Mancuso, Institute IMDEA Networks, Spain - Manuel Uruena, Carlos III University of Madrid, Spain FINANCE & REGISTRATION CHAIR - Yonghe Liu, University of Texas at Arlington, USA WEB CHAIRS - Levente Csikor, Budapest Univ. of Technology and Economics, Hungary - Gabor Retvari, Budapest Univ. of Technology and Economics, Hungary STEERING COMMITTEE - Marco Conti, IIT-CNR, Italy - Sajal K. Das, Univ. Texas at Arlington, USA (CHAIR) - Dipankar Raychaudhuri, Rutgers Univ., USA - Satish K. Tripathi, SUNY Buffalo, USA From Martin.Duke@boeing.com Fri Sep 28 09:45:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9CC21F8489 for ; Fri, 28 Sep 2012 09:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVNfKJZKnZFL for ; Fri, 28 Sep 2012 09:45:18 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id DB6FF21F847C for ; Fri, 28 Sep 2012 09:45:17 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q8SGjH0Q025987 for ; Fri, 28 Sep 2012 11:45:17 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q8SGjGsm025983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 28 Sep 2012 11:45:16 -0500 Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Fri, 28 Sep 2012 09:45:16 -0700 From: "Duke, Martin" To: MANET IETF Date: Fri, 28 Sep 2012 09:45:15 -0700 Thread-Topic: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt Thread-Index: Ac2dmKLqbXCjh4PWSuC0QxkxCDz0nw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD4F357FF5D0244B926B336314E7166725653DDF04XCHNW11Vnwnos_" MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 16:45:19 -0000 --_000_CD4F357FF5D0244B926B336314E7166725653DDF04XCHNW11Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few comments about the DLEP draft, which I like a lot and hope moves forw= ard: I'd like to second Henning's comment that unknown link characteristics (e.g= . latency, link quality) should not be reported as the optimum value for th= at characteristic. I think routers should be able to distinguish between li= nks that have the ideal link quality and links where the radio has no idea.= My suggestion is that we reserve a code (presumably 0xffff or 0xffffffff) = to mean "unknown". Radios with known values MUST report known values greate= r than 0xfffe or 0xfffffffe (!) as 0xfffe/0xfffffffe. ------------------- I think the text in sections 9.9 and 9.10 fail to make the case for distinc= t expressions of "expected forwarding time" and "latency." In the text, EFT is carefully defined. I understand that latency will be im= plementation-dependent, but if I were to implement a router or radio with t= his feature, I have no idea how what I'm expected to calculate/interpret di= ffers from EFT. After poking around a bit in the list archives, it seems li= ke EFT is just a really good way to compute latency, in which case it's not= a separate metric but just a really good vendor implementation of Latency. Moreover, on a purely editorial note, 9.9 defines the metric in the main bo= dy in the text, while 9.10 defines latency in the field definition. Thanks to the authors for their work on this draft. Martin --_000_CD4F357FF5D0244B926B336314E7166725653DDF04XCHNW11Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A few comments a= bout the DLEP draft, which I like a lot and hope moves forward:<= /p>

 

I’d like to second Henning’s comment that un= known link characteristics (e.g. latency, link quality) should not be repor= ted as the optimum value for that characteristic. I think routers should be= able to distinguish between links that have the ideal link quality and lin= ks where the radio has no idea. My suggestion is that we reserve a code (pr= esumably 0xffff or 0xffffffff) to mean “unknown”. Radios with k= nown values MUST report known values greater than 0xfffe or 0xfffffffe (!) = as 0xfffe/0xfffffffe.

 

-------------------

 

I think the text in sections 9.9 and 9.10 fail to make the case for= distinct expressions of “expected forwarding time” and “= latency.”

 

= In the text, EFT is carefully defined. I understand that latency will be im= plementation-dependent, but if I were to implement a router or radio with t= his feature, I have no idea how what I’m expected to calculate/interp= ret differs from EFT. After poking around a bit in the list archives, it se= ems like EFT is just a really good way to compute latency, in which case it= ’s not a separate metric but just a really good vendor implementation= of Latency.

 

More= over, on a purely editorial note, 9.9 defines the metric in the main body i= n the text, while 9.10 defines latency in the field definition.<= /p>

 

Thanks to= the authors for their work on this draft.

 

Martin

= --_000_CD4F357FF5D0244B926B336314E7166725653DDF04XCHNW11Vnwnos_-- From Martin.Duke@boeing.com Fri Sep 28 09:59:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF2421F84C2 for ; Fri, 28 Sep 2012 09:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDGFHJcPqYcx for ; Fri, 28 Sep 2012 09:59:50 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 942D521F849B for ; Fri, 28 Sep 2012 09:59:50 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q8SGxdc5022217 for ; Fri, 28 Sep 2012 09:59:39 -0700 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q8SGxcrE022200 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Fri, 28 Sep 2012 09:59:38 -0700 Received: from XCH-NW-11V.nw.nos.boeing.com ([130.247.25.84]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Fri, 28 Sep 2012 09:59:49 -0700 From: "Duke, Martin" To: MANET IETF Date: Fri, 28 Sep 2012 09:59:48 -0700 Thread-Topic: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt Thread-Index: Ac2dmqrTtatizFoVTZqIgaVvoQLLeg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD4F357FF5D0244B926B336314E7166725653DDF2DXCHNW11Vnwnos_" MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 16:59:51 -0000 --_000_CD4F357FF5D0244B926B336314E7166725653DDF2DXCHNW11Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also, If I might suggest the following be added to Section 24 as another optional= data item TLV: Relative Link Quality: If present, this value represents the desired minimu= m link quality. (The idea here is that radios can reduce their data rate or increase their = SNR to meet the goal.) And to the end of Section 25: Relative Link Quality - If present, this value represents the NEW relative = link quality (or unchanged, if the request is denied) If the implemented change of one Link Characteristics Request affects the v= alues of other link metrics not mentioned in the request, the implementatio= n SHOULD include data item TLVs representing those secondary changes in the= Link Characteristics ACK message. The point of the last paragraph is that if I add a TDMA time slot to reduce= latency, that will also have impact on data rate. If I reduce modulation t= o improve link quality, the same is true. Explicitly suggesting the non-obv= ious decision to report all of these in the ACK allows the router to infer = the tradeoffs that are going on. Thanks. Martin --_000_CD4F357FF5D0244B926B336314E7166725653DDF2DXCHNW11Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Also,=

 

If I mig= ht suggest the following be added to Section 24 as another optional data it= em TLV:

 

Relative Link Quality: If present, thi= s value represents the desired minimum link quality.

 

(The idea here is th= at radios can reduce their data rate or increase their SNR to meet the goal= .)

 

And to the end of Section 25:

=  

Relative Li= nk Quality – If present, this value represents the NEW relative link = quality (or unchanged, if the request is denied)

 

If the implemented change of one Link Charact= eristics Request affects the values of other link metrics not mentioned in = the request, the implementation SHOULD include data item TLVs representing = those secondary changes in the Link Characteristics ACK message.=

 

The poin= t of the last paragraph is that if I add a TDMA time slot to reduce latency= , that will also have impact on data rate. If I reduce modulation to improv= e link quality, the same is true. Explicitly suggesting the non-obvious dec= ision to report all of these in the ACK allows the router to infer the trad= eoffs that are going on.

 

Thanks.

Marti= n

 

= --_000_CD4F357FF5D0244B926B336314E7166725653DDF2DXCHNW11Vnwnos_--