From nataraju.sip@gmail.com  Wed Jun  5 01:09:18 2013
Return-Path: <nataraju.sip@gmail.com>
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 8021221F9A9D for <manet@ietfa.amsl.com>; Wed,  5 Jun 2013 01:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.715
X-Spam-Level: 
X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOeX2EVY0kv9 for <manet@ietfa.amsl.com>; Wed,  5 Jun 2013 01:09:18 -0700 (PDT)
Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CA36021F9A9C for <manet@ietf.org>; Wed,  5 Jun 2013 01:09:17 -0700 (PDT)
Received: by mail-vb0-f43.google.com with SMTP id e15so882002vbg.30 for <manet@ietf.org>; Wed, 05 Jun 2013 01:09: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=X/cW9oE5Kc3HziKaAgic7YMBF8ePVN4f20FzJxm20a4=; b=S1GivLUcYZRARXSGZxnteY9aLHN9yuRI0XuWENukmBw5LO1wCBTDtZYiq0NMwFxz/O ntYKOV3cDo9HmkOlqvpKz4g8GxKWhXJPyPJoEcJyMSJp3Ah46llmXiVRQP6vz8LlNAm3 N1Aa3OFHcqMHWOvM10RZ1BIoJxC4/5Vqamtz1KKiIlCrU/4BBuMsb2rJqF1UQ0sUB6hU pezwfa9S3s2KgllyxjlOyaI78NWg3qSn2caWN6jlTwvN/l49GPGr+Vg6KTRCKSKyIAw6 4tk2XaA5JTsOFhZIg6XH9FYi0Sce90Axrmh7L7DELrQYcR1o75jCeXeAT4861Kr3VMla ZivQ==
MIME-Version: 1.0
X-Received: by 10.221.4.131 with SMTP id oc3mr19828269vcb.49.1370419757184; Wed, 05 Jun 2013 01:09:17 -0700 (PDT)
Received: by 10.220.194.201 with HTTP; Wed, 5 Jun 2013 01:09:17 -0700 (PDT)
In-Reply-To: <CAGJnb3xfJmjfi6zhOSjT6f5AN7we9e5ZFcszbL5dycfwxV3LLg@mail.gmail.com>
References: <CAGJnb3xfJmjfi6zhOSjT6f5AN7we9e5ZFcszbL5dycfwxV3LLg@mail.gmail.com>
Date: Wed, 5 Jun 2013 13:39:17 +0530
Message-ID: <CA+rAfUP6r0KSKZqPe5GqnLLP7y0v-qefGutNaPxorpMm-BYkNA@mail.gmail.com>
From: "Nataraju A.B" <nataraju.sip@gmail.com>
To: Mukul Shukla <mukulrshukla@gmail.com>
Content-Type: multipart/alternative; boundary=089e01293fe2d1fde104de63b633
Cc: manet@ietf.org
Subject: Re: [manet] Need AODV implementations
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2013 08:09:18 -0000

--089e01293fe2d1fde104de63b633
Content-Type: text/plain; charset=ISO-8859-1

Probably NS-2 with Linux OS is the best platform for your work


On Sun, May 19, 2013 at 7:16 PM, Mukul Shukla <mukulrshukla@gmail.com>wrote:

> Hi,
>
> I want to study the security issues of AODV protocol. I need the active
> linux implementation of the AODV protocol. I t would be nice if I can have
> DSR and OLSR implementations too.
>
> Thanks.
>
> Mukul
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>


-- 
Thanks,
Nataraju A.B.

--089e01293fe2d1fde104de63b633
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Probably NS-2 with Linux OS is the best platform for your =
work<br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Su=
n, May 19, 2013 at 7:16 PM, Mukul Shukla <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:mukulrshukla@gmail.com" target=3D"_blank">mukulrshukla@gmail.com</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>Hi,<br><br><=
/div>I want to study the security issues of AODV protocol. I need the activ=
e linux implementation of the AODV protocol. I t would be nice if I can hav=
e DSR and OLSR implementations too.<br>

<br></div>Thanks.<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></f=
ont></span></div><span class=3D"HOEnZb"><font color=3D"#888888">Mukul<br></=
font></span></div>
<br>_______________________________________________<br>
manet mailing list<br>
<a href=3D"mailto:manet@ietf.org">manet@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/manet" target=3D"_blank">h=
ttps://www.ietf.org/mailman/listinfo/manet</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><font co=
lor=3D"#000099"><font face=3D"&#39;courier new&#39;, monospace" size=3D"1">=
Thanks,</font></font><div><font color=3D"#000099"><font face=3D"&#39;courie=
r new&#39;, monospace" size=3D"1">Nataraju A.B.</font></font></div>

</div></div>

--089e01293fe2d1fde104de63b633--

From ulrich@herberg.name  Wed Jun  5 10:23:37 2013
Return-Path: <ulrich@herberg.name>
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 76D9721F9B14 for <manet@ietfa.amsl.com>; Wed,  5 Jun 2013 10:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zCBaVc2e8aA for <manet@ietfa.amsl.com>; Wed,  5 Jun 2013 10:23:36 -0700 (PDT)
Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD321F9AD2 for <manet@ietf.org>; Wed,  5 Jun 2013 10:23:36 -0700 (PDT)
Received: by mail-ve0-f169.google.com with SMTP id m1so1493303ves.0 for <manet@ietf.org>; Wed, 05 Jun 2013 10:23:35 -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:content-transfer-encoding; bh=T6O3cAx74n8vRW2SaV1k4ED5Aqg43NaMt0uywOMa0qk=; b=euR+Li2dbvs/dlxYeX5AhPbhUeVTr75jBQ92YhZSjcDvp9i0bUmQZhQNiWc1dp/ZOX aVOKP9RD5lArrNduOlTQhQnEMwOo76NXkxTH8FVo4Uy8jhGeUaWVaaxmyOop/E3HtYyF T3KZWJ+syS1WbZyAN/JHyltlBCmJ+CmhRNDIU=
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:content-transfer-encoding:x-gm-message-state; bh=T6O3cAx74n8vRW2SaV1k4ED5Aqg43NaMt0uywOMa0qk=; b=NsRum6HVKC9slcVmlrcPXR0kKstgXEVpy0wdj3B/nWiU/f2QEaSz9Nc4wnBnxXxQW+ yA8cSZgTAIuR6jNW/HXnAXZCj7pTRRcnVeWzrhmVAnZZQSJ6M3wDyzyO0M8Vx58kg2KH 53Bpk6AjFHeogpeDtGLJoMz/utoCybSZ6xqEIbNPq1wzM83twcuNU77cXwGTwNKuipUT jt3EZYqSnEfvf1iLRd1Gkl98hMkD67eUTX3RehKDHMcazg72/uvtZ2LiSP444DkVyojN I0PRpDYJ6wxf4oz79cc5os7PdnAn39KxJer21KrjZzuF73Qa5mMu0awMOcDd5WxqpU9F Y6eQ==
MIME-Version: 1.0
X-Received: by 10.220.161.2 with SMTP id p2mr20278487vcx.72.1370453015599; Wed, 05 Jun 2013 10:23:35 -0700 (PDT)
Received: by 10.220.29.7 with HTTP; Wed, 5 Jun 2013 10:23:35 -0700 (PDT)
In-Reply-To: <trinity-eaf9eee4-0692-4534-9e59-393702af96ba-1370432392554@3capp-gmx-bs19>
References: <trinity-eaf9eee4-0692-4534-9e59-393702af96ba-1370432392554@3capp-gmx-bs19>
Date: Wed, 5 Jun 2013 10:23:35 -0700
Message-ID: <CAK=bVC9knJ55RB1GxtnYLYjUzCJnwYd=c2fGVXs2v808ZEX=+Q@mail.gmail.com>
From: Ulrich Herberg <ulrich@herberg.name>
To: Thomas Meier <nsclick@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnNFLwKcnw8+G5vBGI2zxM4Ipt8xe4hDRjoTYm+rjybMfVFc+NC1hWzyOkPo/DVpt6EhVNL
Cc: manet@ietf.org
Subject: Re: [manet] Forwarding AODV messages over a tunnel
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2013 17:23:37 -0000

Thomas,

(replying to manet@ietf.org, which I think is the better place to ask
this question rather than ietf@ietf.org)

What kind of tunnel do you want to use? IP-in-IP tunnel or L2 tunnel
or something else (IP-over-foo)?
In either way, reactive MANET protocols (as well as the proactive
ones) forward messages hop-by-hop, using a link-local multicast
address. If you use an IP-in-IP tunnel or L2 tunnel, the control
message would not be modified, and to the MANET protocol it would look
like a single hop (hop-count++, IP src address =3D tunnel start point).

Side-note: a wormhole is itself just a normal link; I don't see a
difference between a "legitimate" link/tunnel and a wormhole, unless
the wormhole does something "bad" with the actual data (dropping
packets, eavesdropping, advertising wrong link metrics etc).

Best regards
Ulrich

On Wed, Jun 5, 2013 at 4:39 AM, Thomas Meier <nsclick@gmx.de> wrote:
>
> Hello,
>
> I want to forward AODV messages over a tunnel (don't worry, it's not for =
a wormhole attack).
> In the RFC3561 I can't find information about how to deal with the packet=
 at the tunnel endpoint. Should I increment the hopcount of a RREQ by one o=
r by the number of hops the tunnel has? Furthermore I'm wondering about whi=
ch address to use for the previous node at the tunnel endpoint. Should this=
 be the entrance of the tunnel or the "real" previous node?
> If the tunnel entrance is used as previous node and the hopcount is only =
incremented by one, the tunnel would be prefered compared to a connection w=
ithout a tunnel (like in wormhole attacks).
> Is there some information on how to deal with a tunnel?
>
> Thanks,
>
> Thomas

From adrian@olddog.co.uk  Thu Jun  6 03:14:32 2013
Return-Path: <adrian@olddog.co.uk>
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 15E5921F92E7 for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 03:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5FjlvITmzRN for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 03:14:20 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id F168121F9371 for <manet@ietf.org>; Thu,  6 Jun 2013 03:14:19 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r56AEGGW025456;  Thu, 6 Jun 2013 11:14:16 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r56AEEZi025428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 11:14:15 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <manet@ietf.org>
References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com>
In-Reply-To: <20130605150955.25672.65454.idtracker@ietfa.amsl.com>
Date: Thu, 6 Jun 2013 11:14:10 +0100
Message-ID: <090201ce629e$9712a760$c537f620$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJBFHMtswfWjH3sYVH2Y0aAv7p0rJhDE99Q
Content-Language: en-gb
Subject: [manet] FW: Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use of	OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 10:14:32 -0000

Heads up.

This I-D is in IETF last call.

I know some of you had comments on a previous version. Please send any further
comments as described for IETF last call and *NOT* to this list.

Thanks,
Adrian

> -----Original Message-----
> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-
> bounces@ietf.org] On Behalf Of The IESG
> Sent: 05 June 2013 16:10
> To: IETF-Announce
> Cc: ospf@ietf.org
> Subject: Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use of
OSPF-
> MDR in Single-Hop Broadcast Networks) to Experimental RFC
> 
> 
> The IESG has received a request from the Open Shortest Path First IGP WG
> (ospf) to consider the following document:
> - 'Use of OSPF-MDR in Single-Hop Broadcast Networks'
>   <draft-ietf-ospf-manet-single-hop-mdr-03.txt> as Experimental RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2013-06-19. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
> RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks
> (MANETs) by specifying its operation on the new OSPF interface of type
> MANET.  This document describes the use of OSPF-MDR in a single-hop
> broadcast network, which is a special case of a MANET in which each
> router is a (one-hop) neighbor of each other router.  Unlike an OSPF
> broadcast interface, such an interface can have a different cost
> associated with each neighbor.  The document includes configuration
> recommendations and simplified mechanisms that can be used in single-hop
> broadcast networks.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.



From abdussalambaryun@gmail.com  Thu Jun  6 03:20:49 2013
Return-Path: <abdussalambaryun@gmail.com>
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 E483421F9711 for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 03:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-6CclUDHv+O for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 03:20:48 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A2F9121F96FF for <manet@ietf.org>; Thu,  6 Jun 2013 03:20:47 -0700 (PDT)
Received: by mail-pa0-f50.google.com with SMTP id fb1so1616139pad.23 for <manet@ietf.org>; Thu, 06 Jun 2013 03:20:47 -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=uR60kku8KYschE3SRStM3SRPeOPTA71T9fXW3aDclSs=; b=YyNgc6z3Twy67pY5feBt4LDoAkrSHfd2/k3Lj7/wpufSHAOEPdaqf/uo6upfUoJaDU hrwL613duoRUzZTcINHpyYjXV1h50pjoe9S2bk0zCljCtVD4FMJbMuxhggTnv4CKJ7mg vmp0zUy/eYESw2UK1CmsvLsb4w6ctGByUWClE39h8kWjmt9nMF68rPfKHGICLLIJbXFt cmbwYRZZiN1xRO34ZYpCaSpa+3R39aTegnifAIqGJGCjBQJ7UTohPBZh8XXEYE+aDlMa +r0AI0vxKmEyH8EMnCBpTemK1yUPq8xlCPMp49drw2++h25I1g9RQnWgGR5HZQEeDQPw aUGw==
MIME-Version: 1.0
X-Received: by 10.68.219.42 with SMTP id pl10mr38230064pbc.24.1370514047340; Thu, 06 Jun 2013 03:20:47 -0700 (PDT)
Received: by 10.68.78.164 with HTTP; Thu, 6 Jun 2013 03:20:47 -0700 (PDT)
In-Reply-To: <090201ce629e$9712a760$c537f620$@olddog.co.uk>
References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com> <090201ce629e$9712a760$c537f620$@olddog.co.uk>
Date: Thu, 6 Jun 2013 12:20:47 +0200
Message-ID: <CADnDZ8-d6bzbJ9RHPwg-=zwFxRhegRdUrGoSTAipr3Qf2sd5yA@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: adrian@olddog.co.uk
Content-Type: text/plain; charset=ISO-8859-1
Cc: manet@ietf.org
Subject: Re: [manet] FW: Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 10:20:49 -0000

Dear IETF AD,

I hope that my questions are to be answered. Please note that I don't
think I have to remind editors even if they are busy, because I am
busy as well. IMHO, if an editor is busy or not able to reply to
community he/she should not take any work of the IETF. Please note
that this is a public complain from me about the editors of this I-D
not answering to my questions.

AB

On 6/6/13, Adrian Farrel <adrian@olddog.co.uk> wrote:
> Heads up.
>
> This I-D is in IETF last call.
>
> I know some of you had comments on a previous version. Please send any
> further
> comments as described for IETF last call and *NOT* to this list.
>
> Thanks,
> Adrian
>
>> -----Original Message-----
>> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-
>> bounces@ietf.org] On Behalf Of The IESG
>> Sent: 05 June 2013 16:10
>> To: IETF-Announce
>> Cc: ospf@ietf.org
>> Subject: Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use of
> OSPF-
>> MDR in Single-Hop Broadcast Networks) to Experimental RFC
>>
>>
>> The IESG has received a request from the Open Shortest Path First IGP WG
>> (ospf) to consider the following document:
>> - 'Use of OSPF-MDR in Single-Hop Broadcast Networks'
>>   <draft-ietf-ospf-manet-single-hop-mdr-03.txt> as Experimental RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2013-06-19. Exceptionally, comments may be
>> sent to iesg@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>> RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks
>> (MANETs) by specifying its operation on the new OSPF interface of type
>> MANET.  This document describes the use of OSPF-MDR in a single-hop
>> broadcast network, which is a special case of a MANET in which each
>> router is a (one-hop) neighbor of each other router.  Unlike an OSPF
>> broadcast interface, such an interface can have a different cost
>> associated with each neighbor.  The document includes configuration
>> recommendations and simplified mechanisms that can be used in single-hop
>> broadcast networks.
>>
>>
>>
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/
>>
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

From adrian@olddog.co.uk  Thu Jun  6 03:45:47 2013
Return-Path: <adrian@olddog.co.uk>
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 8B93021F995E for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 03:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY+DFiE7YPs6 for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 03:45:42 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 904AA21F9104 for <manet@ietf.org>; Thu,  6 Jun 2013 03:45:42 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r56Ajd26024832;  Thu, 6 Jun 2013 11:45:40 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r56Ajc8O024814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 11:45:39 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Abdussalam Baryun'" <abdussalambaryun@gmail.com>
References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com>	<090201ce629e$9712a760$c537f620$@olddog.co.uk> <CADnDZ8-d6bzbJ9RHPwg-=zwFxRhegRdUrGoSTAipr3Qf2sd5yA@mail.gmail.com>
In-Reply-To: <CADnDZ8-d6bzbJ9RHPwg-=zwFxRhegRdUrGoSTAipr3Qf2sd5yA@mail.gmail.com>
Date: Thu, 6 Jun 2013 11:45:34 +0100
Message-ID: <091a01ce62a2$f9a00180$ece00480$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJBFHMtswfWjH3sYVH2Y0aAv7p0rAGut2ZAAg1jki+YJTk3oA==
Content-Language: en-gb
Cc: manet@ietf.org
Subject: Re: [manet] FW: Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 10:45:47 -0000

Hi,

Which part of 

> >Please send any further comments as described for IETF last call
> > and *NOT* to this list.

did you not understand?

You have also sent a follow-up email as part of IETF last call which is fine and
correct.

Note that your previous emails which you cite were sent to and discussed on the
MANET list. This might explain why the OSPF working group did not pick up on
your comments.

Note also that at least some of your comments in the emails you cite received
reasonable answers/explanations on the MANET list. It is not helpful to demand
further answers to the parts of your emails that have been answered already.

Can we now move this thread to the correct location and cease spamming the MANET
list.

Thanks,
Adrian

> -----Original Message-----
> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
> Sent: 06 June 2013 11:21
> To: adrian@olddog.co.uk
> Cc: manet@ietf.org
> Subject: Re: [manet] FW: Last Call: <draft-ietf-ospf-manet-single-hop-mdr-
> 03.txt> (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental
> RFC
> 
> Dear IETF AD,
> 
> I hope that my questions are to be answered. Please note that I don't
> think I have to remind editors even if they are busy, because I am
> busy as well. IMHO, if an editor is busy or not able to reply to
> community he/she should not take any work of the IETF. Please note
> that this is a public complain from me about the editors of this I-D
> not answering to my questions.
> 
> AB
> 
> On 6/6/13, Adrian Farrel <adrian@olddog.co.uk> wrote:
> > Heads up.
> >
> > This I-D is in IETF last call.
> >
> > I know some of you had comments on a previous version. Please send any
> > further
> > comments as described for IETF last call and *NOT* to this list.
> >
> > Thanks,
> > Adrian
> >
> >> -----Original Message-----
> >> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-
> >> bounces@ietf.org] On Behalf Of The IESG
> >> Sent: 05 June 2013 16:10
> >> To: IETF-Announce
> >> Cc: ospf@ietf.org
> >> Subject: Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use of
> > OSPF-
> >> MDR in Single-Hop Broadcast Networks) to Experimental RFC
> >>
> >>
> >> The IESG has received a request from the Open Shortest Path First IGP WG
> >> (ospf) to consider the following document:
> >> - 'Use of OSPF-MDR in Single-Hop Broadcast Networks'
> >>   <draft-ietf-ospf-manet-single-hop-mdr-03.txt> as Experimental RFC
> >>
> >> The IESG plans to make a decision in the next few weeks, and solicits
> >> final comments on this action. Please send substantive comments to the
> >> ietf@ietf.org mailing lists by 2013-06-19. Exceptionally, comments may be
> >> sent to iesg@ietf.org instead. In either case, please retain the
> >> beginning of the Subject line to allow automated sorting.
> >>
> >> Abstract
> >>
> >>
> >> RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks
> >> (MANETs) by specifying its operation on the new OSPF interface of type
> >> MANET.  This document describes the use of OSPF-MDR in a single-hop
> >> broadcast network, which is a special case of a MANET in which each
> >> router is a (one-hop) neighbor of each other router.  Unlike an OSPF
> >> broadcast interface, such an interface can have a different cost
> >> associated with each neighbor.  The document includes configuration
> >> recommendations and simplified mechanisms that can be used in single-hop
> >> broadcast networks.
> >>
> >>
> >>
> >>
> >> The file can be obtained via
> >> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/
> >>
> >> IESG discussion can be tracked via
> >>
http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ballot/
> >>
> >>
> >> No IPR declarations have been submitted directly on this I-D.
> >
> >
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
> >


From adrian@olddog.co.uk  Thu Jun  6 04:11:32 2013
Return-Path: <adrian@olddog.co.uk>
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 BAC4421F9956 for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 04:11:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGGAcqYhUQcm for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 04:11:28 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id C7C5D21F9923 for <manet@ietf.org>; Thu,  6 Jun 2013 04:11:27 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r56BBOIj000497;  Thu, 6 Jun 2013 12:11:24 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r56BBNRP000473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Jun 2013 12:11:24 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Ulrich Herberg'" <ulrich@herberg.name>, "'Thomas Meier'" <nsclick@gmx.de>
References: <trinity-eaf9eee4-0692-4534-9e59-393702af96ba-1370432392554@3capp-gmx-bs19> <CAK=bVC9knJ55RB1GxtnYLYjUzCJnwYd=c2fGVXs2v808ZEX=+Q@mail.gmail.com>
In-Reply-To: <CAK=bVC9knJ55RB1GxtnYLYjUzCJnwYd=c2fGVXs2v808ZEX=+Q@mail.gmail.com>
Date: Thu, 6 Jun 2013 12:11:19 +0100
Message-ID: <092701ce62a6$9292f200$b7b8d600$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEtEwZUIEZVokWVklWuTOF3bx6WAgJ0NqzymleDy3A=
Content-Language: en-gb
Cc: manet@ietf.org
Subject: Re: [manet] Forwarding AODV messages over a tunnel
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 11:11:32 -0000

I do think this is an interesting question. I think what Thomas is talking about
is running AODV (or any other MANET routing protocol) over a "virtual
adjacency".

Such techniques do, of course, exist in other routing environments and they
cause interesting issues (such as tromboning) if the cost of the virtual link is
not set carefully with consideration of the underlying hop costs, or if careful
(policy-based?) decisions are not made about what traffic can be forwarded on
the tunnel versus the native network.

Ulrich's questions seem quite relevant in that context: what, how, why? :-) It
seems hard to give a simple and definitive answer to a very open question.

Thomas, a normal way to proceed at this point would be to write up the use-case
and motivations for what you are considering and put them in a short
Internet-Draft. The working group can then consider them properly. We might end
up with a little advisory RFC.

Thanks,
Adrian

> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
> Ulrich Herberg
> Sent: 05 June 2013 18:24
> To: Thomas Meier
> Cc: manet@ietf.org
> Subject: Re: [manet] Forwarding AODV messages over a tunnel
> 
> Thomas,
> 
> (replying to manet@ietf.org, which I think is the better place to ask
> this question rather than ietf@ietf.org)
> 
> What kind of tunnel do you want to use? IP-in-IP tunnel or L2 tunnel
> or something else (IP-over-foo)?
> In either way, reactive MANET protocols (as well as the proactive
> ones) forward messages hop-by-hop, using a link-local multicast
> address. If you use an IP-in-IP tunnel or L2 tunnel, the control
> message would not be modified, and to the MANET protocol it would look
> like a single hop (hop-count++, IP src address = tunnel start point).
> 
> Side-note: a wormhole is itself just a normal link; I don't see a
> difference between a "legitimate" link/tunnel and a wormhole, unless
> the wormhole does something "bad" with the actual data (dropping
> packets, eavesdropping, advertising wrong link metrics etc).
> 
> Best regards
> Ulrich
> 
> On Wed, Jun 5, 2013 at 4:39 AM, Thomas Meier <nsclick@gmx.de> wrote:
> >
> > Hello,
> >
> > I want to forward AODV messages over a tunnel (don't worry, it's not for a
> wormhole attack).
> > In the RFC3561 I can't find information about how to deal with the packet at
the
> tunnel endpoint. Should I increment the hopcount of a RREQ by one or by the
> number of hops the tunnel has? Furthermore I'm wondering about which
> address to use for the previous node at the tunnel endpoint. Should this be
the
> entrance of the tunnel or the "real" previous node?
> > If the tunnel entrance is used as previous node and the hopcount is only
> incremented by one, the tunnel would be prefered compared to a connection
> without a tunnel (like in wormhole attacks).
> > Is there some information on how to deal with a tunnel?
> >
> > Thanks,
> >
> > Thomas
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From sratliff@cisco.com  Thu Jun  6 07:22:42 2013
Return-Path: <sratliff@cisco.com>
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 8DEF421F93E0; Thu,  6 Jun 2013 07:22:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+cy6Mx1dWD4; Thu,  6 Jun 2013 07:22:21 -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 2F8E721F972C; Thu,  6 Jun 2013 07:22:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3350; q=dns/txt; s=iport; t=1370528539; x=1371738139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H92TswpvTGdoPsd51P2IQXW0U6iWsH8qwElUXgklU+Y=; b=EMMHiKi/l8KXl5jqJcCU/Z8xFlwYEshIFPh3ZWFMEUeSpTFrd0U4V/97 UZM86aTCcLDiV0C4Htl1delrwBopMIn8OP75FG0JAaGBm7LOShI/ucBtT NmJzCPFg9boK4EKVvRCvQO/Z7MB5NM3tpTpYOtd4bowPme4MyqkV1nFOQ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAPeZsFGtJXG9/2dsb2JhbABZgwkwv0d4FnSCIwEBAQMBAQEBNzQLBQcEAgEIEQQBAQEKFAUEBycLFAkIAgQBDQUIDIdzBgy7LI1wgQ8CMQcGgnRhA5hokBeBWIE3gXE2
X-IronPort-AV: E=Sophos;i="4.87,815,1363132800"; d="scan'208";a="219580324"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 06 Jun 2013 14:22:18 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r56EMIBd000867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 14:22:18 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.104]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 09:22:17 -0500
From: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
To: Abdussalam Baryun <abdussalambaryun@gmail.com>, OSPF List <ospf@ietf.org>,  Acee Lindem <acee.lindem@ericsson.com>
Thread-Topic: [manet] Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
Thread-Index: AQHOYsE/Z1NEPUx3SkSpfeeEjarimg==
Date: Thu, 6 Jun 2013 14:22:16 +0000
Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com>
References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com> <090201ce629e$9712a760$c537f620$@olddog.co.uk> <CADnDZ8-d6bzbJ9RHPwg-=zwFxRhegRdUrGoSTAipr3Qf2sd5yA@mail.gmail.com>
In-Reply-To: <CADnDZ8-d6bzbJ9RHPwg-=zwFxRhegRdUrGoSTAipr3Qf2sd5yA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.102.41.144]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D9B64FC457883A4BAB63C9B196C083AB@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "manet@ietf.org List" <manet@ietf.org>
Subject: Re: [manet] Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 14:22:43 -0000

Abdussalam,=20

I'm forwarding your email to the OSPF mailing list and Acee Lindem (the doc=
ument shepherd). Just FYI, no one on the MANET list has responded since thi=
s is an OSPF issue.=20

Regards,
Stan

On Jun 6, 2013, at 6:20 AM, Abdussalam Baryun wrote:

> Dear IETF AD,
>=20
> I hope that my questions are to be answered. Please note that I don't
> think I have to remind editors even if they are busy, because I am
> busy as well. IMHO, if an editor is busy or not able to reply to
> community he/she should not take any work of the IETF. Please note
> that this is a public complain from me about the editors of this I-D
> not answering to my questions.
>=20
> AB
>=20
> On 6/6/13, Adrian Farrel <adrian@olddog.co.uk> wrote:
>> Heads up.
>>=20
>> This I-D is in IETF last call.
>>=20
>> I know some of you had comments on a previous version. Please send any
>> further
>> comments as described for IETF last call and *NOT* to this list.
>>=20
>> Thanks,
>> Adrian
>>=20
>>> -----Original Message-----
>>> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-
>>> bounces@ietf.org] On Behalf Of The IESG
>>> Sent: 05 June 2013 16:10
>>> To: IETF-Announce
>>> Cc: ospf@ietf.org
>>> Subject: Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use =
of
>> OSPF-
>>> MDR in Single-Hop Broadcast Networks) to Experimental RFC
>>>=20
>>>=20
>>> The IESG has received a request from the Open Shortest Path First IGP W=
G
>>> (ospf) to consider the following document:
>>> - 'Use of OSPF-MDR in Single-Hop Broadcast Networks'
>>>  <draft-ietf-ospf-manet-single-hop-mdr-03.txt> as Experimental RFC
>>>=20
>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> final comments on this action. Please send substantive comments to the
>>> ietf@ietf.org mailing lists by 2013-06-19. Exceptionally, comments may =
be
>>> sent to iesg@ietf.org instead. In either case, please retain the
>>> beginning of the Subject line to allow automated sorting.
>>>=20
>>> Abstract
>>>=20
>>>=20
>>> RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks
>>> (MANETs) by specifying its operation on the new OSPF interface of type
>>> MANET.  This document describes the use of OSPF-MDR in a single-hop
>>> broadcast network, which is a special case of a MANET in which each
>>> router is a (one-hop) neighbor of each other router.  Unlike an OSPF
>>> broadcast interface, such an interface can have a different cost
>>> associated with each neighbor.  The document includes configuration
>>> recommendations and simplified mechanisms that can be used in single-ho=
p
>>> broadcast networks.
>>>=20
>>>=20
>>>=20
>>>=20
>>> The file can be obtained via
>>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/
>>>=20
>>> IESG discussion can be tracked via
>>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ba=
llot/
>>>=20
>>>=20
>>> No IPR declarations have been submitted directly on this I-D.
>>=20
>>=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 wwwrun@rfc-editor.org  Thu Jun  6 07:27:55 2013
Return-Path: <wwwrun@rfc-editor.org>
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 1A4FF21F8EAE for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 07:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA2dK4vRp80l for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 07:27:54 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id EB15621F8D2B for <manet@ietf.org>; Thu,  6 Jun 2013 07:27:45 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 8BCB762117; Thu,  6 Jun 2013 07:26:19 -0700 (PDT)
To: macker@itd.nrl.navy.mil, stbryant@cisco.com, adrian@olddog.co.uk, sratliff@cisco.com, macker@itd.nrl.navy.mil
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20130606142619.8BCB762117@rfc-editor.org>
Date: Thu,  6 Jun 2013 07:26:19 -0700 (PDT)
Cc: manet@ietf.org, joseph.macker@nrl.navy.mil, rfc-editor@rfc-editor.org
Subject: [manet] [Technical Errata Reported] RFC6621 (3640)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 14:27:55 -0000

The following errata report has been submitted for RFC6621,
"Simplified Multicast Forwarding".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6621&eid=3640

--------------------------------------
Type: Technical
Reported by: Joseph Macker <joseph.macker@nrl.navy.mil>

Section: A.4

Original Text
-------------
  4.  If "RtrPri(n0)" is greater than that of all tuples in the union
      of "N1" and "N2", then "n0" selects itself as a relay, and no
      further steps are taken.

Corrected Text
--------------
  4.  If "RtrPri(n0)" is greater than that of all tuples in
      "N1", then "n0" selects itself as a relay, and no
      further steps are taken.

Notes
-----
The initial verbal description of the E-CDS algorithm in first paragraph A.1 pg 40 is correct..as follows

  1.  If an SMF router has a higher ordinal (Router Priority, Router
      ID) than all of its symmetric neighbors, it elects itself to act
      as a forwarder for all received multicast packets.

But LATER in A.4 pseudocode Step 4 contains a bug. N2 (2 hop neighbors are included in this step).  This pseudocode bug can cause incorrect behavior to occur.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6621 (draft-ietf-manet-smf-14)
--------------------------------------
Title               : Simplified Multicast Forwarding
Publication Date    : May 2012
Author(s)           : J. Macker, Ed.
Category            : EXPERIMENTAL
Source              : Mobile Ad-hoc Networks
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

From prvs=9869d7c2d2=acee.lindem@ericsson.com  Thu Jun  6 07:54:06 2013
Return-Path: <prvs=9869d7c2d2=acee.lindem@ericsson.com>
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 B447321F9051; Thu,  6 Jun 2013 07:54:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MY+nE9iLrUBE; Thu,  6 Jun 2013 07:54:01 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 17F7C21F909A; Thu,  6 Jun 2013 07:54:01 -0700 (PDT)
X-AuditID: c618062d-b7f936d000004481-e3-51b0a288ecdf
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F0.20.17537.882A0B15; Thu,  6 Jun 2013 16:54:00 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 10:53:59 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
Thread-Topic: [manet] Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
Thread-Index: AQHOYsFKTfUt5Sz74UK8tC8DlKruYpkpCOEA
Date: Thu, 6 Jun 2013 14:53:59 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4715D995@eusaamb101.ericsson.se>
References: <20130605150955.25672.65454.idtracker@ietfa.amsl.com> <090201ce629e$9712a760$c537f620$@olddog.co.uk> <CADnDZ8-d6bzbJ9RHPwg-=zwFxRhegRdUrGoSTAipr3Qf2sd5yA@mail.gmail.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com>
In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10142BC9@xmb-aln-x03.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0D8E8128D3A6AB4A93A654C8BE56BB7F@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonQbdj0YZAg1PPjSy+3WhlsvjRc4PZ 4t+WJ+wWLffusVusfv+I3YHVY8rvjaweO2fdZfdYsuQnk8eKzSsZA1iiuG2SEkvKgjPT8/Tt Ergzfr+7zliwVLZi2cMG9gbGNokuRk4OCQETiXd3v7BC2GISF+6tZ+ti5OIQEjjKKHHq8VJ2 CGcZo8TXjR1sIFVsAjoSzx/9YwaxRQSMJFY928gIUsQsMIdRYm/LJLB2YYEZjBLXru1kgaia ySjR/9EVpuPq8gWMIDaLgIpE475vYFN5BbwlTq05xgSx7g+jxL1Db9hBEpwCvhJrJl9kArEZ gQ78fmoNmM0sIC5x68l8JojDBSSW7DnPDGGLSrx8/A/qIWWJJU/2s0DU60gs2P2JDcK2lthz +C4jhK0tsWzha2aIIwQlTs58wjKBUXwWkhWzkLTPQtI+C0n7LCTtCxhZVzFylBanluWmGxls YgRG5DEJNt0djHteWh5ilOZgURLnVeNdHCgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDE0RwSTUw ugbOD3t0xmfJ3z2btT2Y8/gW7rz2jVtFn1uy5unZPU5bLok9iNozZ+f3xT2XWH8s7xHs0fsi 3Lt7w2mTs3Wanrz1XTkivyqTDSf+MfTazRji2t328+jFpd5XbhXM+mD+QIGtqVqWy9HdvLAg IVKhuuzkD2bVFrcOyxCpY44ild1m3haGc/8osRRnJBpqMRcVJwIAOjhxapsCAAA=
X-Mailman-Approved-At: Thu, 06 Jun 2013 08:09:35 -0700
Cc: OSPF List <ospf@ietf.org>, "manet@ietf.org List" <manet@ietf.org>
Subject: Re: [manet] Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 14:54:06 -0000

Abdussalam,=20

Your questions on this OSPF WG document were not posted to the OSPF list. H=
ence, your "public complaint" is completely without merit. Please refer to =
RFC 2026, section 1.2.=20

Thanks,
Acee=20

On Jun 6, 2013, at 10:22 AM, Stan Ratliff (sratliff) wrote:

> Abdussalam,=20
>=20
> I'm forwarding your email to the OSPF mailing list and Acee Lindem (the d=
ocument shepherd). Just FYI, no one on the MANET list has responded since t=
his is an OSPF issue.=20
>=20
> Regards,
> Stan
>=20
> On Jun 6, 2013, at 6:20 AM, Abdussalam Baryun wrote:
>=20
>> Dear IETF AD,
>>=20
>> I hope that my questions are to be answered. Please note that I don't
>> think I have to remind editors even if they are busy, because I am
>> busy as well. IMHO, if an editor is busy or not able to reply to
>> community he/she should not take any work of the IETF. Please note
>> that this is a public complain from me about the editors of this I-D
>> not answering to my questions.
>>=20
>> AB
>>=20
>> On 6/6/13, Adrian Farrel <adrian@olddog.co.uk> wrote:
>>> Heads up.
>>>=20
>>> This I-D is in IETF last call.
>>>=20
>>> I know some of you had comments on a previous version. Please send any
>>> further
>>> comments as described for IETF last call and *NOT* to this list.
>>>=20
>>> Thanks,
>>> Adrian
>>>=20
>>>> -----Original Message-----
>>>> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-
>>>> bounces@ietf.org] On Behalf Of The IESG
>>>> Sent: 05 June 2013 16:10
>>>> To: IETF-Announce
>>>> Cc: ospf@ietf.org
>>>> Subject: Last Call: <draft-ietf-ospf-manet-single-hop-mdr-03.txt> (Use=
 of
>>> OSPF-
>>>> MDR in Single-Hop Broadcast Networks) to Experimental RFC
>>>>=20
>>>>=20
>>>> The IESG has received a request from the Open Shortest Path First IGP =
WG
>>>> (ospf) to consider the following document:
>>>> - 'Use of OSPF-MDR in Single-Hop Broadcast Networks'
>>>> <draft-ietf-ospf-manet-single-hop-mdr-03.txt> as Experimental RFC
>>>>=20
>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>>> final comments on this action. Please send substantive comments to the
>>>> ietf@ietf.org mailing lists by 2013-06-19. Exceptionally, comments may=
 be
>>>> sent to iesg@ietf.org instead. In either case, please retain the
>>>> beginning of the Subject line to allow automated sorting.
>>>>=20
>>>> Abstract
>>>>=20
>>>>=20
>>>> RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks
>>>> (MANETs) by specifying its operation on the new OSPF interface of type
>>>> MANET.  This document describes the use of OSPF-MDR in a single-hop
>>>> broadcast network, which is a special case of a MANET in which each
>>>> router is a (one-hop) neighbor of each other router.  Unlike an OSPF
>>>> broadcast interface, such an interface can have a different cost
>>>> associated with each neighbor.  The document includes configuration
>>>> recommendations and simplified mechanisms that can be used in single-h=
op
>>>> broadcast networks.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> The file can be obtained via
>>>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/
>>>>=20
>>>> IESG discussion can be tracked via
>>>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/b=
allot/
>>>>=20
>>>>=20
>>>> No IPR declarations have been submitted directly on this I-D.
>>>=20
>>>=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
>=20


From internet-drafts@ietf.org  Thu Jun  6 08:13:58 2013
Return-Path: <internet-drafts@ietf.org>
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 261C021F9966; Thu,  6 Jun 2013 08:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.445
X-Spam-Level: 
X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvbSn99n9jX4; Thu,  6 Jun 2013 08:13:57 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C97F21F9984; Thu,  6 Jun 2013 08:13:57 -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.50
Message-ID: <20130606151357.16350.38685.idtracker@ietfa.amsl.com>
Date: Thu, 06 Jun 2013 08:13:57 -0700
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-04.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 15:13:58 -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           : Security Threats for NHDP
	Author(s)       : Ulrich Herberg
                          Jiazi Yi
                          Thomas Heide Clausen
	Filename        : draft-ietf-manet-nhdp-sec-threats-04.txt
	Pages           : 17
	Date            : 2013-06-06

Abstract:
   This document analyzes common security threats of the Neighborhood
   Discovery Protocol (NHDP), and describes their potential impacts on
   MANET routing protocols using NHDP.  This document is not intended to
   propose solutions to the threats described.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From ulrich@herberg.name  Thu Jun  6 08:18:31 2013
Return-Path: <ulrich@herberg.name>
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 2932921F9371 for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 08:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur1DjCfyIwLX for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 08:18:30 -0700 (PDT)
Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8A221F9349 for <manet@ietf.org>; Thu,  6 Jun 2013 08:18:30 -0700 (PDT)
Received: by mail-ve0-f181.google.com with SMTP id db10so2263484veb.40 for <manet@ietf.org>; Thu, 06 Jun 2013 08:18: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 :content-type; bh=qT2xUV2UuqaZ3u7A56zT9k5ufgPnYF3RyZuERs8qMUk=; b=1Cz8DmzvSShdZrt2K94rk8h0SqgkAhVQ311lI0E0f5LvpMtzSsYx3VCNcIrijKw2Lp /xiUF/tybkFEDuTpfiqNU3R/0g7k6v1w1N/2fmv68ziPJRcMoJgWKk5+DCk7QgHEnhDn 41iE7acAT2wQ5LxrbnllBqoeTX9L56ftkvcn4=
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 :content-type:x-gm-message-state; bh=qT2xUV2UuqaZ3u7A56zT9k5ufgPnYF3RyZuERs8qMUk=; b=HTVaU7khS3MbBdG1SiiG9JDQbNxQLBko3GiQlflLQkZUz8CkctZXuAc7KS7SQBsBvh LMxX/D4oWSIV9TYOaKm2WnYmapSEC9XG9xUHEHToEx+7yl6U2cJ10+x1SPYZpNF3pDOe ZRC1fNCYqUVOaQ6dD3k0i4CE0pXUQ4Sua/BxXGwSxAlsP5JmG8MLoyXkPjP8/krfmaCI siI4TmSiQmZO565XN987VkfYTSP+18Du0Lg497ZCmxBUi3HGDZj+MAQ6PkKbqK1y61ED nTSSXMUwBJBt6wNdHvpC2RmM6uyhofXpQ6ZXi0Ce3/DFUqfRjfGW6GQHmpA0kgJMLtSZ qsjg==
MIME-Version: 1.0
X-Received: by 10.52.157.138 with SMTP id wm10mr18949592vdb.57.1370531909472;  Thu, 06 Jun 2013 08:18:29 -0700 (PDT)
Received: by 10.220.29.7 with HTTP; Thu, 6 Jun 2013 08:18:29 -0700 (PDT)
In-Reply-To: <20130606151357.16350.39448.idtracker@ietfa.amsl.com>
References: <20130606151357.16350.39448.idtracker@ietfa.amsl.com>
Date: Thu, 6 Jun 2013 08:18:29 -0700
Message-ID: <CAK=bVC9R0Q+63oMU-dNsnFJ4vDWYU_hw901Hsc6BcZdo8Lvv_A@mail.gmail.com>
From: Ulrich Herberg <ulrich@herberg.name>
To: manet@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmEyM/0Glpi4UzZjtrvJjqp0RPimJ7LodFUIm7o10IlZzlpeaWRNrGky4KBWx5j8mct0Cs2
Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-nhdp-sec-threats-04.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 15:18:31 -0000

Hello,

we have submitted a new revision of nhdp-sec-threats, addressing Joe's
and Adrian's comments in IETF Last Call.
There were no other objections or comments to the draft in IETF LC,
besides a complaint of Abdussalam to be listed in the acknowledgments.
We believe that only comments that lead to significant improvements of
the draft deserve a listing in the acknowledgment section, and we have
therefore not modified the section.

Best regards
Ulrich


---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>
Date: Thu, Jun 6, 2013 at 8:13 AM
Subject: New Version Notification for draft-ietf-manet-nhdp-sec-threats-04.txt
To: Thomas Heide Clausen <t.clausen@computer.org>, Ulrich Herberg
<ulrich@herberg.name>, Jiazi Yi <jiazi@jiaziyi.com>, "Thomas H.
Clausen" <T.Clausen@computer.org>



A new version of I-D, draft-ietf-manet-nhdp-sec-threats-04.txt
has been successfully submitted by Ulrich Herberg and posted to the
IETF repository.

Filename:        draft-ietf-manet-nhdp-sec-threats
Revision:        04
Title:           Security Threats for NHDP
Creation date:   2013-06-06
Group:           manet
Number of pages: 17
URL:
http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-04.txt
Status:
http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats
Htmlized:        http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-04
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-sec-threats-04

Abstract:
   This document analyzes common security threats of the Neighborhood
   Discovery Protocol (NHDP), and describes their potential impacts on
   MANET routing protocols using NHDP.  This document is not intended to
   propose solutions to the threats described.




The IETF Secretariat

From salo@saloits.com  Thu Jun  6 12:33:48 2013
Return-Path: <salo@saloits.com>
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 7DCBC11E80E4 for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 12:33:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1td80-8FMae for <manet@ietfa.amsl.com>; Thu,  6 Jun 2013 12:33:41 -0700 (PDT)
Received: from mail.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id A9CD211E80F6 for <manet@ietf.org>; Thu,  6 Jun 2013 12:33:39 -0700 (PDT)
Received: from [192.168.255.119] (thinkpad2.saloits.com [192.168.255.119]) by mail.saloits.com (8.14.4/8.14.3) with ESMTP id r56JXcTA002580; Thu, 6 Jun 2013 14:33:38 -0500
Message-ID: <51B0E412.7080308@saloits.com>
Date: Thu, 06 Jun 2013 14:33:38 -0500
From: "Timothy J. Salo" <salo@saloits.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: manet@ietf.org
References: <20130606151357.16350.39448.idtracker@ietfa.amsl.com> <CAK=bVC9R0Q+63oMU-dNsnFJ4vDWYU_hw901Hsc6BcZdo8Lvv_A@mail.gmail.com>
In-Reply-To: <CAK=bVC9R0Q+63oMU-dNsnFJ4vDWYU_hw901Hsc6BcZdo8Lvv_A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [manet] Fwd: New Version Notification for draft-ietf-manet-nhdp-sec-threats-04.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 19:33:48 -0000

On 6/6/2013 10:18 AM, Ulrich Herberg wrote:
> We believe that only comments that lead to significant improvements of
> the draft deserve a listing in the acknowledgment section, and we have
> therefore not modified the section.

+1

-tjs


From valerio.arnaboldi@iit.cnr.it  Sun Jun  9 04:52:40 2013
Return-Path: <valerio.arnaboldi@iit.cnr.it>
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 6A30121F8E9D for <manet@ietfa.amsl.com>; Sun,  9 Jun 2013 04:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.481
X-Spam-Level: **
X-Spam-Status: No, score=2.481 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iocsa80A8+U0 for <manet@ietfa.amsl.com>; Sun,  9 Jun 2013 04:52:40 -0700 (PDT)
Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1741321F8E93 for <manet@ietf.org>; Sun,  9 Jun 2013 04:52:40 -0700 (PDT)
Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by mxbk.iit.cnr.it (Postfix) with ESMTPA id 755E0C3686 for <manet@ietf.org>; Sun,  9 Jun 2013 13:52:39 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Valerio Arnaboldi<valerio.arnaboldi@iit.cnr.it>
To: manet@ietf.org
Message-Id: <20130609115240.1741321F8E93@ietfa.amsl.com>
Date: Sun,  9 Jun 2013 04:52:40 -0700 (PDT)
Subject: [manet] Call for demos - SustainIT 2013 (deadline June 20)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jun 2013 11:52:40 -0000

-------------------------------------------------------------------
*** Our apologies if you receive multiple copies of this e-mail ***
-------------------------------------------------------------------

                        CALL FOR DEMONSTRATIONS
                      The Third IFIP Conference on

            Sustainable Internet and ICT for Sustainability
                            (SustainIT 2013)

           http://www.dicgim.unipa.it/networks/sustainit2013

                          October 30-31, 2013
                        Palermo, Sicily, Italy

- Technically sponsored by the IFIP TC6 WG 6.3 (Performance of Communication Systems)
- Technically co-sponsored by IEEE TCCC (Technical Committee on Computer Communications)
- In cooperation with IEEE TSGCC (Technical Subcommittee on Green Communications and Computing)
- Supported by EINS: The Network of Excellence in Internet Science

------------------------------------------------------------------------
SCOPE AND OVERVIEW
------------------------------------------------------------------------

SUSTAINIT 2013 will feature a demo session providing a forum for researchers and developers from academia, industry, and government to interact and share latest research results on the areas of Sustainable Internet and ICT for Sustainability. Towards this goal, SUSTAINIT seeks participations from all three entities. Demonstrations offer the opportunity to present novel ideas and emerging results through innovative applications and tools. Demo submissions are welcome in all aspects of Sustainable Internet and ICT for Sustainability, including algorithms, protocols, applications, hardware and tools, new research prototypes, testbeds, etc. Authors are 
asked to submit a demo paper of up to 3 pages (including figures, tables, and references). The demo paper should highlight the main contributions and describe the details of the demonstrations, with a focus on the interaction with the audience. Please refer to the Submission Instructions below for more details.

IMPORTANT DATES
------------------------------------------------------------------------

- Demo paper submission deadline:         June 20, 2013
- Acceptance/Reject notification:         July 15, 2013
- Camera-ready version due:               July 30, 2013

DEMO PAPER SUBMISSION
------------------------------------------------------------------------
Papers must be submitted electronically in PDF format through EDAS (http://edas.info/newPaper.php?c=14317). Manuscripts must be formatted in accordance with the IEEE Computer Society author guidelines (http://edas.info/newPaper.php?c=14317). Demo papers must be limited to 3 pages, single spacing, double column, and must strictly adhere to the template format. Detailed instructions for manuscript preparation and submission are available on the conference website (http://www.dicgim.unipa.it/networks/sustainit2013/submission.html).


FOR MORE INFORMATION
------------------------------------------------------------------------
For questions about the demonstration submission and review  process, please contact the SUSTAINIT 2013 Demonstration Co-Chairs:

Daniele Puccinelli, SUPSI, Switzerland - daniele (dot) puccinelli (at) supsi ch
Pablo Serrano, Universidad Carlos III de Madrid, Spain - pablo (at) it (dot) uc3m (dot) es



From internet-drafts@ietf.org  Sun Jun  9 12:00:22 2013
Return-Path: <internet-drafts@ietf.org>
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 D427721F9732; Sun,  9 Jun 2013 12:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.523
X-Spam-Level: 
X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stdTeme+3M2t; Sun,  9 Jun 2013 12:00:21 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 177E221F940D; Sun,  9 Jun 2013 12:00:18 -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.50
Message-ID: <20130609190017.678.1900.idtracker@ietfa.amsl.com>
Date: Sun, 09 Jun 2013 12:00:17 -0700
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-10.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jun 2013 19:00:23 -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	 Optimized Link St=
ate Routing Protocol version 2
	Author(s)       : Ulrich Herberg
                          Robert G. Cole
                          Thomas Heide Clausen
	Filename        : draft-ietf-manet-olsrv2-mib-10.txt
	Pages           : 84
	Date            : 2013-06-09

Abstract:
   This document defines the Management Information Base (MIB) module
   for configuring and managing the Optimized Link State Routing
   protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
   into configuration information, state information, performance
   information, and notifications.  This additional state and
   performance information is useful to troubleshoot problems and
   performance issues of the routing protocol.  Two levels of compliance
   allow this MIB module to be deployed on constrained routers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mib-10


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From abdussalambaryun@gmail.com  Mon Jun 10 03:51:10 2013
Return-Path: <abdussalambaryun@gmail.com>
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 4527C21F85BF for <manet@ietfa.amsl.com>; Mon, 10 Jun 2013 03:51:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eaf0HSl51a+N for <manet@ietfa.amsl.com>; Mon, 10 Jun 2013 03:51:03 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39C21F86FB for <manet@ietf.org>; Mon, 10 Jun 2013 03:51:02 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id fa11so4314460pad.33 for <manet@ietf.org>; Mon, 10 Jun 2013 03:51:01 -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=dt3lMBRegUT5CHyVO/N0RvMziBHGY3jUTEUEpX/rLH8=; b=JMxAkbCzDq9v4/nSS36VjrWLRwiN7xFll2M9qtq9RK6Mr32H0sdLCfITdCnhBbqar1 SyyTuthncVv/Eq1kZIGoTapLdc0qB4QAqr7953dc1M5bBenVRO7aK3hFDqtdzmtKAzae enOZYHZ0vpfzORBuhuVpRuJBwyAPYGM49ZqtOB5rHQYcqwWUF58rTZfngXHj5zvQbG0K R77GsNTefqy1X3RcaBbFDEZ2DC2fgnAA2PxlesUfkES713IQxPOnUZf3zWJPGQ+nQhpU jPSdZTafIDC+3NPCdbLr4+PI3XH5+Rr87Zapn/vbLoS39Dv735sDW54EEeIgypgZpVls pFEg==
MIME-Version: 1.0
X-Received: by 10.68.103.194 with SMTP id fy2mr9287265pbb.158.1370861461762; Mon, 10 Jun 2013 03:51:01 -0700 (PDT)
Received: by 10.68.78.164 with HTTP; Mon, 10 Jun 2013 03:51:01 -0700 (PDT)
In-Reply-To: <CAK=bVC9R0Q+63oMU-dNsnFJ4vDWYU_hw901Hsc6BcZdo8Lvv_A@mail.gmail.com>
References: <20130606151357.16350.39448.idtracker@ietfa.amsl.com> <CAK=bVC9R0Q+63oMU-dNsnFJ4vDWYU_hw901Hsc6BcZdo8Lvv_A@mail.gmail.com>
Date: Mon, 10 Jun 2013 12:51:01 +0200
Message-ID: <CADnDZ8_ZUzkpJwhS7X8UwFB6pUT6e96TFr-mv=NpequBJJE_YQ@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Ulrich Herberg <ulrich@herberg.name>
Content-Type: text/plain; charset=ISO-8859-1
Cc: manet@ietf.org
Subject: Re: [manet] Fwd: New Version Notification for draft-ietf-manet-nhdp-sec-threats-04.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 10:51:11 -0000

I understood your policy in editing contributions, so I will not
participate any more in any future work you author in ietf or manet.
If I get a request to review a work having similar authors, I will
appologies and refer to the message I received below. If all WGs hold
the same policy, then I would like to understand, because I have
specific understanding of team work.

Thanking you for clarification.

AB

On 6/6/13, Ulrich Herberg <ulrich@herberg.name> wrote:
> Hello,
>
> we have submitted a new revision of nhdp-sec-threats, addressing Joe's
> and Adrian's comments in IETF Last Call.
> There were no other objections or comments to the draft in IETF LC,
> besides a complaint of Abdussalam to be listed in the acknowledgments.
> We believe that only comments that lead to significant improvements of
> the draft deserve a listing in the acknowledgment section, and we have
> therefore not modified the section.
>
> Best regards
> Ulrich
>
>
> ---------- Forwarded message ----------
> From:  <internet-drafts@ietf.org>
> Date: Thu, Jun 6, 2013 at 8:13 AM
> Subject: New Version Notification for
> draft-ietf-manet-nhdp-sec-threats-04.txt
> To: Thomas Heide Clausen <t.clausen@computer.org>, Ulrich Herberg
> <ulrich@herberg.name>, Jiazi Yi <jiazi@jiaziyi.com>, "Thomas H.
> Clausen" <T.Clausen@computer.org>
>
>
>
> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-04.txt
> has been successfully submitted by Ulrich Herberg and posted to the
> IETF repository.
>
> Filename:        draft-ietf-manet-nhdp-sec-threats
> Revision:        04
> Title:           Security Threats for NHDP
> Creation date:   2013-06-06
> Group:           manet
> Number of pages: 17
> URL:
> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-04.txt
> Status:
> http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats
> Htmlized:
> http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-04
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-sec-threats-04
>
> Abstract:
>    This document analyzes common security threats of the Neighborhood
>    Discovery Protocol (NHDP), and describes their potential impacts on
>    MANET routing protocols using NHDP.  This document is not intended to
>    propose solutions to the threats described.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

From l.wood@surrey.ac.uk  Mon Jun 10 05:10:26 2013
Return-Path: <l.wood@surrey.ac.uk>
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 3D11921F8CB4 for <manet@ietfa.amsl.com>; Mon, 10 Jun 2013 05:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.078
X-Spam-Level: 
X-Spam-Status: No, score=-4.078 tagged_above=-999 required=5 tests=[AWL=2.520,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P3AB9R-7nMh for <manet@ietfa.amsl.com>; Mon, 10 Jun 2013 05:09:43 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) by ietfa.amsl.com (Postfix) with ESMTP id 066C521F88AC for <manet@ietf.org>; Mon, 10 Jun 2013 05:08:42 -0700 (PDT)
Received: from [195.245.230.131:59759] by server-3.bemta-3.messagelabs.com id 0D/A4-12734-9C1C5B15; Mon, 10 Jun 2013 12:08:41 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-12.tower-78.messagelabs.com!1370866120!29017450!1
X-Originating-IP: [131.227.200.39]
X-StarScan-Received: 
X-StarScan-Version: 6.9.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21315 invoked from network); 10 Jun 2013 12:08:40 -0000
Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-12.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 10 Jun 2013 12:08:40 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.180]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Mon, 10 Jun 2013 13:08:40 +0100
From: <l.wood@surrey.ac.uk>
To: <abdussalambaryun@gmail.com>
Date: Mon, 10 Jun 2013 13:08:40 +0100
Thread-Topic: [manet] Fwd: New Version Notification for draft-ietf-manet-nhdp-sec-threats-04.txt
Thread-Index: Ac5lyHqz0kaQ8Wb6R1ia6bTRXaNURQACVfmr
Message-ID: <290E20B455C66743BE178C5C84F12408223F494EA6@EXMB01CMS.surrey.ac.uk>
References: <20130606151357.16350.39448.idtracker@ietfa.amsl.com> <CAK=bVC9R0Q+63oMU-dNsnFJ4vDWYU_hw901Hsc6BcZdo8Lvv_A@mail.gmail.com>, <CADnDZ8_ZUzkpJwhS7X8UwFB6pUT6e96TFr-mv=NpequBJJE_YQ@mail.gmail.com>
In-Reply-To: <CADnDZ8_ZUzkpJwhS7X8UwFB6pUT6e96TFr-mv=NpequBJJE_YQ@mail.gmail.com>
Accept-Language: en-US, en-GB
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: manet@ietf.org
Subject: Re: [manet] Fwd: New Version Notification for	draft-ietf-manet-nhdp-sec-threats-04.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 12:10:28 -0000

AB,

This isn't established WG policy, but an author team decision that just hap=
pens to also be the generally accepted convention for handling the matter.

But, as it's not policy, can I also request the same non-participation from=
 you for any drafts I author?

(I'd like to get in early, before the rush.)

Lloyd Wood
http://sat-net.com/L.Wood/


________________________________________
From: manet-bounces@ietf.org [manet-bounces@ietf.org] On Behalf Of Abdussal=
am Baryun [abdussalambaryun@gmail.com]
Sent: 10 June 2013 11:51
To: Ulrich Herberg
Cc: manet@ietf.org
Subject: Re: [manet] Fwd: New Version Notification for  draft-ietf-manet-nh=
dp-sec-threats-04.txt

I understood your policy in editing contributions, so I will not
participate any more in any future work you author in ietf or manet.
If I get a request to review a work having similar authors, I will
appologies and refer to the message I received below. If all WGs hold
the same policy, then I would like to understand, because I have
specific understanding of team work.

Thanking you for clarification.

AB

On 6/6/13, Ulrich Herberg <ulrich@herberg.name> wrote:
> Hello,
>
> we have submitted a new revision of nhdp-sec-threats, addressing Joe's
> and Adrian's comments in IETF Last Call.
> There were no other objections or comments to the draft in IETF LC,
> besides a complaint of Abdussalam to be listed in the acknowledgments.
> We believe that only comments that lead to significant improvements of
> the draft deserve a listing in the acknowledgment section, and we have
> therefore not modified the section.
>
> Best regards
> Ulrich
>
>
> ---------- Forwarded message ----------
> From:  <internet-drafts@ietf.org>
> Date: Thu, Jun 6, 2013 at 8:13 AM
> Subject: New Version Notification for
> draft-ietf-manet-nhdp-sec-threats-04.txt
> To: Thomas Heide Clausen <t.clausen@computer.org>, Ulrich Herberg
> <ulrich@herberg.name>, Jiazi Yi <jiazi@jiaziyi.com>, "Thomas H.
> Clausen" <T.Clausen@computer.org>
>
>
>
> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-04.txt
> has been successfully submitted by Ulrich Herberg and posted to the
> IETF repository.
>
> Filename:        draft-ietf-manet-nhdp-sec-threats
> Revision:        04
> Title:           Security Threats for NHDP
> Creation date:   2013-06-06
> Group:           manet
> Number of pages: 17
> URL:
> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-04.=
txt
> Status:
> http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats
> Htmlized:
> http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-04
> Diff:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-04
>
> Abstract:
>    This document analyzes common security threats of the Neighborhood
>    Discovery Protocol (NHDP), and describes their potential impacts on
>    MANET routing protocols using NHDP.  This document is not intended to
>    propose solutions to the threats described.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> 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 internet-drafts@ietf.org  Mon Jun 10 13:27:56 2013
Return-Path: <internet-drafts@ietf.org>
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 D8D7E21F922A; Mon, 10 Jun 2013 13:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.536
X-Spam-Level: 
X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phlwpyv-pH-8; Mon, 10 Jun 2013 13:27:56 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2035E21E8096; Mon, 10 Jun 2013 13:27:54 -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.51
Message-ID: <20130610202754.25404.98190.idtracker@ietfa.amsl.com>
Date: Mon, 10 Jun 2013 13:27:54 -0700
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-05.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 20:27:57 -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           : Security Threats for NHDP
	Author(s)       : Ulrich Herberg
                          Jiazi Yi
                          Thomas Heide Clausen
	Filename        : draft-ietf-manet-nhdp-sec-threats-05.txt
	Pages           : 18
	Date            : 2013-06-10

Abstract:
   This document analyzes common security threats of the Neighborhood
   Discovery Protocol (NHDP), and describes their potential impacts on
   MANET routing protocols using NHDP.  This document is not intended to
   propose solutions to the threats described.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From ulrich@herberg.name  Mon Jun 10 13:34:04 2013
Return-Path: <ulrich@herberg.name>
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 A45F321F861F for <manet@ietfa.amsl.com>; Mon, 10 Jun 2013 13:34:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UJmvQS-kk+X for <manet@ietfa.amsl.com>; Mon, 10 Jun 2013 13:34:03 -0700 (PDT)
Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C559F21F8749 for <manet@ietf.org>; Mon, 10 Jun 2013 13:34:01 -0700 (PDT)
Received: by mail-ve0-f172.google.com with SMTP id jz10so5165150veb.17 for <manet@ietf.org>; Mon, 10 Jun 2013 13:34:01 -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=hSw971eJSZ1FDPo78t98YLAaqqN9Isw5lVu+whRpxAk=; b=hmqlMlEXB4wRSWKfmgeM2liNWMefNn6TeQ3WkuMaBHPUFfEU4q6Z/IjhGy3caL5iIz 4sHSmBjeDqOImnD6mW9yU/EdNKZwSPxdUKXK9zTHbnrqrIr7EW9V8R1anRL/DJ3pyBc1 LYyupddFmsfZRuE3AIFdQskIrtztaD4Mso5eQ=
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=hSw971eJSZ1FDPo78t98YLAaqqN9Isw5lVu+whRpxAk=; b=LRZ0jnebKtodzz52+dNWSgcwvliKcX+GaIn3sGJs5Ue0658vIJfhsLVR64gXVtyHhb qxZ443xBYHt2eA+18CZx5R/7zLjZuOv5Gr1WV5nBRkII0TjPNzGqhFohXkfHq0M4ZITI lCeSLoFyWWhS57gGWaStJFvJmnSY8XO7NU6iT2Yy/YKbIiwr56jxheAcpjOpfJ/XB+dH T8V+8XaJK+LkS1jvX2oBP9K4C0/WqqqIrBmxRK0dIYEz2fhRGZi4bJs10KGmWtfbYYcf s0Nh5XuX3b4OwjrXzlkpMKY9KxgqaBLysYiT6MlrhoVxsEuzp6BvvM24cIaT+VTus0Ja kPyg==
MIME-Version: 1.0
X-Received: by 10.52.232.69 with SMTP id tm5mr5584921vdc.117.1370896441192; Mon, 10 Jun 2013 13:34:01 -0700 (PDT)
Received: by 10.220.29.7 with HTTP; Mon, 10 Jun 2013 13:34:01 -0700 (PDT)
In-Reply-To: <20130523222242.3631.36122.idtracker@ietfa.amsl.com>
References: <20130523222242.3631.36122.idtracker@ietfa.amsl.com>
Date: Mon, 10 Jun 2013 13:34:01 -0700
Message-ID: <CAK=bVC9WJdDoi481bLxa9ibHa690Vg3xa-iWfrG2F4jGgCPc+w@mail.gmail.com>
From: Ulrich Herberg <ulrich@herberg.name>
To: ietf@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlBeXhbH7PFhYdiZ7tL3ZWP1lztWiImF47Xa5Cqyl86XlP1/ewYUNYbMtPqKlD60Y3de17w
Cc: manet@ietf.org
Subject: Re: [manet] Last Call: <draft-ietf-manet-nhdp-sec-threats-03.txt> (Security Threats for NHDP) to Informational RFC
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 20:34:04 -0000

We have submitted a new revision of the draft, addressing one comment
from Adrian during IETF LC (which we wanted to address in the previous
revision, but forgot about it). We added a new section that can
trigger future work, as requested by Adrian.

To the WG: Obviously, the new text is up for discussion if anyone has
any issues with it.

Best regards
Ulrich

On Thu, May 23, 2013 at 3:22 PM, The IESG <iesg-secretary@ietf.org> wrote:
>
> The IESG has received a request from the Mobile Ad-hoc Networks WG
> (manet) to consider the following document:
> - 'Security Threats for NHDP'
>   <draft-ietf-manet-nhdp-sec-threats-03.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2013-06-06. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>    This document analyses common security threats of the Neighborhood
>    Discovery Protocol (NHDP), and describes their potential impacts on
>    MANET routing protocols using NHDP.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

From charliep@computer.org  Tue Jun 11 17:40:50 2013
Return-Path: <charliep@computer.org>
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 CD1F821F9B4D for <manet@ietfa.amsl.com>; Tue, 11 Jun 2013 17:40:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5uqkzoul1Im for <manet@ietfa.amsl.com>; Tue, 11 Jun 2013 17:40:46 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8FE21F9B3F for <manet@ietf.org>; Tue, 11 Jun 2013 17:40:45 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1UmZ7D-0004Au-Cx; Tue, 11 Jun 2013 20:40:43 -0400
Message-ID: <51B7C382.2080608@computer.org>
Date: Tue, 11 Jun 2013 17:40:34 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Thomas Meier <nsclick@gmx.de>
References: <trinity-eaf9eee4-0692-4534-9e59-393702af96ba-1370432392554@3capp-gmx-bs19> <CAK=bVC9knJ55RB1GxtnYLYjUzCJnwYd=c2fGVXs2v808ZEX=+Q@mail.gmail.com>
In-Reply-To: <CAK=bVC9knJ55RB1GxtnYLYjUzCJnwYd=c2fGVXs2v808ZEX=+Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86803832dc96a80a591d3d66718e6652f8350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Cc: manet@ietf.org
Subject: Re: [manet] Forwarding AODV messages over a tunnel
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jun 2013 00:40:50 -0000

Hello Thomas,

AODV and other Manet protocols do not impose any restriction on
choice of tunnel mechanism to my knowledge, so basically I agree
with Ulrich.  However, some tunneling mechanisms impose their
own restrictions, and one could imagine defining a tunnel protocol
with unusual conditions.  Depending on the choice, it is likely that
error conditions will be handled differently, or fragmentation, or
perhaps QoS restrictions would come into play.

If someone wanted to go to the trouble of using tunnels to
circumvent hopcount restrictions, I don't think there would be
anything to prevent that.  But, on the other hand, a malicious
router could just set the TTL to be any arbitrary value, so this
might be an unproductive use for a tunnel.

Regards,
Charlie P.




On 6/5/2013 10:23 AM, Ulrich Herberg wrote:
> Thomas,
>
> (replying to manet@ietf.org, which I think is the better place to ask
> this question rather than ietf@ietf.org)
>
> What kind of tunnel do you want to use? IP-in-IP tunnel or L2 tunnel
> or something else (IP-over-foo)?
> In either way, reactive MANET protocols (as well as the proactive
> ones) forward messages hop-by-hop, using a link-local multicast
> address. If you use an IP-in-IP tunnel or L2 tunnel, the control
> message would not be modified, and to the MANET protocol it would look
> like a single hop (hop-count++, IP src address = tunnel start point).
>
> Side-note: a wormhole is itself just a normal link; I don't see a
> difference between a "legitimate" link/tunnel and a wormhole, unless
> the wormhole does something "bad" with the actual data (dropping
> packets, eavesdropping, advertising wrong link metrics etc).
>
> Best regards
> Ulrich
>
> On Wed, Jun 5, 2013 at 4:39 AM, Thomas Meier <nsclick@gmx.de> wrote:
>> Hello,
>>
>> I want to forward AODV messages over a tunnel (don't worry, it's not for a wormhole attack).
>> In the RFC3561 I can't find information about how to deal with the packet at the tunnel endpoint. Should I increment the hopcount of a RREQ by one or by the number of hops the tunnel has? Furthermore I'm wondering about which address to use for the previous node at the tunnel endpoint. Should this be the entrance of the tunnel or the "real" previous node?
>> If the tunnel entrance is used as previous node and the hopcount is only incremented by one, the tunnel would be prefered compared to a connection without a tunnel (like in wormhole attacks).
>> Is there some information on how to deal with a tunnel?
>>
>> Thanks,
>>
>> Thomas
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>


-- 
Regards,
Charlie P.


From trac+manet@trac.tools.ietf.org  Wed Jun 12 15:41:53 2013
Return-Path: <trac+manet@trac.tools.ietf.org>
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 38C6511E811A for <manet@ietfa.amsl.com>; Wed, 12 Jun 2013 15:41:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrxoxGDcPdaa for <manet@ietfa.amsl.com>; Wed, 12 Jun 2013 15:41:52 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAF611E8119 for <manet@ietf.org>; Wed, 12 Jun 2013 15:41:51 -0700 (PDT)
Received: from localhost ([127.0.0.1]:43853 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+manet@trac.tools.ietf.org>) id 1UmtjY-0006jo-64; Thu, 13 Jun 2013 00:41:40 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "manet issue tracker" <trac+manet@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: charliep@computer.org
X-Trac-Project: manet
Date: Wed, 12 Jun 2013 22:41:40 -0000
X-URL: http://tools.ietf.org/manet/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/3#comment:1
Message-ID: <076.ecd34e743b67a0017d1bbb5283e523b4@trac.tools.ietf.org>
References: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org>
X-Trac-Ticket-ID: 3
In-Reply-To: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org
X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: manet@ietf.org
Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: manet@ietf.org
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jun 2013 22:41:53 -0000

#3: Use msg-hop-count in RFC 5444 header to limit # of hops


Comment (by charliep@computer.org):

 ----
 From: Thomas Heide Clausen 11/1/2012 5:18 AM --
 That would be a direct violation of the definition of <msg-hop-limit> and
 <msg-hop-count> in RFC5444, and would render any generic
 demultiplexing/dispatching/forwarding framework inapplicable.

 This proposal is, therefore, not acceptable under any circumstances.

 ----
 From: Dearlove, Christopher (UK) 11/1/2012 6:50 AM ----

 Let's consider an RREQ message, which is flooded. The issue is, does it
 mutate on its travels? If not, I don't see why we can't use the 5444 hop
 limit. If it does, then that is not technically an issue for 5444, but
 does have two bad effects:
 - There is a general processing/forwarding engine described in OLSRv2. In
 an ideal world this is another thing that should be in a separate draft.
 It is designed for wider use (hence its inclusion of message type). There
 are reasons I would find that a good model for what I'm going to call son-
 of-AODV, whatever that ends up being based on and called.
 - Unmutated (other than hop count/limit) messages work well with message
 signatures described in 6622 for end to end verification. Mutating
 messages are a bigger headache. They need either new signatures each hop,
 in which case let's just not bother signing messages, but let's sign
 packets - a valid choice, but loses a tool - or some sort of difference
 collecting and aggregating signature that I know nothing about, and may
 not even exist.

 -------
 From: Charles E. Perkins 11/1/2012 10:43 AM -------

 RFC 5444 has this:

    o  <msg-hop-count> field, if present, contains the number of hops on
       which the packet has traveled across the MANET.  The <msg-hop-
       count> is set to 0 by the message originator and is used to
       prevent messages from endlessly circulating in a MANET. When
       forwarding a message, a MANET router should increase <msg-hop-
       count> by 1 and should discard the message when <msg-hop-count>
       reaches 255.

 From this, I conclude that the purpose of the field is to count the
 number of hops a message has traversed.

 -------
 From: Henning Rogge 11/1/2012 10:45 AM -------

 If DYMO changes the content of a message, its not the same message
 anymore. At least thats how I understand this field.

 You could not put a signature on it "end to end" for example.

 -------
 From: Charles E. Perkins 11/1/2012 11:04 AM -------
 RFC 5444 also says this:

    o  For forwarded messages where the message is unchanged by
       forwarding MANET routers, end-to-end authentication and integrity
       MAY be implemented, between MANET routers with an existing
       security association, by including a suitable Message TLV
       containing a cryptographic signature in the message.  Since <msg-
       hop-count> and <msg-hop-limit> are the only fields that should be
       modified when such a message is forwarded in this manner, this
       signature can be calculated based on the entire message, including
       the Message Header, with the <msg-hop-count> and <msg-hop-limit>
       fields set to 0, if present.

 I think this means that the msg-hop-count can be incremented while
 the other content of the message remains the same.

 -------

 On 11/1/2012 12:17 PM, Abdussalam Baryun wrote:

 I agree with the proposal, it seems with advantages, but there maybe
 disadvantages (i.e. violation to rfc5444) that need to be fixed. I don't
 think it is flexible to use only the hop-limit for rfc5444 messages for
 better dissimination, using other fields will give advantages. It may be
 considered to modify RFC5444 in future to accomodate reactive protocols
 advantages.

 -------

-- 
-----------------------------------+------------------------------
 Reporter:  charliep@computer.org  |       Owner:  Charlie Perkins
     Type:  enhancement            |      Status:  new
 Priority:  major                  |   Milestone:
Component:  dymo                   |     Version:
 Severity:  Active WG Document     |  Resolution:
 Keywords:  hop count, hop limit   |
-----------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/3#comment:1>
manet <http://tools.ietf.org/manet/>


From charliep@computer.org  Wed Jun 12 17:10:05 2013
Return-Path: <charliep@computer.org>
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 32FFD21F944C for <manet@ietfa.amsl.com>; Wed, 12 Jun 2013 17:10:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6BPSJfqgecN for <manet@ietfa.amsl.com>; Wed, 12 Jun 2013 17:09:59 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3807121F8F33 for <manet@ietf.org>; Wed, 12 Jun 2013 17:09:58 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1Umv6z-0003YA-Vt for manet@ietf.org; Wed, 12 Jun 2013 20:09:58 -0400
Message-ID: <51B90DCB.2080104@computer.org>
Date: Wed, 12 Jun 2013 17:09:47 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: manet@ietf.org
References: <061.dd96a35b96e4ad8b95c1f2b46c7199f8@trac.tools.ietf.org> <076.ecd34e743b67a0017d1bbb5283e523b4@trac.tools.ietf.org>
In-Reply-To: <076.ecd34e743b67a0017d1bbb5283e523b4@trac.tools.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86dd44e8f2ea945b13f64b9fc9c3c4a84c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Subject: Re: [manet] #3: Use msg-hop-count in RFC 5444 header to limit # of hops
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2013 00:10:05 -0000

Hello folks,

I have collected the previous discussion about issue #3 and
posted the the technical parts of the discussion to the issue tracker,
as reproduced before.  If I have missed any points of the discussion,
please let me know and I will similarly post those points also to
the issue tracker.

While the technical matters involved with issue #3 may still be of
interest and open to discussion, I think that the discussion is no
longer relevant to the working group document, because there isn't
much motivation to make the necessary protocol changes to
utilize the idea.  For this reason, I propose to close the issue without
making any changes to the document.

Regards,
Charlie P.

PS. My plan is to similarly collect the technical discussions related
       to the other issues, and to propose a resolution for each one,
       according to the current state of the AODVv2 document, based
       on the points raised during the discussion.

On 6/12/2013 3:41 PM, manet issue tracker wrote:
> #3: Use msg-hop-count in RFC 5444 header to limit # of hops
>
>
> Comment (by charliep@computer.org):
>
>   ----
>   From: Thomas Heide Clausen 11/1/2012 5:18 AM --
>   That would be a direct violation of the definition of <msg-hop-limit> and
>   <msg-hop-count> in RFC5444, and would render any generic
>   demultiplexing/dispatching/forwarding framework inapplicable.
>
>   This proposal is, therefore, not acceptable under any circumstances.
>
>   ----
>   From: Dearlove, Christopher (UK) 11/1/2012 6:50 AM ----
>
>   Let's consider an RREQ message, which is flooded. The issue is, does it
>   mutate on its travels? If not, I don't see why we can't use the 5444 hop
>   limit. If it does, then that is not technically an issue for 5444, but
>   does have two bad effects:
>   - There is a general processing/forwarding engine described in OLSRv2. In
>   an ideal world this is another thing that should be in a separate draft.
>   It is designed for wider use (hence its inclusion of message type). There
>   are reasons I would find that a good model for what I'm going to call son-
>   of-AODV, whatever that ends up being based on and called.
>   - Unmutated (other than hop count/limit) messages work well with message
>   signatures described in 6622 for end to end verification. Mutating
>   messages are a bigger headache. They need either new signatures each hop,
>   in which case let's just not bother signing messages, but let's sign
>   packets - a valid choice, but loses a tool - or some sort of difference
>   collecting and aggregating signature that I know nothing about, and may
>   not even exist.
>
>   -------
>   From: Charles E. Perkins 11/1/2012 10:43 AM -------
>
>   RFC 5444 has this:
>
>      o  <msg-hop-count> field, if present, contains the number of hops on
>         which the packet has traveled across the MANET.  The <msg-hop-
>         count> is set to 0 by the message originator and is used to
>         prevent messages from endlessly circulating in a MANET. When
>         forwarding a message, a MANET router should increase <msg-hop-
>         count> by 1 and should discard the message when <msg-hop-count>
>         reaches 255.
>
>   From this, I conclude that the purpose of the field is to count the
>   number of hops a message has traversed.
>
>   -------
>   From: Henning Rogge 11/1/2012 10:45 AM -------
>
>   If DYMO changes the content of a message, its not the same message
>   anymore. At least thats how I understand this field.
>
>   You could not put a signature on it "end to end" for example.
>
>   -------
>   From: Charles E. Perkins 11/1/2012 11:04 AM -------
>   RFC 5444 also says this:
>
>      o  For forwarded messages where the message is unchanged by
>         forwarding MANET routers, end-to-end authentication and integrity
>         MAY be implemented, between MANET routers with an existing
>         security association, by including a suitable Message TLV
>         containing a cryptographic signature in the message.  Since <msg-
>         hop-count> and <msg-hop-limit> are the only fields that should be
>         modified when such a message is forwarded in this manner, this
>         signature can be calculated based on the entire message, including
>         the Message Header, with the <msg-hop-count> and <msg-hop-limit>
>         fields set to 0, if present.
>
>   I think this means that the msg-hop-count can be incremented while
>   the other content of the message remains the same.
>
>   -------
>
>   On 11/1/2012 12:17 PM, Abdussalam Baryun wrote:
>
>   I agree with the proposal, it seems with advantages, but there maybe
>   disadvantages (i.e. violation to rfc5444) that need to be fixed. I don't
>   think it is flexible to use only the hop-limit for rfc5444 messages for
>   better dissimination, using other fields will give advantages. It may be
>   considered to modify RFC5444 in future to accomodate reactive protocols
>   advantages.
>
>   -------
>


-- 
Regards,
Charlie P.


From internet-drafts@ietf.org  Wed Jun 12 18:45:54 2013
Return-Path: <internet-drafts@ietf.org>
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 58E1821E8082; Wed, 12 Jun 2013 18:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+VmQvHDeFcF; Wed, 12 Jun 2013 18:45:41 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A70D21E8056; Wed, 12 Jun 2013 18:45:41 -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.51.p2
Message-ID: <20130613014540.21901.50402.idtracker@ietfa.amsl.com>
Date: Wed, 12 Jun 2013 18:45:40 -0700
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-11.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2013 01:45:54 -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	 Optimized Link St=
ate Routing Protocol version 2
	Author(s)       : Ulrich Herberg
                          Robert G. Cole
                          Thomas Heide Clausen
	Filename        : draft-ietf-manet-olsrv2-mib-11.txt
	Pages           : 85
	Date            : 2013-06-12

Abstract:
   This document defines the Management Information Base (MIB) module
   for configuring and managing the Optimized Link State Routing
   protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
   into configuration information, state information, performance
   information, and notifications.  This additional state and
   performance information is useful to troubleshoot problems and
   performance issues of the routing protocol.  Two levels of compliance
   allow this MIB module to be deployed on constrained routers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mib-11


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From sratliff@cisco.com  Wed Jun 12 19:33:04 2013
Return-Path: <sratliff@cisco.com>
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 030C321F949D for <manet@ietfa.amsl.com>; Wed, 12 Jun 2013 19:33: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6vvZfMRC2It for <manet@ietfa.amsl.com>; Wed, 12 Jun 2013 19:32:59 -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 23AAB21F9476 for <manet@ietf.org>; Wed, 12 Jun 2013 19:32:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2242; q=dns/txt; s=iport; t=1371090779; x=1372300379; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=V6JHGs801+34zu8f47rApX56Gq3REDAZfXJscehRWkA=; b=bQvv9eLQPa1ZGeFUJPiWjGupWAFXeJHZ32HlxextajowzD5nq1uXPKDa 1L8ZHVZDTeXO57nT7N6mipWvLWjCqXFHKEyz8bmAGcpU5S3HPzyE+TPuv Tugw+xsdONI2EQQBhrpvMudvGsh2y7Yb6fF9CcE8YitK5rK/AxKMKKJSs E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAEUuuVGtJV2Y/2dsb2JhbABagwkwQwa+UoEAFnSCIwEBAQMBAQEBNzQbAgEqFBAnCyUCBBMIAYd/BgcFuxiPEjiCf2EDk26Ee5AZgw+CJw
X-IronPort-AV: E=Sophos;i="4.87,855,1363132800"; d="scan'208";a="222171083"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 13 Jun 2013 02:32:58 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5D2Wwi8001129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <manet@ietf.org>; Thu, 13 Jun 2013 02:32:58 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.104]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 21:32:57 -0500
From: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
To: "manet@ietf.org List" <manet@ietf.org>
Thread-Topic: draft-ietf-manet-olsrv2-mib-11.txt
Thread-Index: AQHOZ95Qwahaeo17c0GyMQsWFowEaA==
Date: Thu, 13 Jun 2013 02:32:56 +0000
Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1014D4A0@xmb-aln-x03.cisco.com>
References: <20130613014540.21901.50402.idtracker@ietfa.amsl.com>
In-Reply-To: <20130613014540.21901.50402.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.179.211]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <926896B3C1D0E1439CC013C48462E973@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [manet] draft-ietf-manet-olsrv2-mib-11.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2013 02:33:04 -0000

Hello, Working Group -=20

The OSLR MIB document has undergone some changes during the IESG review pro=
cess. In order to give the WG a chance to review and comment, we are reques=
ting your attention to the doc during a 7-day "Sanity Check" period. This 7=
-day window will end at 2300 EDT on June 19. So please give the doc a look,=
 and comment as you feel appropriate.=20

Regards,
Stan


On Jun 12, 2013, at 9:45 PM, <internet-drafts@ietf.org>
 <internet-drafts@ietf.org> wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> 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	 Optimized Link =
State Routing Protocol version 2
> 	Author(s)       : Ulrich Herberg
>                          Robert G. Cole
>                          Thomas Heide Clausen
> 	Filename        : draft-ietf-manet-olsrv2-mib-11.txt
> 	Pages           : 85
> 	Date            : 2013-06-12
>=20
> Abstract:
>   This document defines the Management Information Base (MIB) module
>   for configuring and managing the Optimized Link State Routing
>   protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
>   into configuration information, state information, performance
>   information, and notifications.  This additional state and
>   performance information is useful to troubleshoot problems and
>   performance issues of the routing protocol.  Two levels of compliance
>   allow this MIB module to be deployed on constrained routers.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-11
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mib-11
>=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


From randy_presuhn@mindspring.com  Wed Jun 12 22:52:54 2013
Return-Path: <randy_presuhn@mindspring.com>
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 9CF3B21F99BD; Wed, 12 Jun 2013 22:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.866
X-Spam-Level: 
X-Spam-Status: No, score=-101.866 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU4DbhuB7M8a; Wed, 12 Jun 2013 22:52:48 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3E76621F99B9; Wed, 12 Jun 2013 22:52:47 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dfEvfYXGtP/Ulfdl74Hj4i36s9AivhnyC/5iqFlzp1RHuuahnpAzG1C6TDkGZnKK; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1Un0Sk-0006Bi-Hm; Thu, 13 Jun 2013 01:52:46 -0400
Received: from 76.254.49.35 by webmail.earthlink.net with HTTP; Thu, 13 Jun 2013 01:52:46 -0400
Message-ID: <26771980.1371102766523.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
Date: Wed, 12 Jun 2013 22:52:46 -0700 (GMT-07:00)
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: mib-doctors@ietf.org, draft-ietf-manet-olsrv2-mib.all@tools.ietf.org,  manet@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f08c3bff2f2b658935c9d8718a8b6dad758350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.34
X-Mailman-Approved-At: Wed, 12 Jun 2013 23:20:18 -0700
Subject: [manet] MIB doctor "skim" of draft-ietf-manet-olsrv2-mib-11.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Randy Presuhn <randy_presuhn@mindspring.com>
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2013 05:52:54 -0000

Hi -

In reponse to my earlier comments, the editors of the OLSRv2
MIB module issued an updated I-D, which I understand has been
sent to the manet WG for a sanity check.  In order speed things
along, I did a quick skim of the document this evening.

These comments are in my opinion very minor, with the exception
of RMP-313, but I would appreciate comments from other MIB doctors
on the two "***" items below.  (As well as anything else if you
think I've missed the boat.)

RMP-301
top of page 4: "OLSRV2" should be "OLSRv2"

RMP-302
top of page 4: "intervals etc." -> "intervals, etc."

RMP-303
6.3: needs to mention IANAolsrv2LinkMetricType-MIB in
the list.

RMP-304
Olsrv2MetricValueCompressedFormTC: I'm surprised that
the display-hint is "x" rather than "d".  I hope the
WG discussed this - I'm ok with whatever, as long as
it's a conscious decision and not an oversight.

RMP-305
Olsrv2MetricValueCompressedFormTC: I'm also a little
surprised that the DESCRIPTION talks about set processing,
since it looks to me as though all uses of this TC are
for read-only objects.

RMP-306
Olsrv2MetricValueCompressedFormTC: has the WG discussed
what a management system should do if an implementation
reponds to a get/getnext/getbulk request for an object
of this type with a syntactically legal but mathematically
impossible value, such as 16776959?

RMP-307
olsrv2InterfaceTable: "This object is set either by
network management, or by other means, e.g., CLI."
Is the EXCLUSIVE-OR intentional?  If not, should
delete the "either".

RMP-308
Something I overlooked on previous passes:
olsrv2RxHoldTime, olsrv2PHoldTime, olsrv2FHoldTime,
olsrv2TpMaxJitter, olsrv2TtMaxJitter, olsrv2FMaxJitter:
are the maximum values for these *really* more than
49 days? 

*** RMP-309
olsrv2LinkMetricType: the DEFVAL should probably say
	{ unknown(0) } - I don't know whether all
	MIB compilers out there nowadays are smart
	enough to figure out { unknown } by itself.
	They *should* be able to, but this might be
	a case where conservatism is warranted.

RMP-310
olsrv2TibAdRemoteRouterSetMaxSeqNo and
olsrv2TibAttNetworksSetSeqNo: I seem to recall from
another document that the notion of "greatest" for this
bit of information isn't the same as in math.  If that
is so, it should be spelled out here, as has already been done
in the description for olsrv2TibAdRemoteRouterSetMaxSeqNo.

*** RMP-311
All items with SYNTAX TimeStamp - some might argue whether
UNITS clauses are appropriate for these.  I'm equivocal on
the point.

RMP-312
You might consider whether you'd like to put DEFVAL clauses
on the read-write items in olsrv2NotificationsControl.
DEFVALs are merely advisory - implementations are NOT obligated
to follow them (RFC 2578 clause 7.9).

RMP-313
Section 10: needs to add instructions for the registration
and spin-off of the MIB module with the metric textual convention.
(Those instructions currently are in the first paragraph
of Appendix A.  It's ok by me if thery're repeated there, but
I think it's crucial that IANA's instructions in section 10 are
complete.)

Randy

From iesg-secretary@ietf.org  Thu Jun 13 13:28:30 2013
Return-Path: <iesg-secretary@ietf.org>
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 1B1BC21F9AAC; Thu, 13 Jun 2013 13:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.53
X-Spam-Level: 
X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1u9kstflzAWB; Thu, 13 Jun 2013 13:28:29 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B5A21F9A93; Thu, 13 Jun 2013 13:28:29 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Sender: <iesg-secretary@ietf.org>
Message-ID: <20130613202829.25693.37707.idtracker@ietfa.amsl.com>
Date: Thu, 13 Jun 2013 13:28:29 -0700
Cc: manet@ietf.org
Subject: [manet] Last Call: <draft-ietf-manet-rfc6622-bis-02.txt> (Integrity Check	Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks	(MANETs)) to Proposed Standard
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2013 20:28:30 -0000

The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc
   Networks (MANETs)'
  <draft-ietf-manet-rfc6622-bis-02.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-06-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document revises, extends and replaces RFC 6622.  It describes
   general and flexible TLVs for representing cryptographic Integrity
   Check Values (ICVs) and timestamps, using the generalized Mobile Ad
   Hoc Network (MANET) packet/message format defined in RFC 5444.  It
   defines two Packet TLVs, two Message TLVs, and two Address Block TLVs
   for affixing ICVs and timestamps to a packet, a message, and one or
   more addresses, respectively.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis/ballot/


No IPR declarations have been submitted directly on this I-D.

From charliep@computer.org  Thu Jun 13 13:37:00 2013
Return-Path: <charliep@computer.org>
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 B97B821F9A45 for <manet@ietfa.amsl.com>; Thu, 13 Jun 2013 13:37:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqaimO6Mcr3R for <manet@ietfa.amsl.com>; Thu, 13 Jun 2013 13:36:55 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id E096921F9ABD for <manet@ietf.org>; Thu, 13 Jun 2013 13:36:54 -0700 (PDT)
Received: from [107.1.141.74] (helo=[192.168.255.219]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1UnEGL-0003u9-L6; Thu, 13 Jun 2013 16:36:53 -0400
Message-ID: <51BA2D59.3060609@computer.org>
Date: Thu, 13 Jun 2013 13:36:41 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: manet@ietf.org
References: <061.9fd5709d256b2f4a875556dafc06bb3b@trac.tools.ietf.org>
In-Reply-To: <061.9fd5709d256b2f4a875556dafc06bb3b@trac.tools.ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867e7ed8fd447761758dabc123ac564e59350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 107.1.141.74
Cc: manet issue tracker <trac+manet@trac.tools.ietf.org>
Subject: Re: [manet] #4: Change to handling of Route.Dist for AdditionalNode routing information
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2013 20:37:00 -0000

Hello folks,

This change has been superceded in the specification without noticeable
loss of function or any disagreement.  It does not seem to have any bad
interaction with the way the specification deals with alternative metrics.

I think the issue can be safely closed, unless there is anyone with more
relevant discussion points.

Regards,
Charlie P.


On 11/2/2012 7:41 PM, manet issue tracker wrote:
> #4: Change to handling of Route.Dist for AdditionalNode routing information
>
>   Normal RREQ + RREP processing for route information always requires
>   inclusion of a valid Route.Dist (i.e., Hop Count [as of the current
>   revision]).  Optionally, routing information related to "Additional Nodes"
>   can be included for nodes that are not themselves AODVv2 routers.  For
>   such nodes, provision has been made to include relevant information (e.g.,
>   next hop) without requiring a valid Route.Dist for the additional node.
>   However, this makes some of the specification more difficult to
>   understand.  The same effect can be achieved by assigning a large value
>   for Route.Dist, so that any measured hop count will have the proper effect
>   of updating the route table entry.  Such a parameter is available now,
>   namely MAX_HOPCOUNT.  This only affects the optional inclusion of routing
>   information about Additional Nodes.
>


-- 
Regards,
Charlie P.


From chris.dearlove@baesystems.com  Fri Jun 14 01:47:15 2013
Return-Path: <chris.dearlove@baesystems.com>
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 CAA3E21F9C02; Fri, 14 Jun 2013 01:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level: 
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnNxWcuykIzb; Fri, 14 Jun 2013 01:47:11 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4459021F9C47; Fri, 14 Jun 2013 01:47:09 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,864,1363132800"; d="scan'208";a="293052597"
Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 14 Jun 2013 09:47:08 +0100
X-IronPort-AV: E=Sophos;i="4.87,864,1363132800"; d="scan'208";a="18914399"
Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 14 Jun 2013 09:47:07 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.180]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0328.009; Fri, 14 Jun 2013 09:47:08 +0100
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: Randy Presuhn <randy_presuhn@mindspring.com>, "mib-doctors@ietf.org" <mib-doctors@ietf.org>, "draft-ietf-manet-olsrv2-mib.all@tools.ietf.org" <draft-ietf-manet-olsrv2-mib.all@tools.ietf.org>, "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [manet] MIB doctor "skim" of draft-ietf-manet-olsrv2-mib-11.txt
Thread-Index: AQHOZ/4Z51uBc2IiGUaWa6mxk0vjMpk05iog
Date: Fri, 14 Jun 2013 08:47:07 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D25090A66@GLKXM0002V.GREENLNK.net>
References: <26771980.1371102766523.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
In-Reply-To: <26771980.1371102766523.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
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"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: Re: [manet] MIB doctor "skim" of draft-ietf-manet-olsrv2-mib-11.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2013 08:47:15 -0000

With regard to the maximum long period for timing information, something ab=
ou the figure you indicate is the maximum value representable using the RFC=
 5497 format.

Is it realistic? I can see a use for a large figure, if running a MANET in =
part over reliable fixed links. But essentially the original format had a 4=
/4 split of bits, and its maximum was deemed too short. 5/3 gave a long fig=
ure, even setting granularity to a binary millisecond.

-- =

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 R=
andy Presuhn
Sent: 13 June 2013 06:53
To: mib-doctors@ietf.org; draft-ietf-manet-olsrv2-mib.all@tools.ietf.org; m=
anet@ietf.org
Subject: [manet] MIB doctor "skim" of draft-ietf-manet-olsrv2-mib-11.txt

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi -

In reponse to my earlier comments, the editors of the OLSRv2
MIB module issued an updated I-D, which I understand has been
sent to the manet WG for a sanity check.  In order speed things
along, I did a quick skim of the document this evening.

These comments are in my opinion very minor, with the exception
of RMP-313, but I would appreciate comments from other MIB doctors
on the two "***" items below.  (As well as anything else if you
think I've missed the boat.)

RMP-301
top of page 4: "OLSRV2" should be "OLSRv2"

RMP-302
top of page 4: "intervals etc." -> "intervals, etc."

RMP-303
6.3: needs to mention IANAolsrv2LinkMetricType-MIB in
the list.

RMP-304
Olsrv2MetricValueCompressedFormTC: I'm surprised that
the display-hint is "x" rather than "d".  I hope the
WG discussed this - I'm ok with whatever, as long as
it's a conscious decision and not an oversight.

RMP-305
Olsrv2MetricValueCompressedFormTC: I'm also a little
surprised that the DESCRIPTION talks about set processing,
since it looks to me as though all uses of this TC are
for read-only objects.

RMP-306
Olsrv2MetricValueCompressedFormTC: has the WG discussed
what a management system should do if an implementation
reponds to a get/getnext/getbulk request for an object
of this type with a syntactically legal but mathematically
impossible value, such as 16776959?

RMP-307
olsrv2InterfaceTable: "This object is set either by
network management, or by other means, e.g., CLI."
Is the EXCLUSIVE-OR intentional?  If not, should
delete the "either".

RMP-308
Something I overlooked on previous passes:
olsrv2RxHoldTime, olsrv2PHoldTime, olsrv2FHoldTime,
olsrv2TpMaxJitter, olsrv2TtMaxJitter, olsrv2FMaxJitter:
are the maximum values for these *really* more than
49 days? =


*** RMP-309
olsrv2LinkMetricType: the DEFVAL should probably say
	{ unknown(0) } - I don't know whether all
	MIB compilers out there nowadays are smart
	enough to figure out { unknown } by itself.
	They *should* be able to, but this might be
	a case where conservatism is warranted.

RMP-310
olsrv2TibAdRemoteRouterSetMaxSeqNo and
olsrv2TibAttNetworksSetSeqNo: I seem to recall from
another document that the notion of "greatest" for this
bit of information isn't the same as in math.  If that
is so, it should be spelled out here, as has already been done
in the description for olsrv2TibAdRemoteRouterSetMaxSeqNo.

*** RMP-311
All items with SYNTAX TimeStamp - some might argue whether
UNITS clauses are appropriate for these.  I'm equivocal on
the point.

RMP-312
You might consider whether you'd like to put DEFVAL clauses
on the read-write items in olsrv2NotificationsControl.
DEFVALs are merely advisory - implementations are NOT obligated
to follow them (RFC 2578 clause 7.9).

RMP-313
Section 10: needs to add instructions for the registration
and spin-off of the MIB module with the metric textual convention.
(Those instructions currently are in the first paragraph
of Appendix A.  It's ok by me if thery're repeated there, but
I think it's crucial that IANA's instructions in section 10 are
complete.)

Randy
_______________________________________________
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 valerio.arnaboldi@iit.cnr.it  Fri Jun 14 08:04:12 2013
Return-Path: <valerio.arnaboldi@iit.cnr.it>
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 2B52021F9CF0 for <manet@ietfa.amsl.com>; Fri, 14 Jun 2013 08:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.614
X-Spam-Level: 
X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd2jVvqm6YqE for <manet@ietfa.amsl.com>; Fri, 14 Jun 2013 08:04:07 -0700 (PDT)
Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) by ietfa.amsl.com (Postfix) with ESMTP id 554C521F9CE1 for <manet@ietf.org>; Fri, 14 Jun 2013 08:04:03 -0700 (PDT)
Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by mxbk.iit.cnr.it (Postfix) with ESMTPA id 61C91C032F for <manet@ietf.org>; Fri, 14 Jun 2013 17:03:50 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Valerio Arnaboldi<valerio.arnaboldi@iit.cnr.it>
To: manet@ietf.org
Message-Id: <20130614150403.554C521F9CE1@ietfa.amsl.com>
Date: Fri, 14 Jun 2013 08:04:03 -0700 (PDT)
Subject: [manet] Call for industrial track papers - SustainIT 2013 (paper registration deadline June 30)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2013 15:04:12 -0000

-------------------------------------------------------------------	
*** Our apologies if you receive multiple copies of this e-mail ***
-------------------------------------------------------------------
	
                    CALL FOR INDUSTRIAL TRACK PAPERS

                     The Third IFIP Conference on
            Sustainable Internet and ICT for Sustainability
                            (SustainIT 2013)

           http://www.dicgim.unipa.it/networks/sustainit2013

                          October 30-31, 2013
                        Palermo, Sicily, Italy

- Technically sponsored by the IFIP TC6 WG 6.3 (Performance of
  Communication Systems)
- Technically co-sponsored by IEEE TCCC
  (Technical Committee on Computer Communications)
- In cooperation with IEEE TSGCC (Technical Subcommittee on Green
  Communications and Computing)
- Supported by EINS: The Network of Excellence in Internet Science

------------------------------------------------------------------------
SCOPE AND OVERVIEW
------------------------------------------------------------------------

SUSTAINIT 2013 will feature an industrial track providing a forum for researchers and developers from academia, industry, and government to interact and share latest research results achieved by national and international projects on the areas of Sustainable Internet and ICT for Sustainability. Towards this goal, SUSTAINIT seeks participations from all three entities. The industrial track offers the opportunity to present the latest findings by ongoing projects or the overview of recently approved projects. Industrial track paper submissions are
welcome in all aspects of Sustainable Internet and ICT for Sustainability, including algorithms, protocols, applications, hardware and tools, new research prototypes, testbeds, etc. Authors are asked to submit a paper of up to 5 pages (including figures, tables, and references) (one additional page is allowed upon a fee payment). The paper should highlight the main contributions and describe the details of the project, with a focus on the interaction with the audience and highlighting the environmental sustainability benefits either achieved or targeted. Please refer to the Submission Instructions below for more details.


IMPORTANT DATES
------------------------------------------------------------------------
- Industrial track paper registration deadline:    June 30, 2013
- Industrial track paper submission deadline:      July 5, 2013
- Acceptance/Reject notification:         	      July 20, 2013
- Camera-ready version due:               	      August 5, 2013


INDUSTRIAL TRACK PAPER SUBMISSION
------------------------------------------------------------------------

Papers must be submitted electronically in PDF format through EDAS (http://edas.info/newPaper.php?c=14317). Manuscripts must be formatted in accordance with the IEEE Computer Society author guidelines (http://edas.info/newPaper.php?c=14317). Industrial track papers must be limited to 5 pages (one additional page is allowed upon a fee payment), single spacing, double column, and must strictly adhere to the template format. Detailed instructions for manuscript preparation and submission are available on the conference website
(http://www.dicgim.unipa.it/networks/sustainit2013/submission.html).

FOR MORE INFORMATION
------------------------------------------------------------------------
For questions about the industrial track paper submission and review process, please contact the SUSTAINIT 2013 Industrial Track Co-Chairs:

Maria Cristina Bueti, International Telecommunication Union (ITU) -
cristina (dot) bueti (at) itu (dot) int
Luca Valcarenghi, Scuola Superiore Sant'Anna, luca (dot) valcarenghi
(at) sssup (dot) it

From randy_presuhn@mindspring.com  Fri Jun 14 11:17:51 2013
Return-Path: <randy_presuhn@mindspring.com>
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 CC1FA21F9A43; Fri, 14 Jun 2013 11:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.199
X-Spam-Level: 
X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXJI87F06Yzj; Fri, 14 Jun 2013 11:17:45 -0700 (PDT)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5694321F9B7F; Fri, 14 Jun 2013 11:17:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SQup08gWAKVN1ODyen10glt7TJbShSAX+1hnIQFDQMp0YeQb+2Ph5j6WbleGRv2I; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1UnYZE-0006ui-6Q; Fri, 14 Jun 2013 14:17:44 -0400
Received: from 99.33.92.75 by webmail.earthlink.net with HTTP; Fri, 14 Jun 2013 14:17:43 -0400
Message-ID: <13815749.1371233863980.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>
Date: Fri, 14 Jun 2013 11:17:43 -0700 (GMT-07:00)
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: "Dearlove,Christopher (UK)" <chris.dearlove@baesystems.com>,  "mib-doctors@ietf.org" <mib-doctors@ietf.org>,  "draft-ietf-manet-olsrv2-mib.all@tools.ietf.org" <draft-ietf-manet-olsrv2-mib.all@tools.ietf.org>,  "manet@ietf.org" <manet@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f086b9f95b9dc33391f89f27a553ae87b50350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.42
X-Mailman-Approved-At: Fri, 14 Jun 2013 11:22:36 -0700
Subject: Re: [manet] MIB doctor "skim" of draft-ietf-manet-olsrv2-mib-11.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Randy Presuhn <randy_presuhn@mindspring.com>
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2013 18:17:51 -0000

Hi -

In response to this comment:
RMP-308
Something I overlooked on previous passes:
olsrv2RxHoldTime, olsrv2PHoldTime, olsrv2FHoldTime,
olsrv2TpMaxJitter, olsrv2TtMaxJitter, olsrv2FMaxJitter:
are the maximum values for these *really* more than
49 days? 

There was this:
>From: "Dearlove, Christopher (UK)" 
>Sent: Jun 14, 2013 1:47 AM
>To: Randy Presuhn , "mib-doctors@ietf.org" , "draft-ietf-manet-olsrv2-mib.all@tools.ietf.org" , "manet@ietf.org" 
>Subject: RE: [manet] MIB doctor "skim" of draft-ietf-manet-olsrv2-mib-11.txt
>
>With regard to the maximum long period for timing information,
> something abou the figure you indicate is the maximum value
> representable using the RFC 5497 format.
>
>Is it realistic? I can see a use for a large figure,
>if running a MANET in part over reliable fixed links.
>But essentially the original format had a 4/4 split of bits,
>and its maximum was deemed too short. 5/3 gave a long figure,
>even setting granularity to a binary millisecond.
...

Using the RFC 5497 section 5 formulas, the maximum value
representable (a = 7, b = 31, c = 1/1,024 {or is it .001?})
comes to 3,932,160 seconds, or about 45 days right?
That's less than the upper bound of the Unsigned32 data
type, so if the architecture truly supports the whole range
of the RFC 5497 representation for these values, then the
SMI data type should be restricted to an upper bound of
3,932,160,000 rather than the 4,294,967,295 that comes
with the Unsigned32 data type. (Of course, someone should
check my math.)

Rationale: it's generally a bad idea to permit a management
interface to configure architecturally impossible settings.

Perhaps this perfectly reasonable given the operational
characteristics of this protocol (I'm ignorant on the topic)
but permitting configuration of (for example) a jitter term
to have a value of more than 6 weeks, particularly given
the recommendations of RFC 5148, doesn't seem to make a
great deal of sense.

Rationale: we have a tradition of giving operators plenty
of rope with which to hang themselves, but this seems
excessive. :-)

Randy

From housley@vigilsec.com  Fri Jun 14 13:23:53 2013
Return-Path: <housley@vigilsec.com>
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 132D521F9CC3; Fri, 14 Jun 2013 13:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.511
X-Spam-Level: 
X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfgaREJGLlGQ; Fri, 14 Jun 2013 13:23:48 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id E8E5A21F9B82; Fri, 14 Jun 2013 13:23:47 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 8BB39F2407D; Fri, 14 Jun 2013 16:23:51 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id o1kzzxD7pdlj; Fri, 14 Jun 2013 16:23:44 -0400 (EDT)
Received: from [192.168.2.109] (pool-96-241-156-29.washdc.fios.verizon.net [96.241.156.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BC3DFF24078; Fri, 14 Jun 2013 16:23:50 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri, 14 Jun 2013 16:23:45 -0400
Message-Id: <90D2B755-F68F-4C58-A645-84E4445C73BE@vigilsec.com>
To: IETF <ietf@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Cc: IETF Gen-ART <gen-art@ietf.org>, manet@ietf.org
Subject: [manet] Gen-ART Review of draft-ietf-manet-rfc6622-bis-02
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2013 20:23:53 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-manet-rfc6622-bis-02
Reviewer: Russ Housley
Review Date: 2013-06-15
IETF LC End Date: 2013-06-27
IESG Telechat date: Unknown

Summary:  The document is almost ready for publication as a
standards track RFC.  I raise one major concern, and once it
is resolved, the document will be ready.

Major Concern:

In Section 12.2.3, is there any difference in processing when the
source IP address is IPv4 as opposed to IPv6?  Obviously, the two have
a different length.  Off the top of my head I cannot find a way for an
attacker to exploit one party using IPv4 in the ICV calculation and the
other party using IPv6.  Since the IPv6 address is 12 octets longer
than the IPv4 address, there may be some opportunity for an attacker.
Anyway, concerns like this are usually thwarted by including the length
of the overall hash function input as the first octet or two of the
value-to-be-hashed.  Such a value does not need to be transmitted.
Each party knows how many octets it passed to the hash function.


Minor Concerns:  

I find Section 1.1 a bit confusing.  I think it should start by saying
that RFC 6622 defined two ICV TLV extension types (0 and 1).  This
document repeats those definitions and adds a third ICV TLV extension
type (2).


Section 5 says:

  An ICV TLV with type extension = 2 specifies a modified version of
  this definition.
 
This is unclear.  I believe that an ICV TLV with type extension = 2 is
an update to ICV TLV with type extension = 1.  It would be good to
introduce the need for this update.  I suggest:

  An ICV TLV with type extension = 2 is the same as an ICV TLV with
  type extension = 1, except that the integrity protection also covers
  the source address of the IP datagram carrying the packet, message,
  or address block.

If you accept this suggestion, the following paragraph should also be
revised.  I suggest:

  Specifically, with type extension = 1 or type extension = 2, the
  <value> field contains the result of combining a cryptographic
  function and a hash function.  The <value> field contains multiple
  sub-fields indicating which hash function and cryptographic function
  have been used as specified in Section 12.


From adrian@olddog.co.uk  Sun Jun 16 15:41:53 2013
Return-Path: <adrian@olddog.co.uk>
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 B233821F9CEC for <manet@ietfa.amsl.com>; Sun, 16 Jun 2013 15:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Level: 
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0SgFLE40Xkn for <manet@ietfa.amsl.com>; Sun, 16 Jun 2013 15:41:47 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 6619E21F9AE8 for <manet@ietf.org>; Sun, 16 Jun 2013 15:41:43 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5GMffpv022720;  Sun, 16 Jun 2013 23:41:41 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r5GMfeVW022712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Jun 2013 23:41:40 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org>
Date: Sun, 16 Jun 2013 23:41:39 +0100
Message-ID: <012301ce6ae2$ab3714f0$01a53ed0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac5q4qlf9Zlz5H0HQYivWgQN/5Bivg==
Content-Language: en-gb
Cc: manet@ietf.org
Subject: [manet] AD review of draft-ietf-manet-nhdp-olsrv2-sec
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Jun 2013 22:41:53 -0000

Hi Authors, 

Thanks for this small but important addition to NHDP and OLSRv2. I
found the document pretty clear and have only one technical issue with
it.  The bunch of editorial comments below can be taken under 
advisement, but I think that fixing them will make the document more
readable and will ease its passage through the next stages.

If you can turn around a new revision (or tell me that none of my 
suggestions needs to be adopted) then I can kick of the IETF last call.

Thanks for the work,
Adrian

---

Technical issue...

I understand that this document specifies mandatory rules for NHDP (and
OLSRv2) and your use of "updates" is correct.  However, there are 
obviously existing implementations of NHDP that are deployed.

I am searching for the backward compatibility description. An existing
implementation of NHDP may now receive messages containing the ICV or
timestamp TLVs.  But these will not be used by the legacy implementation
because they are unknown TLVs.  

How will they be processed by the legacy implementation? I think this
needs just a single statement and a pointer to the correct rule in 6130.

How will the way that a legacy implementation behaves change the 
perception of security that the sender has?  This obviously depends on 
the answer to the previous question, and can hopefully be stated very
briefly.

---

I think that this document will also update [OLSRv2] when it is
published as an RFC (even if that is simultaneous). Therefore, I 
recommend to top the document with...

[RFC Editor note: Please replace "xxxx" throughout this document with
the RFC number assigned to [OLSRv2], and remove this note.]

Noting that the citation will be fixed by the RFC Editor in any case.

---

The line in the document header should read 
"Updates: 6130, xxxx (if approved)"

---

The Abstract should mention
"This document updates RFC 6130 and RFC xxxx."

Additionally, I found the Abstract quite dense. Can I suggest some
re-wording.

OLD
   This document specifies integrity and replay protection for required
   implementation in the MANET Neighborhood Discovery Protocol (NHDP)
   and the Optimized Link State Routing Protocol version 2 (OLSRv2).
   This document specifies how an included integrity check value (ICV)
   and a timestamp TLV, defined in RFC6622bis, are used by NHDP and
   OLSRv2 for countering a number of security threats.  The ICV TLV uses
   a SHA-256 based HMAC and one or more shared secret keys.  The
   timestamp TLV is based on POSIX time, and assumes that the clocks in
   all routers in the network can be synchronized with sufficient
   precision.  The mechanism in this specification can also be used for
   other MANET protocols using RFC5444.
NEW
   This document specifies integrity and replay protection for the MANET
   Neighborhood Discovery Protocol (NHDP) and the Optimized Link State 
   Routing Protocol version 2 (OLSRv2).  This protection is achieved by
   using the Integrity Check value (ICV) and the Timestamp TLV.
   
   The mechanism in this specification can also be used for protocols
   that use the generalized packet/message format described in RFC 5444.

   This document updates RFC 6130 and RFC xxxx by mandating the
   implementation of integrity and replay protection in NHDP and OLSRv2.
END

---

The Introduction should also say something like:

   This document updates [RFC6130] and [OLSRv2] by mandating the 
   implementation of integrity and replay protection in NHDP and OLSRv2.

---

In the Introduction, I had to read the following paragraph several times
and look at the figure in order to work out what you meant. At that point
it was obvious, but can I suggest re-wording:

OLD
   The mechanism specified in this document exists between NHDP's and
   OLSRv2's message processing/generation and the [RFC5444] packet
   parsing/generation, as illustrated in Figure 1.
NEW
   The mechanism specified in this document is placed in the packet-
   processing flow as indicated in Figure 1.  It exists between the
   packet parsing/generation function of [RFC5444], and the message
   processing/generation function of NHDP and OSLRv2.
END

---

Section 3

I found the following hard:
   o  Specifies an association of ICVs with messages, and for using
      missing or invalid ICVs as such an additional reason for rejecting
      a message as "badly formed and therefore invalid for processing".

How about:
   o  Specifies an association of ICVs with protocol messages, and
      specifies how to use a missing or invalid ICV as an reason to 
      reject a message as "badly formed and therefore invalid for 
      processing".

---

Section 3

   o  Specifies the implementation of an ICV Message TLV, defined in
      [RFC6622bis], using a SHA-256 based HMAC applied to the
      appropriate message contents (and for HELLO messages also
      including the IP datagram source address).  Deployments of
      [RFC6130] and [OLSRv2] using this framework should use an HMAC/
      SHA-256 ICV TLV, but may use different algorithms if more
      appropriate in a deployment.  An implementation may also use more
      than one ICV TLV in a message, as long as they each use a
      different algorithm to calculate the ICV.

There is a "should" and two "may"s in this text. Given the use of 2119
language higher up the section and in the next bullet, I wondered 
whether you wanted this in 2119-speak as well.

---

I think the RFC Editor would ask you for help determining the 
consistency of case in "timestamp TLV" and "TIMESTAMP TLV".  Can you
check you are happy with what you have.

---

The last sentence of Section 4 says:

   This framework specifies that a
   message MUST be rejected if the ICV Message TLV is absent, or its
   value cannot be verified.

This is equivalent to saying that a sender MUST include an ICV Message
TLV in every message it sends. Initially, it seemed to me that this 
contradicted the statements about optional use in deployments: e.g.
(from the introduction),
  
   A deployment may choose
   to use no such security mechanisms, but this is not recommended.


So I think that what you are saying is actually:

   This framework specifies that an implementation conforming to this
   specification and with security enabled, MUST reject a received
   message if the ICV Message TLV is absent, or its value cannot be
   verified.

---

Section 5

When you say "silently discarded" do you intend to preclude raising an
alert or incrementing a count? It seems likely that over-age messages
are indicative of something (like a replay attack, or an echo, or long
delays, or a misconfigured constant) and some log of the fact might be
useful. The usual way to handle this is "An implementation MAY log or
count such events, but SHOULD be careful to avoid logging storms caused
by a replay attack."

---

Section 5

   However it should also be noted that, in
   the ideal case, the parameters SHOULD be significantly less than
   those bounds.

Some smart-arse on the IESG is going to ask what "significantly" means.
Is there any way you can quantify this: e.g., 27.5%

---

Section 7

Should this section also note that routers should be able to be 
configured to use (or not use) the mechanisms described in this 
document, and that implementations should make use of these mechanisms
the default?

---

Section 9.1.2

Will the readership know what is meant by Link Spoofing or should you
give a reference?


From chris.dearlove@baesystems.com  Mon Jun 17 01:53:33 2013
Return-Path: <chris.dearlove@baesystems.com>
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 1CF0B21F9B05; Mon, 17 Jun 2013 01:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m5fJSKCrOl0; Mon, 17 Jun 2013 01:53:20 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 44EED21F935A; Mon, 17 Jun 2013 01:53:20 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,879,1363132800"; d="scan'208";a="293467847"
Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Jun 2013 09:53:18 +0100
X-IronPort-AV: E=Sophos;i="4.87,879,1363132800"; d="scan'208";a="19096107"
Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 17 Jun 2013 09:53:17 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.180]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 09:53:17 +0100
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: Randy Presuhn <randy_presuhn@mindspring.com>, "mib-doctors@ietf.org" <mib-doctors@ietf.org>, "draft-ietf-manet-olsrv2-mib.all@tools.ietf.org" <draft-ietf-manet-olsrv2-mib.all@tools.ietf.org>, "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [manet] MIB doctor "skim" of draft-ietf-manet-olsrv2-mib-11.txt
Thread-Index: AQHOaSt251uBc2IiGUaWa6mxk0vjMpk5nQAg
Date: Mon, 17 Jun 2013 08:53:17 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D25090E6D@GLKXM0002V.GREENLNK.net>
References: <13815749.1371233863980.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>
In-Reply-To: <13815749.1371233863980.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net>
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="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Subject: Re: [manet] MIB doctor "skim" of draft-ietf-manet-olsrv2-mib-11.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2013 08:53:33 -0000

T0ssIGlmIHlvdSBhcmUgZGlzY3Vzc2luZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIDQ1IGFuZCA0
OSBkYXlzLCBhbmQgd2hldGhlciBhbGwgdmFyaWFibGVzIG5lZWQgdGhhdCByYW5nZSwgSSdsbCBs
ZWF2ZSB0aGF0IHRvIHRoZSBkb2N1bWVudCBhdXRob3JzLg0KDQotLSANCkNocmlzdG9waGVyIERl
YXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBDb21tdW5pY2F0aW9ucyBHcm91cA0K
Q29tbXVuaWNhdGlvbnMsIE5ldHdvcmtzIGFuZCBJbWFnZSBBbmFseXNpcyBDYXBhYmlsaXR5DQpC
QUUgU3lzdGVtcyBBZHZhbmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KV2VzdCBIYW5uaW5nZmllbGQg
Um9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KVGVsOiArNDQgMTI0
NSAyNDIxOTTCoHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQpjaHJpcy5kZWFybG92ZUBiYWVzeXN0
ZW1zLmNvbSB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20NCg0KQkFFIFN5c3RlbXMgKE9wZXJh
dGlvbnMpIExpbWl0ZWQNClJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBCb3gg
ODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywgR1Ux
NCA2WVUsIFVLDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nw0KDQoN
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSYW5keSBQcmVzdWhuIFttYWlsdG86
cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbV0gDQpTZW50OiAxNCBKdW5lIDIwMTMgMTk6MTgN
ClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgbWliLWRvY3RvcnNAaWV0Zi5vcmc7IGRy
YWZ0LWlldGYtbWFuZXQtb2xzcnYyLW1pYi5hbGxAdG9vbHMuaWV0Zi5vcmc7IG1hbmV0QGlldGYu
b3JnDQpTdWJqZWN0OiBSRTogW21hbmV0XSBNSUIgZG9jdG9yICJza2ltIiBvZiBkcmFmdC1pZXRm
LW1hbmV0LW9sc3J2Mi1taWItMTEudHh0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5J
TkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9t
IG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwNCmVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRu
ZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQpLZWVwIHRoaXMgaW4gbWluZCBpZiB5b3UgYW5zd2Vy
IHRoaXMgbWVzc2FnZS4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGlu
ayBvbiBJVCBtYXR0ZXJzDQpmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3Vz
IGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCg0KSGkgLQ0KDQpJbiByZXNwb25zZSB0byB0aGlzIGNvbW1lbnQ6
DQpSTVAtMzA4DQpTb21ldGhpbmcgSSBvdmVybG9va2VkIG9uIHByZXZpb3VzIHBhc3NlczoNCm9s
c3J2MlJ4SG9sZFRpbWUsIG9sc3J2MlBIb2xkVGltZSwgb2xzcnYyRkhvbGRUaW1lLA0Kb2xzcnYy
VHBNYXhKaXR0ZXIsIG9sc3J2MlR0TWF4Sml0dGVyLCBvbHNydjJGTWF4Sml0dGVyOg0KYXJlIHRo
ZSBtYXhpbXVtIHZhbHVlcyBmb3IgdGhlc2UgKnJlYWxseSogbW9yZSB0aGFuDQo0OSBkYXlzPyAN
Cg0KVGhlcmUgd2FzIHRoaXM6DQo+RnJvbTogIkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIiAN
Cj5TZW50OiBKdW4gMTQsIDIwMTMgMTo0NyBBTQ0KPlRvOiBSYW5keSBQcmVzdWhuICwgIm1pYi1k
b2N0b3JzQGlldGYub3JnIiAsICJkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1taWIuYWxsQHRvb2xz
LmlldGYub3JnIiAsICJtYW5ldEBpZXRmLm9yZyIgDQo+U3ViamVjdDogUkU6IFttYW5ldF0gTUlC
IGRvY3RvciAic2tpbSIgb2YgZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbWliLTExLnR4dA0KPg0K
PldpdGggcmVnYXJkIHRvIHRoZSBtYXhpbXVtIGxvbmcgcGVyaW9kIGZvciB0aW1pbmcgaW5mb3Jt
YXRpb24sDQo+IHNvbWV0aGluZyBhYm91IHRoZSBmaWd1cmUgeW91IGluZGljYXRlIGlzIHRoZSBt
YXhpbXVtIHZhbHVlDQo+IHJlcHJlc2VudGFibGUgdXNpbmcgdGhlIFJGQyA1NDk3IGZvcm1hdC4N
Cj4NCj5JcyBpdCByZWFsaXN0aWM/IEkgY2FuIHNlZSBhIHVzZSBmb3IgYSBsYXJnZSBmaWd1cmUs
DQo+aWYgcnVubmluZyBhIE1BTkVUIGluIHBhcnQgb3ZlciByZWxpYWJsZSBmaXhlZCBsaW5rcy4N
Cj5CdXQgZXNzZW50aWFsbHkgdGhlIG9yaWdpbmFsIGZvcm1hdCBoYWQgYSA0LzQgc3BsaXQgb2Yg
Yml0cywNCj5hbmQgaXRzIG1heGltdW0gd2FzIGRlZW1lZCB0b28gc2hvcnQuIDUvMyBnYXZlIGEg
bG9uZyBmaWd1cmUsDQo+ZXZlbiBzZXR0aW5nIGdyYW51bGFyaXR5IHRvIGEgYmluYXJ5IG1pbGxp
c2Vjb25kLg0KLi4uDQoNClVzaW5nIHRoZSBSRkMgNTQ5NyBzZWN0aW9uIDUgZm9ybXVsYXMsIHRo
ZSBtYXhpbXVtIHZhbHVlDQpyZXByZXNlbnRhYmxlIChhID0gNywgYiA9IDMxLCBjID0gMS8xLDAy
NCB7b3IgaXMgaXQgLjAwMT99KQ0KY29tZXMgdG8gMyw5MzIsMTYwIHNlY29uZHMsIG9yIGFib3V0
IDQ1IGRheXMgcmlnaHQ/DQpUaGF0J3MgbGVzcyB0aGFuIHRoZSB1cHBlciBib3VuZCBvZiB0aGUg
VW5zaWduZWQzMiBkYXRhDQp0eXBlLCBzbyBpZiB0aGUgYXJjaGl0ZWN0dXJlIHRydWx5IHN1cHBv
cnRzIHRoZSB3aG9sZSByYW5nZQ0Kb2YgdGhlIFJGQyA1NDk3IHJlcHJlc2VudGF0aW9uIGZvciB0
aGVzZSB2YWx1ZXMsIHRoZW4gdGhlDQpTTUkgZGF0YSB0eXBlIHNob3VsZCBiZSByZXN0cmljdGVk
IHRvIGFuIHVwcGVyIGJvdW5kIG9mDQozLDkzMiwxNjAsMDAwIHJhdGhlciB0aGFuIHRoZSA0LDI5
NCw5NjcsMjk1IHRoYXQgY29tZXMNCndpdGggdGhlIFVuc2lnbmVkMzIgZGF0YSB0eXBlLiAoT2Yg
Y291cnNlLCBzb21lb25lIHNob3VsZA0KY2hlY2sgbXkgbWF0aC4pDQoNClJhdGlvbmFsZTogaXQn
cyBnZW5lcmFsbHkgYSBiYWQgaWRlYSB0byBwZXJtaXQgYSBtYW5hZ2VtZW50DQppbnRlcmZhY2Ug
dG8gY29uZmlndXJlIGFyY2hpdGVjdHVyYWxseSBpbXBvc3NpYmxlIHNldHRpbmdzLg0KDQpQZXJo
YXBzIHRoaXMgcGVyZmVjdGx5IHJlYXNvbmFibGUgZ2l2ZW4gdGhlIG9wZXJhdGlvbmFsDQpjaGFy
YWN0ZXJpc3RpY3Mgb2YgdGhpcyBwcm90b2NvbCAoSSdtIGlnbm9yYW50IG9uIHRoZSB0b3BpYykN
CmJ1dCBwZXJtaXR0aW5nIGNvbmZpZ3VyYXRpb24gb2YgKGZvciBleGFtcGxlKSBhIGppdHRlciB0
ZXJtDQp0byBoYXZlIGEgdmFsdWUgb2YgbW9yZSB0aGFuIDYgd2Vla3MsIHBhcnRpY3VsYXJseSBn
aXZlbg0KdGhlIHJlY29tbWVuZGF0aW9ucyBvZiBSRkMgNTE0OCwgZG9lc24ndCBzZWVtIHRvIG1h
a2UgYQ0KZ3JlYXQgZGVhbCBvZiBzZW5zZS4NCg0KUmF0aW9uYWxlOiB3ZSBoYXZlIGEgdHJhZGl0
aW9uIG9mIGdpdmluZyBvcGVyYXRvcnMgcGxlbnR5DQpvZiByb3BlIHdpdGggd2hpY2ggdG8gaGFu
ZyB0aGVtc2VsdmVzLCBidXQgdGhpcyBzZWVtcw0KZXhjZXNzaXZlLiA6LSkNCg0KUmFuZHkNCioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFs
IHRvIHRoZSBpbnRlbmRlZApyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm
IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZApyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9t
IHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KWW91IHNob3VsZCBub3QgY29weSBp
dCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgpkaXN0cmlidXRlIGl0
cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo=


From henning.rogge@fkie.fraunhofer.de  Mon Jun 17 03:54:51 2013
Return-Path: <henning.rogge@fkie.fraunhofer.de>
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 AB98421F9BEE for <manet@ietfa.amsl.com>; Mon, 17 Jun 2013 03:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek5-QKnagJpK for <manet@ietfa.amsl.com>; Mon, 17 Jun 2013 03:54:21 -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 C56BF21F9BCD for <manet@ietf.org>; Mon, 17 Jun 2013 03:53:48 -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 <henning.rogge@fkie.fraunhofer.de>) id 1UoX4E-0001OK-7A; Mon, 17 Jun 2013 12:53:46 +0200
Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <henning.rogge@fkie.fraunhofer.de>) id 1UoX4E-0002Fl-4V; Mon, 17 Jun 2013 12:53:46 +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, 17 Jun 2013 12:53:45 +0200
Message-ID: <51BEEAB8.9080002@fkie.fraunhofer.de>
Date: Mon, 17 Jun 2013 12:53:44 +0200
From: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: "manet@ietf.org" <manet@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080202050903090405010406"
X-Originating-IP: [128.7.5.36]
X-Virus-Scanned: yes (ClamAV 0.97.8/17366/Mon Jun 17 06:39:26 2013) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: e54ed25f656bf0f020d31b07979cd2b7
Cc: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Subject: [manet] Informal draft about OLSRv2 ETT metric posted
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2013 10:54:58 -0000

--------------ms080202050903090405010406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

a few people asked me in the last months if I would like to revive the=20
OLSR metric draft I worked on in 2009, so Emmanuel Baccelli and me=20
decided to work on a metric draft again.

The new draft is NOT a description of the ETX metric for OLSRv1 as it is =

used in the Freifunk and Funkfeuer networks, it describes the ETT metric =

used in the OLSR.org OLSRv2 implementation (which is based on the=20
experience with the OLSRv1 ETX metric).

While updating the draft to the new metric, I cleaned it up and adapted=20
it to the directional metric approach used in OLSRv2.

We plan to update the draft in two weeks based on the feedback from this =

list. I will also attend the IETF Meeting in Berlin, so I could give a=20
short presentation about the draft there.

You will find the -00 release of the draft at this URL:

http://www.ietf.org/id/draft-rogge-baccelli-olsrv2-ett-metric-00.txt

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


--------------ms080202050903090405010406
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
Fw0xMzA2MTcxMDUzNDRaMCMGCSqGSIb3DQEJBDEWBBTMUgUwWtWuc0qDReU7oza7BbWyKTBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy
MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m
ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y
cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA
uuYwDQYJKoZIhvcNAQEBBQAEggEAkTZlii51rhUNcCV0DuGu94xXyHve6Zop+y05DvPejhFi
GqZ4+kxBYhUmBRklaDLybqxy5WJYLYJ+FjFhfQKB1LdJtZvvcUIU7NY5CrOX+7N5XMcu4bKd
c3kpjogGwBH0ShTw6tgbfajmtzRnhRWLhxjX7i1hzJ3QCbhQ7wSY+Xj4/A0WKUZ8mcIH6tY6
KIJddGa+BFXUyad9ITI/BFY51kEkaSdriaD9DPhI45QkQwwQuOrUHPyLvV+Vxc/S3ILxPncQ
zvzNY7a8UJuLKmcHyUoygIkuYGWLajdkD2kJ6KtjSilVqgc5hSUz5nZflfe7NxnyUdk68s7j
H1uVLHRCaQAAAAAAAA==
--------------ms080202050903090405010406--

From chris.dearlove@baesystems.com  Mon Jun 17 05:42:29 2013
Return-Path: <chris.dearlove@baesystems.com>
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 A338421F9B19 for <manet@ietfa.amsl.com>; Mon, 17 Jun 2013 05:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.397
X-Spam-Level: 
X-Spam-Status: No, score=-9.397 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moKUVXXOwxQN for <manet@ietfa.amsl.com>; Mon, 17 Jun 2013 05:42:19 -0700 (PDT)
Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7B65521F8CB4 for <manet@ietf.org>; Mon, 17 Jun 2013 05:42:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,880,1363132800"; d="scan'208";a="347219135"
Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 17 Jun 2013 13:42:17 +0100
X-IronPort-AV: E=Sophos;i="4.87,880,1363132800"; d="scan'208";a="19174835"
Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 17 Jun 2013 13:42:11 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.180]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 13:42:11 +0100
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org" <draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org>
Thread-Topic: AD review of draft-ietf-manet-nhdp-olsrv2-sec
Thread-Index: Ac5q4qlf9Zlz5H0HQYivWgQN/5BivgAcOzsg
Date: Mon, 17 Jun 2013 12:42:10 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D25090F20@GLKXM0002V.GREENLNK.net>
References: <012301ce6ae2$ab3714f0$01a53ed0$@olddog.co.uk>
In-Reply-To: <012301ce6ae2$ab3714f0$01a53ed0$@olddog.co.uk>
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"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Cc: "manet@ietf.org" <manet@ietf.org>
Subject: Re: [manet] AD review of draft-ietf-manet-nhdp-olsrv2-sec
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2013 12:42:29 -0000

Some personal comments marked by >>> below.

-- =

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: Adrian Farrel [mailto:adrian@olddog.co.uk] =

Sent: 16 June 2013 23:42
To: draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org
Cc: manet@ietf.org
Subject: AD review of draft-ietf-manet-nhdp-olsrv2-sec

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hi Authors, =


Thanks for this small but important addition to NHDP and OLSRv2. I
found the document pretty clear and have only one technical issue with
it.  The bunch of editorial comments below can be taken under =

advisement, but I think that fixing them will make the document more
readable and will ease its passage through the next stages.

If you can turn around a new revision (or tell me that none of my =

suggestions needs to be adopted) then I can kick of the IETF last call.

Thanks for the work,
Adrian

---

Technical issue...

I understand that this document specifies mandatory rules for NHDP (and
OLSRv2) and your use of "updates" is correct.  However, there are =

obviously existing implementations of NHDP that are deployed.

I am searching for the backward compatibility description. An existing
implementation of NHDP may now receive messages containing the ICV or
timestamp TLVs.  But these will not be used by the legacy implementation
because they are unknown TLVs.  =


How will they be processed by the legacy implementation? I think this
needs just a single statement and a pointer to the correct rule in 6130.

>>> The legacy implementation should be straightforward, nothing in NHDP di=
scusses other TLVs. In fact that's the whole point of the TLV design, if yo=
u don't understand it, ignore it. I think this may already be said (there i=
s a discussion of extensibility) but haven't checked.

>>> There is one nit, that there is permission to refuse messages "for any =
other reason". That can always be abused if you want to create an implement=
ation that is technically compliant, but useless. Failing because you have =
received a TLV you don't understand would be such a case. (Failing because =
you receive an expected TLV with an unexpected value is a subtlety that the=
 authors are actually discussing, but is not relevant here.)

How will the way that a legacy implementation behaves change the =

perception of security that the sender has?  This obviously depends on =

the answer to the previous question, and can hopefully be stated very
briefly.

>>> This is actually a bit of a red herring, in that such implementations a=
re irrelevant, they can do what they like, communicate with each other, be =
friendly or unfriendly, whatever. They are just all ignored. (As far as rou=
ting is concerned. There are issues above and below the network layer, but =
we aren't solving them in a network layer protocol.)

>>> (That these aren't real issues in practice is not to say that a sentenc=
e or two about them wouldn't go amiss. It should make the sentence or two e=
asy. Usually the hard thing is to work out where best to put them.)

---

I think that this document will also update [OLSRv2] when it is
published as an RFC (even if that is simultaneous). Therefore, I =

recommend to top the document with...

[RFC Editor note: Please replace "xxxx" throughout this document with
the RFC number assigned to [OLSRv2], and remove this note.]

Noting that the citation will be fixed by the RFC Editor in any case.

---

The line in the document header should read =

"Updates: 6130, xxxx (if approved)"

---

The Abstract should mention
"This document updates RFC 6130 and RFC xxxx."

>>> All the above good points. We've always discussed it in those terms, ju=
st failed to follow through.

Additionally, I found the Abstract quite dense. Can I suggest some
re-wording.

OLD
   This document specifies integrity and replay protection for required
   implementation in the MANET Neighborhood Discovery Protocol (NHDP)
   and the Optimized Link State Routing Protocol version 2 (OLSRv2).
   This document specifies how an included integrity check value (ICV)
   and a timestamp TLV, defined in RFC6622bis, are used by NHDP and
   OLSRv2 for countering a number of security threats.  The ICV TLV uses
   a SHA-256 based HMAC and one or more shared secret keys.  The
   timestamp TLV is based on POSIX time, and assumes that the clocks in
   all routers in the network can be synchronized with sufficient
   precision.  The mechanism in this specification can also be used for
   other MANET protocols using RFC5444.
NEW
   This document specifies integrity and replay protection for the MANET
   Neighborhood Discovery Protocol (NHDP) and the Optimized Link State =

   Routing Protocol version 2 (OLSRv2).  This protection is achieved by
   using the Integrity Check value (ICV) and the Timestamp TLV.

>>> I don't like the last line's use of the definite article and TLV in one=
 case but not the other. So some massaging needed.
   =

   The mechanism in this specification can also be used for protocols
   that use the generalized packet/message format described in RFC 5444.

>>> Protocols wants an "other" before it.

   This document updates RFC 6130 and RFC xxxx by mandating the
   implementation of integrity and replay protection in NHDP and OLSRv2.
END

I think this has thrown away what may be to some the key information of HMA=
C-SHA256 and POSIX timestamp, those being options for those TLVs. So while =
I agree with the separation of the statements about status, I think we may =
want to put something back.

---

The Introduction should also say something like:

   This document updates [RFC6130] and [OLSRv2] by mandating the =

   implementation of integrity and replay protection in NHDP and OLSRv2.

>>> Goes with earlier.

---

In the Introduction, I had to read the following paragraph several times
and look at the figure in order to work out what you meant. At that point
it was obvious, but can I suggest re-wording:

OLD
   The mechanism specified in this document exists between NHDP's and
   OLSRv2's message processing/generation and the [RFC5444] packet
   parsing/generation, as illustrated in Figure 1.
NEW
   The mechanism specified in this document is placed in the packet-
   processing flow as indicated in Figure 1.

>>> Not quite. It's the packet/message processing flow, in particular at th=
e point where inserted, it's the message processing flow (but is packet els=
ewhere).

 It exists between the
   packet parsing/generation function of [RFC5444], and the message
   processing/generation function of NHDP and OSLRv2.
END

---

Section 3

I found the following hard:
   o  Specifies an association of ICVs with messages, and for using
      missing or invalid ICVs as such an additional reason for rejecting
      a message as "badly formed and therefore invalid for processing".

How about:
   o  Specifies an association of ICVs with protocol messages, and
      specifies how to use a missing or invalid ICV as an reason to =

      reject a message as "badly formed and therefore invalid for =

      processing".

>>> I can live with that.

---

Section 3

   o  Specifies the implementation of an ICV Message TLV, defined in
      [RFC6622bis], using a SHA-256 based HMAC applied to the
      appropriate message contents (and for HELLO messages also
      including the IP datagram source address).  Deployments of
      [RFC6130] and [OLSRv2] using this framework should use an HMAC/
      SHA-256 ICV TLV, but may use different algorithms if more
      appropriate in a deployment.  An implementation may also use more
      than one ICV TLV in a message, as long as they each use a
      different algorithm to calculate the ICV.

There is a "should" and two "may"s in this text. Given the use of 2119
language higher up the section and in the next bullet, I wondered =

whether you wanted this in 2119-speak as well.

>>> I'm not going to work out a definite answer here, except to agree that =
within this section we should be consistent. We usually use SHOULD etc. in =
normative parts (and non-normative appendices on the understanding that if =
you adopt them, then they kick in) but should etc. in early descriptive par=
ts (like sections 1 and 4). Section 3 hovers on borderline, I'm not sure wh=
uich way we usually go with it, but should be consistent.

---

I think the RFC Editor would ask you for help determining the =

consistency of case in "timestamp TLV" and "TIMESTAMP TLV".  Can you
check you are happy with what you have.

>>> We can do that. We've usually tried, but sometimes edits may be made af=
ter last time you (we) remembered to check, so I can't at this moment guara=
ntee all is correct, but it can be checked.

---

The last sentence of Section 4 says:

   This framework specifies that a
   message MUST be rejected if the ICV Message TLV is absent, or its
   value cannot be verified.

This is equivalent to saying that a sender MUST include an ICV Message
TLV in every message it sends. Initially, it seemed to me that this =

contradicted the statements about optional use in deployments: e.g.
(from the introduction),
  =

   A deployment may choose
   to use no such security mechanisms, but this is not recommended.


So I think that what you are saying is actually:

   This framework specifies that an implementation conforming to this
   specification and with security enabled, MUST reject a received
   message if the ICV Message TLV is absent, or its value cannot be
   verified.

>>> My view (and whether the text reflects that is a question) is that we h=
ave a framework. The rules say you MUST implement it, but then MAY use it. =
IF you use THEN there are various MUST/SHOULD/MAY rules. If you don't use t=
hen none of them apply.

---

Section 5

When you say "silently discarded" do you intend to preclude raising an
alert or incrementing a count? It seems likely that over-age messages
are indicative of something (like a replay attack, or an echo, or long
delays, or a misconfigured constant) and some log of the fact might be
useful. The usual way to handle this is "An implementation MAY log or
count such events, but SHOULD be careful to avoid logging storms caused
by a replay attack."

>>> Silently discarded is a term used already in the other specifications, =
so nothing new here. I think it applies within the protocol framework - so =
no update of protocol state, messages sent etc. Outside the protocol (e.g. =
logging) is outside scope, so you can do what you like.

---

Section 5

   However it should also be noted that, in
   the ideal case, the parameters SHOULD be significantly less than
   those bounds.

Some smart-arse on the IESG is going to ask what "significantly" means.
Is there any way you can quantify this: e.g., 27.5%

>>> I think the (obviously humorous) 27.5% illustrates exactly the problem.=
 Yes we've has people ask this before,. but frankly they may be demonstrati=
ng a lack of smarts. There is no hard and fast rule, there is only ever a t=
radeoff, and it's false precision to actually say even " a quarter". Now be=
cause IESG people will do what they will, and one has to accommodate them, =
we have before now fudged a bit to hide this. No be fair, there is one just=
ification for saying e.g. "a quarter", so that people at least are guided i=
n the direction of something not entirely insane (like say a millionth). Ho=
wever at this time I'm not sure what "a quarter" should actually be.

---

Section 7

Should this section also note that routers should be able to be =

configured to use (or not use) the mechanisms described in this =

document, and that implementations should make use of these mechanisms
the default?

>>> Not sure about that. I don't thing default is the answer.  Given that t=
hings won't work with a mixture, we are in the area of administrative confi=
guration. And as we need a key, and there is no default key (a bit of an ox=
ymoron) I don't think saying on by default works. Off by default would work=
, but is dangerous. So I think I'd stick with that default is not relevant,=
 it must be administratively configured.

---

Section 9.1.2

Will the readership know what is meant by Link Spoofing or should you
give a reference?

>>> Actually I think I raised this one, as it's not a term I use. Ulrich ha=
d an answer at the time, so I will defer to him.


********************************************************************
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 chris.dearlove@baesystems.com  Mon Jun 17 05:54:32 2013
Return-Path: <chris.dearlove@baesystems.com>
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 BE52D21F9A83 for <manet@ietfa.amsl.com>; Mon, 17 Jun 2013 05:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.148
X-Spam-Level: 
X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KH0WRaMUE6Ui for <manet@ietfa.amsl.com>; Mon, 17 Jun 2013 05:54:29 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id AC29221F9B4C for <manet@ietf.org>; Mon, 17 Jun 2013 05:54:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,880,1363132800"; d="scan'208";a="293566551"
Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Jun 2013 13:54:28 +0100
X-IronPort-AV: E=Sophos;i="4.87,881,1363132800"; d="scan'208";a="19148224"
Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 17 Jun 2013 13:54:27 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.180]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 13:54:27 +0100
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: Henning Rogge <henning.rogge@fkie.fraunhofer.de>, "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [manet] Informal draft about OLSRv2 ETT metric posted
Thread-Index: AQHOa0lBtpkmpEVm8E+h4aPU1L+oIpk53JBg
Date: Mon, 17 Jun 2013 12:54:27 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D25090F4A@GLKXM0002V.GREENLNK.net>
References: <51BEEAB8.9080002@fkie.fraunhofer.de>
In-Reply-To: <51BEEAB8.9080002@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"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Cc: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Subject: Re: [manet] Informal draft about OLSRv2 ETT metric posted
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2013 12:54:32 -0000

I don't yet know if I can make it to Berlin. But (caveat, not read the draf=
t yet) if I do I'd like to see such a presentation, or sit down and talk ab=
out it. Inclusive or.

-- =

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: 17 June 2013 11:54
To: manet@ietf.org
Cc: Emmanuel Baccelli
Subject: [manet] Informal draft about OLSRv2 ETT metric posted

Hi,

a few people asked me in the last months if I would like to revive the =

OLSR metric draft I worked on in 2009, so Emmanuel Baccelli and me =

decided to work on a metric draft again.

The new draft is NOT a description of the ETX metric for OLSRv1 as it is =

used in the Freifunk and Funkfeuer networks, it describes the ETT metric =

used in the OLSR.org OLSRv2 implementation (which is based on the =

experience with the OLSRv1 ETX metric).

While updating the draft to the new metric, I cleaned it up and adapted =

it to the directional metric approach used in OLSRv2.

We plan to update the draft in two weeks based on the feedback from this =

list. I will also attend the IETF Meeting in Berlin, so I could give a =

short presentation about the draft there.

You will find the -00 release of the draft at this URL:

http://www.ietf.org/id/draft-rogge-baccelli-olsrv2-ett-metric-00.txt

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

********************************************************************
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 internet-drafts@ietf.org  Mon Jun 17 13:07:30 2013
Return-Path: <internet-drafts@ietf.org>
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 61E4921F9BA5; Mon, 17 Jun 2013 13:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.513
X-Spam-Level: 
X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltnaHA4tgaiJ; Mon, 17 Jun 2013 13:07:29 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 606D821F9BA9; Mon, 17 Jun 2013 13:07:28 -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.51.p2
Message-ID: <20130617200728.3933.71933.idtracker@ietfa.amsl.com>
Date: Mon, 17 Jun 2013 13:07:28 -0700
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-nhdp-sec-threats-06.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2013 20:07:30 -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           : Security Threats for NHDP
	Author(s)       : Jiazi Yi
                          Ulrich Herberg
                          Thomas Heide Clausen
	Filename        : draft-ietf-manet-nhdp-sec-threats-06.txt
	Pages           : 20
	Date            : 2013-06-17

Abstract:
   This document analyzes common security threats of the Neighborhood
   Discovery Protocol (NHDP), and describes their potential impacts on
   MANET routing protocols using NHDP.  This document is not intended to
   propose solutions to the threats described.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From yi.jiazi@gmail.com  Mon Jun 17 13:12:37 2013
Return-Path: <yi.jiazi@gmail.com>
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 5BD8421F9D0B for <manet@ietfa.amsl.com>; Mon, 17 Jun 2013 13:12:37 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQKlOIEMZr5o for <manet@ietfa.amsl.com>; Mon, 17 Jun 2013 13:12:36 -0700 (PDT)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 51D2E21F9D13 for <manet@ietf.org>; Mon, 17 Jun 2013 13:12:32 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id u53so2732117wes.37 for <manet@ietf.org>; Mon, 17 Jun 2013 13:12:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=YdMgzmU7QlxlCLTdcga6W6/7OVLewk45ohBfyb20uvI=; b=DhVuvDWF3v3JV6Oif0ssg/EHUtAa9UZ8+0QCngFk4neJWbwfTEH+Q7CyCoYeqQlGKP 1+duNt9xZun/8o94KYNmXGSvs88jdtc9FWqSPqToQ3H2MsBNk9hzU/VmCttr+cATxMFQ d4A4FSkiQkAGDBqBofrVY86nHnuHAeT+HqhzW318YOM+R/SBXgR1AAu8sUdcDPItinuo DEr2y7qok8yR3ImPiL1RopDBz4fsZ47OA8Qnx72HGMKo0/i/rnfNXmoVrG+Y2RrT660J p41dlWgA6TPLUHYbThtj0X/kepcafQTBXfxVFfJwnFQihD3zXl6SWSgQ0PCDq2pftaME m0dw==
X-Received: by 10.194.121.132 with SMTP id lk4mr9043015wjb.25.1371499945540; Mon, 17 Jun 2013 13:12:25 -0700 (PDT)
Received: from jy-mac-pro.home (128-79-35-43.hfc.dyn.abo.bbox.fr. [128.79.35.43]) by mx.google.com with ESMTPSA id ay7sm24476790wib.9.2013.06.17.13.12.23 for <manet@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Jun 2013 13:12:24 -0700 (PDT)
From: Jiazi Yi <yi.jiazi@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 17 Jun 2013 22:12:22 +0200
References: <20130617200728.3933.71345.idtracker@ietfa.amsl.com>
To: "manet@ietf.org List" <manet@ietf.org>
Message-Id: <07474C98-30D1-432D-87AC-49D26C18EACD@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [manet] Fwd: New Version Notification - draft-ietf-manet-nhdp-sec-threats-06.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jun 2013 20:12:37 -0000

Dear all,=20

We have submitted a new revision of the nhdp-sec-threats draft, mainly =
addressing the comments from IESG members.=20

You are welcome to send comments on the next text.=20

cheers

Jiazi

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification - =
draft-ietf-manet-nhdp-sec-threats-06.txt
> Date: June 17, 2013 22:07:28 PM GMT+02:00
> Resent-To: jiazi@jiaziyi.com, t.clausen@computer.org, =
ulrich@herberg.name
> Resent-To: macker@itd.nrl.navy.mil, sratliff@cisco.com,
> To: manet-chairs@tools.ietf.org, =
draft-ietf-manet-nhdp-sec-threats@tools.ietf.org, adrian@olddog.co.uk, =
turners@ieca.com
>=20
>=20
> A new version (-06) has been submitted for =
draft-ietf-manet-nhdp-sec-threats:
> =
http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-06.t=
xt
>=20
>=20
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/
>=20
> Diff from previous version:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-sec-threats-06
>=20
> IETF Secretariat.
>=20


From chris.dearlove@baesystems.com  Tue Jun 18 02:16:08 2013
Return-Path: <chris.dearlove@baesystems.com>
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 4312821F9B20; Tue, 18 Jun 2013 02:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.261
X-Spam-Level: 
X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RnWvMIyioE8; Tue, 18 Jun 2013 02:16:04 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCF621F8904; Tue, 18 Jun 2013 02:16:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,887,1363132800"; d="scan'208";a="347486685"
Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 18 Jun 2013 10:15:56 +0100
X-IronPort-AV: E=Sophos;i="4.87,887,1363132800"; d="scan'208";a="19264460"
Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 18 Jun 2013 10:15:55 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.2.180]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.02.0328.009; Tue, 18 Jun 2013 10:15:55 +0100
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: Russ Housley <housley@vigilsec.com>, IETF <ietf@ietf.org>
Thread-Topic: Gen-ART Review of draft-ietf-manet-rfc6622-bis-02
Thread-Index: AQHOaT0eFhzEQVZMPEinJ81AQTFy/Jk7MyUg
Date: Tue, 18 Jun 2013 09:15:54 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D250921AA@GLKXM0002V.GREENLNK.net>
References: <90D2B755-F68F-4C58-A645-84E4445C73BE@vigilsec.com>
In-Reply-To: <90D2B755-F68F-4C58-A645-84E4445C73BE@vigilsec.com>
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"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Cc: IETF Gen-ART <gen-art@ietf.org>, "manet@ietf.org" <manet@ietf.org>
Subject: Re: [manet] Gen-ART Review of draft-ietf-manet-rfc6622-bis-02
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 09:16:08 -0000

Comments below, marked >>>. I think (though I need my co-authors to agree o=
f course) that a draft with these revisions (and any others we need) will b=
e appropriate following any other IETF LC comments.

-- =

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: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Rus=
s Housley
Sent: 14 June 2013 21:24
To: IETF
Cc: IETF Gen-ART; manet@ietf.org
Subject: Gen-ART Review of draft-ietf-manet-rfc6622-bis-02

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-manet-rfc6622-bis-02
Reviewer: Russ Housley
Review Date: 2013-06-15
IETF LC End Date: 2013-06-27
IESG Telechat date: Unknown

Summary:  The document is almost ready for publication as a
standards track RFC.  I raise one major concern, and once it
is resolved, the document will be ready.

Major Concern:

In Section 12.2.3, is there any difference in processing when the
source IP address is IPv4 as opposed to IPv6?  Obviously, the two have
a different length.  Off the top of my head I cannot find a way for an
attacker to exploit one party using IPv4 in the ICV calculation and the
other party using IPv6.  Since the IPv6 address is 12 octets longer
than the IPv4 address, there may be some opportunity for an attacker.
Anyway, concerns like this are usually thwarted by including the length
of the overall hash function input as the first octet or two of the
value-to-be-hashed.  Such a value does not need to be transmitted.
Each party knows how many octets it passed to the hash function.

>>> As it happens, this value is present in the packet header, but not in t=
he message header, and we do not want to introduce a difference between the=
m. In addition, being after the address might not work.
>>> Like you, I can't see how to exploit and still maintain a legal structu=
re following, but attackers can be very resourceful. and I don't see that t=
his can be guaranteed.
>>> Thus, this appears a good suggestion, with minimal computational overhe=
ad and no over the air overhead.


Minor Concerns:  =


I find Section 1.1 a bit confusing.  I think it should start by saying
that RFC 6622 defined two ICV TLV extension types (0 and 1).  This
document repeats those definitions and adds a third ICV TLV extension
type (2).

>>> OK.

Section 5 says:

  An ICV TLV with type extension =3D 2 specifies a modified version of
  this definition.
 =

This is unclear.  I believe that an ICV TLV with type extension =3D 2 is
an update to ICV TLV with type extension =3D 1.  It would be good to
introduce the need for this update.  I suggest:

  An ICV TLV with type extension =3D 2 is the same as an ICV TLV with
  type extension =3D 1, except that the integrity protection also covers
  the source address of the IP datagram carrying the packet, message,
  or address block.

>>> Might tweak that a little, but OK.

If you accept this suggestion, the following paragraph should also be
revised.  I suggest:

  Specifically, with type extension =3D 1 or type extension =3D 2, the
  <value> field contains the result of combining a cryptographic
  function and a hash function.  The <value> field contains multiple
  sub-fields indicating which hash function and cryptographic function
  have been used as specified in Section 12.

>>> Essentially moving detail from this paragraph to previous one.


********************************************************************
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 abdussalambaryun@gmail.com  Tue Jun 18 05:00:57 2013
Return-Path: <abdussalambaryun@gmail.com>
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 DB08421F9282 for <manet@ietfa.amsl.com>; Tue, 18 Jun 2013 05:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.555
X-Spam-Level: 
X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.045,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH+NvsvQsAYh for <manet@ietfa.amsl.com>; Tue, 18 Jun 2013 05:00:56 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED1521F8FF3 for <manet@ietf.org>; Tue, 18 Jun 2013 05:00:54 -0700 (PDT)
Received: by mail-pa0-f54.google.com with SMTP id kx10so3900690pab.41 for <manet@ietf.org>; Tue, 18 Jun 2013 05:00: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:content-transfer-encoding; bh=UE5N6xdJXYM+3d0fNXmx08OEpBdNDxCXhmlnmgs6PUw=; b=cWSmUpMB/zhFm2HrLwSUbr/IMWZWOSTQ4hU3lwYrAyIMGMnP5MQ46xWPMRagAzLn5d 3jJPcL76QFP2cm6ctOkpTohd2OvIaMLBKgcUfjOuQ+NTs4ygs1savmU2VXq7WagXkk14 yhw4cneCYdl6YjOz2j9MaBWRNKCPFBm3kYRXBFM1YO9NpJMOLyOsgG2ikWOuRLEHXZAD oJY3JmI/HlILJwHwBX7cF0iVGBBXC20oHfjW0RyiOk9dRdKsViie1N9EmmJ/MjfNSOPo gqeJrtIN/OGc90emImDrMeUIbXkGevJ5rMlgSnTQKJGT9g54bw96rXp65HM+48DJO0LM QXCw==
MIME-Version: 1.0
X-Received: by 10.66.121.131 with SMTP id lk3mr1890842pab.43.1371556853764; Tue, 18 Jun 2013 05:00:53 -0700 (PDT)
Received: by 10.68.78.164 with HTTP; Tue, 18 Jun 2013 05:00:53 -0700 (PDT)
In-Reply-To: <51BEEAB8.9080002@fkie.fraunhofer.de>
References: <51BEEAB8.9080002@fkie.fraunhofer.de>
Date: Tue, 18 Jun 2013 14:00:53 +0200
Message-ID: <CADnDZ8_ZucMMYLcof9=ded6M=yP2uFO7nWKcY62GoqXS7CGybw@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "manet@ietf.org" <manet@ietf.org>
Subject: Re: [manet] Informal draft about OLSRv2 ETT metric posted
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 12:00:57 -0000

Thanks to renew (I was waiting for this), it is interesting draft,

AB

On 6/17/13, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:
> Hi,
>
> a few people asked me in the last months if I would like to revive the
> OLSR metric draft I worked on in 2009, so Emmanuel Baccelli and me
> decided to work on a metric draft again.
>
> The new draft is NOT a description of the ETX metric for OLSRv1 as it is
> used in the Freifunk and Funkfeuer networks, it describes the ETT metric
> used in the OLSR.org OLSRv2 implementation (which is based on the
> experience with the OLSRv1 ETX metric).
>
> While updating the draft to the new metric, I cleaned it up and adapted
> it to the directional metric approach used in OLSRv2.
>
> We plan to update the draft in two weeks based on the feedback from this
> list. I will also attend the IETF Meeting in Berlin, so I could give a
> short presentation about the draft there.
>
> You will find the -00 release of the draft at this URL:
>
> http://www.ietf.org/id/draft-rogge-baccelli-olsrv2-ett-metric-00.txt
>
> 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 iesg-secretary@ietf.org  Tue Jun 18 14:34:01 2013
Return-Path: <iesg-secretary@ietf.org>
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 5272D21F84AA; Tue, 18 Jun 2013 14:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.522
X-Spam-Level: 
X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e36zbPwgkpuN; Tue, 18 Jun 2013 14:34:00 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7997821F85B8; Tue, 18 Jun 2013 14:33:59 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130618213359.646.16550.idtracker@ietfa.amsl.com>
Date: Tue, 18 Jun 2013 14:33:59 -0700
Cc: manet chair <manet-chairs@tools.ietf.org>, manet mailing list <manet@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [manet] Document Action: 'Security Threats for NHDP' to Informational RFC	(draft-ietf-manet-nhdp-sec-threats-06.txt)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 21:34:01 -0000

The IESG has approved the following document:
- 'Security Threats for NHDP'
  (draft-ietf-manet-nhdp-sec-threats-06.txt) as Informational RFC

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-sec-threats/




Technical Summary

   This document analyzes common security threats of the Neighborhood Discovery
   Protocol (NHDP), and describes their potential impacts on MANET routing 
   protocols using NHDP.

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 does not specify a protocol, therefore no implementations
   are available. There are several NHDP implementations existing, and the WG
   has a thorough understanding of the protocol and its security considerations. 

Personnel

Joseph Macker (joseph.macker@nrl.navy.mil) is the document shepherd.
Adrian Farrel (adrian@olddog.co.uk) is the responsible AD.

From valerio.arnaboldi@iit.cnr.it  Sun Jun 23 05:45:51 2013
Return-Path: <valerio.arnaboldi@iit.cnr.it>
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 EFAD421F9D1D for <manet@ietfa.amsl.com>; Sun, 23 Jun 2013 05:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.928
X-Spam-Level: 
X-Spam-Status: No, score=-0.928 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAOFUXHLXC0J for <manet@ietfa.amsl.com>; Sun, 23 Jun 2013 05:45:47 -0700 (PDT)
Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) by ietfa.amsl.com (Postfix) with ESMTP id CB6CA21F9C26 for <manet@ietf.org>; Sun, 23 Jun 2013 05:45:46 -0700 (PDT)
Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by mxbk.iit.cnr.it (Postfix) with ESMTPA id 37C37C0694 for <manet@ietf.org>; Sun, 23 Jun 2013 14:45:40 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Valerio Arnaboldi<valerio.arnaboldi@iit.cnr.it>
To: manet@ietf.org
Message-Id: <20130623124546.CB6CA21F9C26@ietfa.amsl.com>
Date: Sun, 23 Jun 2013 05:45:46 -0700 (PDT)
Subject: [manet] IFIP/IEEE SustainIT 2013: Submission deadline for Demo/WiP/PhD Forum papers EXTENDED to July 5
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jun 2013 12:45:52 -0000

Dear Colleagues, 

Due to numerous requests, the submission deadline for Demo, WiP and PhD Forum papers has been EXTENDED to July 5, 2013. Please refer to the conference website http://www.dicgim.unipa.it/networks/sustainit2013 for more information about the various calls and their submission instructions.  

We remind you that all accepted papers will be included in the conference proceedings and they will be published in the IEEE Digital Library. 

Looking forward to receiving your valuable contributions.

Kind regards,
Raffaele & Thierry
TPC Co-chairs

From henning.rogge@fkie.fraunhofer.de  Mon Jun 24 01:57:37 2013
Return-Path: <henning.rogge@fkie.fraunhofer.de>
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 EEE2B21F9B5C for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 01:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJQ8dppWgn9N for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 01:57:31 -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 01B8E21E8088 for <manet@ietf.org>; Mon, 24 Jun 2013 01:57:31 -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 <henning.rogge@fkie.fraunhofer.de>) id 1Ur2aX-0000Bp-UF for manet@ietf.org; Mon, 24 Jun 2013 10:57:29 +0200
Received: from mailserv2acas.fkie.fraunhofer.de ([128.7.96.54] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <henning.rogge@fkie.fraunhofer.de>) id 1Ur2aX-00053z-Rh for manet@ietf.org; Mon, 24 Jun 2013 10:57:29 +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 Jun 2013 10:57:29 +0200
Message-ID: <51C809F5.1030301@fkie.fraunhofer.de>
Date: Mon, 24 Jun 2013 10:57:25 +0200
From: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: <manet@ietf.org>
References: <51BEEAB8.9080002@fkie.fraunhofer.de>
In-Reply-To: <51BEEAB8.9080002@fkie.fraunhofer.de>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030408060302030805080707"
X-Originating-IP: [128.7.5.36]
X-Virus-Scanned: yes (ClamAV 0.97.8/17404/Mon Jun 24 06:45:31 2013) by a.mx.fkie.fraunhofer.de
X-Scan-Signature: 44205366898805df1de72924aa95b600
Subject: Re: [manet] ETT draft -01 released
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2013 08:57:37 -0000

--------------ms030408060302030805080707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

based on a couple of Reviews we just released draft -01 of our ETT=20
metric draft.

http://www.ietf.org/id/draft-rogge-baccelli-olsrv2-ett-metric-01.txt

We would like to see more feedback on the draft and plan to fold coming=20
changes into a -02 revision before the cutoff date for Berlin.

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


--------------ms030408060302030805080707
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
Fw0xMzA2MjQwODU3MjhaMCMGCSqGSIb3DQEJBDEWBBQcT4l8AtXHHVJmFry/yRa2IfKf0jBs
BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw
DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo
MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy
MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m
ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG
A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y
cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA
uuYwDQYJKoZIhvcNAQEBBQAEggEAr0lvQplbOR9ZjbOsStrZU8cYwYvySJxzoep+vWQMkEY+
WvJgJCHHna/Pu7Jh606M5dLSn+tgPxt29AOt+ntyAZXDyWLuIMvP9+CHswRGfIb5K8DLLKKh
uHtdUD49/r0Sh1HD1HlCvBFlO74DOlytWItpIppSF7LSnEf2y03qvM56L1eZwyEvvsScpygL
vdiUlajS32raFZ7vbqkgRhYupia3lZtfhWa2DbQR4e+rFO4uLh+J05bCnkXhZxUgKgjUMBZA
DOudVldMgS9wzbxIHoHRiJqmhMv34T2pkExSWPI8/ojZ13Y9K9S4aQN6yOl2iUZQ/iDfGjX9
mXqWQblSqgAAAAAAAA==
--------------ms030408060302030805080707--

From sratliff@cisco.com  Mon Jun 24 10:34:34 2013
Return-Path: <sratliff@cisco.com>
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 713E521E8106 for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 10:34:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJAEgTYDFybz for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 10:34:29 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3D08521E80E9 for <manet@ietf.org>; Mon, 24 Jun 2013 10:34:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2742; q=dns/txt; s=iport; t=1372095269; x=1373304869; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=z1/rw82a/ihM6mxfRyVO7LN6xjQoDWkwy+fnNMr2f7A=; b=AnXs8piJI6RB++QTh1xkJnWJTHibaM8FtASVFzKOEpkk7iYlkfMWJMl3 ZwVCo2R9OExDoHXSgXkxJsoN85kGx+Gm0oZMD/+ZrKq156BFgW9TtQTjH 2Of/9MIpLEQEKfw+Svco8+lxxISNeTcYoJvfC+s3qa023/kQW5MNRzCdH 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah8FAPGByFGtJXHB/2dsb2JhbABbgwkxQwa/OIEHFnSCIwEBAQMBAQEBNzQQCwIBCBgKFBAnCyUCBBMIAYd/BgcFumGPHAI4gwJhA5NxhHuQG4MQgig
X-IronPort-AV: E=Sophos;i="4.87,929,1363132800"; d="scan'208";a="226757611"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 24 Jun 2013 17:34:28 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5OHYStL008649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <manet@ietf.org>; Mon, 24 Jun 2013 17:34:28 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.173]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 24 Jun 2013 12:34:28 -0500
From: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
To: "manet@ietf.org List" <manet@ietf.org>
Thread-Topic: [manet] draft-ietf-manet-olsrv2-mib-11.txt
Thread-Index: AQHOZ95Qwahaeo17c0GyMQsWFowEaJlFhjuA
Date: Mon, 24 Jun 2013 17:34:27 +0000
Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1016B2DD@xmb-aln-x03.cisco.com>
References: <20130613014540.21901.50402.idtracker@ietfa.amsl.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C1014D4A0@xmb-aln-x03.cisco.com>
In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C1014D4A0@xmb-aln-x03.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.102.41.144]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BA4078EB9E76E1409B6B1031F3F56A3C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [manet] draft-ietf-manet-olsrv2-mib-11.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2013 17:34:34 -0000

Hello WG,=20

Just noting (very late, and thanks to Adrian for reminding me) that this 7-=
day period has expired without any comments from the WG. So, we press on wi=
th publication of the OLSRv2 MIB.=20

Regards,
Stan
+
On Jun 12, 2013, at 10:32 PM, Stan Ratliff (sratliff) wrote:

> Hello, Working Group -=20
>=20
> The OSLR MIB document has undergone some changes during the IESG review p=
rocess. In order to give the WG a chance to review and comment, we are requ=
esting your attention to the doc during a 7-day "Sanity Check" period. This=
 7-day window will end at 2300 EDT on June 19. So please give the doc a loo=
k, and comment as you feel appropriate.=20
>=20
> Regards,
> Stan
>=20
>=20
> On Jun 12, 2013, at 9:45 PM, <internet-drafts@ietf.org>
> <internet-drafts@ietf.org> wrote:
>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
>> 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	 Optimized Link=
 State Routing Protocol version 2
>> 	Author(s)       : Ulrich Herberg
>>                         Robert G. Cole
>>                         Thomas Heide Clausen
>> 	Filename        : draft-ietf-manet-olsrv2-mib-11.txt
>> 	Pages           : 85
>> 	Date            : 2013-06-12
>>=20
>> Abstract:
>>  This document defines the Management Information Base (MIB) module
>>  for configuring and managing the Optimized Link State Routing
>>  protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
>>  into configuration information, state information, performance
>>  information, and notifications.  This additional state and
>>  performance information is useful to troubleshoot problems and
>>  performance issues of the routing protocol.  Two levels of compliance
>>  allow this MIB module to be deployed on constrained routers.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-11
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mib-11
>>=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 charliep@computer.org  Mon Jun 24 16:51:43 2013
Return-Path: <charliep@computer.org>
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 3FA2021F9F0A for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 16:51:43 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd0ex+eJiwCG for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 16:51:28 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id A022921F9F03 for <manet@ietf.org>; Mon, 24 Jun 2013 16:51:27 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1UrGXc-0001QF-M8 for manet@ietf.org; Mon, 24 Jun 2013 19:51:24 -0400
Message-ID: <51C8DB7A.3000004@computer.org>
Date: Mon, 24 Jun 2013 16:51:22 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: manet@ietf.org
References: <061.db3c48158682d65cd854a9d5c40c741f@trac.tools.ietf.org> <511588AC.7020404@computer.org> <CADnDZ8_x6H+pfad6NsUsDy9U6fMi=7rd9VyjY17_K+jXkjt=mA@mail.gmail.com>
In-Reply-To: <CADnDZ8_x6H+pfad6NsUsDy9U6fMi=7rd9VyjY17_K+jXkjt=mA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8678eb994b4caa13660c76ef8092f46311350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Subject: Re: [manet] #5: Reorganizing the route table entry timeout management
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2013 23:51:43 -0000

Hello folks,

I'm not sure who has the authority to close issues, but if the submitter 
believes
that the issue can be closed, and no one in the working group disagrees, 
then
I reckon it's O.K. for the issue to close.

So I think that this issue can be closed :-)  I have not seen any 
disagreement.

Regards,
Charlie P.


On 2/11/2013 12:03 AM, Abdussalam Baryun wrote:
> I advise not to close any related issue until Chair makes input. We
> still not received the email of chair regarding editing team of the
> reactive protocol. IMO, it is reasonable to close WG-issues only after
> receiving the Chair's advises. Otherwise why the chair is a chair, I
> think the chair helps to close such WG issues. The co-chair mentioned
> to continue WG discuss or I may understand to open issues but not
> understand to close issues,
>
> If I mistaken or missed something please advise,
>
> AB
>
> On 2/9/13, Charles E. Perkins <charliep@computer.org> wrote:
>> Hello folks,
>>
>> The route table timeout issue and proposed resolution has been incorporated
>> in the most recent revisions for the AODVv2 specification.  If the new
>> timeout
>> structure and definitions are satisfactory, the AODVv2 editing team will
>> consider closing issue #5.  Please let us know if there is any objection to
>> closing the issue.
>>
>> Regards,
>> Charlie P.
>>
>> On 11/4/2012 8:52 PM, manet issue tracker wrote:
>>> #5: Reorganizing the route table entry timeout management
>>>
>>>    The current set of route timeouts and concepts is confusing.  Instead,
>>> one
>>>    can view a route table entry as having a normal lifetime progressing
>>>    through the following stages: Active --> Idle --> Expired --> Expunged.
>>>    Alternatively a route can be prematurely invalidated if one of its path
>>>    components breaks (i.e., the link to a next hop breaks).  By
>>> reorganizing
>>>    route lifetime information in this way, a much simpler description can
>>> be
>>>    given.  The following proposed text should make this approach clearer.
>>>    Instead of previous manifest constants for various timeout information,
>>>    the new approach only requires ACTIVE_INTERVAL, MAX_IDLETIME, and
>>>    MAX_SEQNUM_LIFETIME.  The following text has been (provisionally) added
>>> to
>>>    Section 4.1.
>>>
>>>
>>> ========================================================================
>>>
>>>       A route table entry (i.e., a route) may be in one of the following
>>>       states:
>>>
>>>       Active
>>>          An Active route is in current use for forwarding packets
>>>
>>>       Idle
>>>          An Idle route can be used for forwarding packets, even though it
>>>          is not in current use
>>>
>>>       Expired
>>>          After a route has been idle for too long, it expires, and may no
>>>          longer be used for forwarding packets
>>>
>>>       Broken
>>>          A route marked as Broken cannot be used for forwarding packets
>>> but
>>>          still has valid destination sequence number information.
>>>
>>>       The route's state determines the operations that can be performed on
>>>       the route table entry.  During use, an Active route is maintained
>>>       continuously by AODVv2 and is considered to remain active as long as
>>>       it is used at least once every ACTIVE_INTERVAL.  When a route is no
>>>       longer Active, it becomes an Idle route.  After a route remains Idle
>>>       for MAX_IDLETIME, it becomes an Expired route; after that, the route
>>>       is not used for forwarding, but the sequence number information is
>>>       maintained until the destination sequence number has had no updates
>>>       for MAX_SEQNUM_LIFETIME.  After MAX_SEQNUM_LIFETIME, old sequence
>>>       number information is considered no longer valuable and the route is
>>>       expunged.
>>>
>>>       MAX_SEQNUM_LIFETIME is the time after a reboot during which an
>>> AODVv2
>>>       router MUST NOT transmit any routing messages.  Thus, if all other
>>>       AODVv2 routers expunge routes to the rebooted router after that time
>>>       interval, the rebooted AODVv2 router's sequence number will not be
>>>       considered stale by any other AODVv2 router in the MANET.
>>>
>>>       When the link to a route's next hop is broken, the route is in the
>>>       Broken state, and it may no longer be used.
>>>
>>>
>>> ========================================================================
>>>
>>>    Note that if (ACTIVE_INTERVAL + MAX_IDLETIME) == MAX_SEQNUM_LIFETIME,
>>>    then a route has to be expunged as soon as it has been idle too long.
>>>    This has little negative impact on the base protocol but may eliminate
>>> the
>>>    possibility for some optional features related to route repair.
>>>
>>
>> --
>> Regards,
>> Charlie P.
>>
>> _______________________________________________
>> 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
>


-- 
Regards,
Charlie P.


From charliep@computer.org  Mon Jun 24 16:59:40 2013
Return-Path: <charliep@computer.org>
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 9437C21F9D81 for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 16:59:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlqmFefAHKQN for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 16:59:34 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id B513121F9D76 for <manet@ietf.org>; Mon, 24 Jun 2013 16:59:34 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1UrGfU-0007Gf-3R for manet@ietf.org; Mon, 24 Jun 2013 19:59:32 -0400
Message-ID: <51C8DD62.2040306@computer.org>
Date: Mon, 24 Jun 2013 16:59:30 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: manet@ietf.org
References: <061.132760a1d00e99fedcf3e89100775c1a@trac.tools.ietf.org>
In-Reply-To: <061.132760a1d00e99fedcf3e89100775c1a@trac.tools.ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86699ebd7c8e28871db72df3b2d2b72634350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Subject: Re: [manet] #6: sequence number incrementation mandate
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2013 23:59:40 -0000

Hello folks,

The stronger mandate has been specified in recent revisions of the document.
Doing so has, as expected, simplified numerous parts of the overall 
specification,
and no objections have been expressed for this proposed resolution of the
issue.

For this reason, I believe it is reasonable to close the issue, unless 
there are
use cases suggested to the mailing list for reducing the strength of the
mandate back to its previous status of "SHOULD".

Regards,
Charlie P.

On 11/4/2012 9:07 PM, manet issue tracker wrote:
> #6: sequence number incrementation mandate
>
>   Previous versions of DYMO *strongly recommend* incrementation of
>   !OwnSeqNum upon generation of every new RREQ or RREP message, but do not
>   impose a strict mandate.  This leads to some uncertainty about whether
>   there are cases when the incrementation should not be performed.
>   Demonstrations have been made in the past about the differences, but it is
>   not clear that these differences have caused any performance degradation.
>
>   For the purposes of making the current document more readable, and since
>   there seems to be little downside, it is proposed to change "SHOULD"
>   increment to "MUST" increment in all relevant cases, including RREQ
>   retries.
>   If future studies illustrate the circumstances under which sequence number
>   incrementation may be avoided, description of those circumstances should
>   be added to the document and the specification changed in those
>   circumstances.
>


-- 
Regards,
Charlie P.


From charliep@computer.org  Mon Jun 24 17:14:19 2013
Return-Path: <charliep@computer.org>
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 8EDE221F9E05 for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 17:14:19 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+LYuKHvUcj9 for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 17:14:14 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id AE60621F9DF9 for <manet@ietf.org>; Mon, 24 Jun 2013 17:14:14 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1UrGth-0001YL-Pv for manet@ietf.org; Mon, 24 Jun 2013 20:14:14 -0400
Message-ID: <51C8E0D3.9040608@computer.org>
Date: Mon, 24 Jun 2013 17:14:11 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: manet@ietf.org
References: <061.f6d9e0fa28b46c77085c2605af4906fb@trac.tools.ietf.org> <CADnDZ8-t=_LK7wZbb6QpQoo-1Zrz=T9Fv=k-aQO7yKzE754MTg@mail.gmail.com>
In-Reply-To: <CADnDZ8-t=_LK7wZbb6QpQoo-1Zrz=T9Fv=k-aQO7yKzE754MTg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8614805fdd554fc2b161ad762ebdc87624350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Subject: Re: [manet] #7: Top level document organization
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 00:14:19 -0000

Hello folks,

This has been done, and has not caused any presentation difficulties
or organizational inconvenience in recent versions of the specification.
Therefore, unless there are any objections or suggestions for further
improvement, I think we can safely close this issue.

Regards,
Charlie P.


On 11/6/2012 3:35 AM, Abdussalam Baryun wrote:
> Thanks, I agree with the proposal,
>
> AB
>
> On 11/5/12, manet issue tracker <trac+manet@trac.tools.ietf.org> wrote:
>> #7: Top level document organization
>>
>>   Previous revisions have collected together various sections describing
>>   base protocol features into a top-level section entitled "Detailed
>>   Operation for the Base Protocol".  However, this does not seem to provide
>>   very much guidance for finding appropriate sections of the document, and
>>   some of the subsections seem better suited to be described in their own
>>   high-level sections.  There is another section devoted to Optional
>>   Features, and it seems that already provides a pretty good way to separate
>>   Base features from Optional features.  It is proposed to eliminate the
>>   abovementioned top-level section and promote its subsections to be top-
>>   level sections.
>>
>>   Here is a snapshot of the Table of Contents, still subject to minor
>>   changes:
>>
>>   {{{
>>   Table of Contents
>>
>>      1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
>>      2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
>>      3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  7
>>      4.  Data Structures  . . . . . . . . . . . . . . . . . . . . . . .  8
>>        4.1.  Route Table Entry  . . . . . . . . . . . . . . . . . . . .  8
>>        4.2.  AODVv2 Message Structure and Information Elements  . . . . 10
>>        4.3.  RteMsg-specific Protocol Elements  . . . . . . . . . . . . 13
>>        4.4.  Route Error (RERR)-specific Protocol Elements  . . . . . . 14
>>      5.  AODVv2 Sequence Numbers  . . . . . . . . . . . . . . . . . . . 14
>>      6.  AODVv2 Operations on Route Table Entries . . . . . . . . . . . 15
>>        6.1.  Evaluating Incoming Routing Information  . . . . . . . . . 15
>>        6.2.  Creating or Updating Route Table Entries . . . . . . . . . 17
>>        6.3.  Route Table Entry Timeouts . . . . . . . . . . . . . . . . 17
>>      7.  Routing Messages . . . . . . . . . . . . . . . . . . . . . . . 18
>>        7.1.  RREQ Creation  . . . . . . . . . . . . . . . . . . . . . . 18
>>        7.2.  RREP Creation  . . . . . . . . . . . . . . . . . . . . . . 19
>>        7.3.  Handling a Received RteMsg . . . . . . . . . . . . . . . . 19
>>      8.  Route Discovery, Retries, and Buffering  . . . . . . . . . . . 21
>>      9.  Route Maintenance  . . . . . . . . . . . . . . . . . . . . . . 22
>>        9.1.  Active Next-hop Router Adjacency Monitoring  . . . . . . . 22
>>        9.2.  Handling Route Lifetimes During Packet Forwarding  . . . . 23
>>        9.3.  RERR Generation  . . . . . . . . . . . . . . . . . . . . . 23
>>        9.4.  Receiving and Handling RERR Messages . . . . . . . . . . . 24
>>      10. Unknown Message and TLV Types  . . . . . . . . . . . . . . . . 25
>>      11. Advertising Network Addresses  . . . . . . . . . . . . . . . . 25
>>      12. Simple Internet Attachment . . . . . . . . . . . . . . . . . . 25
>>      13. Multiple Interfaces  . . . . . . . . . . . . . . . . . . . . . 27
>>      14. AODVv2 Control Packet/Message Generation Limits  . . . . . . . 27
>>      15. Optional Features  . . . . . . . . . . . . . . . . . . . . . . 27
>>        15.1. Expanding Rings Multicast  . . . . . . . . . . . . . . . . 28
>>        15.2. Intermediate RREP  . . . . . . . . . . . . . . . . . . . . 28
>>        15.3. Precursor Notification . . . . . . . . . . . . . . . . . . 28
>>          15.3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . 28
>>          15.3.2.  Precursor Notification  . . . . . . . . . . . . . . . 28
>>        15.4. Reporting Multiple Unreachable Nodes . . . . . . . . . . . 30
>>        15.5. Message Aggregation  . . . . . . . . . . . . . . . . . . . 30
>>        15.6. Adding Additional Routing Information to a RteMsg  . . . . 30
>>      16. Administratively Configured Parameters and Timer Values  . . . 32
>>      17. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
>>        17.1. AODVv2 Message Types Specification . . . . . . . . . . . . 35
>>        17.2. Message and Address Block TLV Type Specification . . . . . 35
>>        17.3. Address Block TLV Specification  . . . . . . . . . . . . . 36
>>      18. Security Considerations  . . . . . . . . . . . . . . . . . . . 36
>>      19. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 38
>>      20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
>>        20.1. Normative References . . . . . . . . . . . . . . . . . . . 38
>>        20.2. Informative References . . . . . . . . . . . . . . . . . . 39
>>      Appendix A.  Changes since the Previous Version  . . . . . . . . . 40
>>      Appendix B.  Shifting Network Prefix Advertisement Between
>>                   AODVv2 Routers  . . . . . . . . . . . . . . . . . . . 41
>>      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
>>   }}}
>>
>> --
>> --------------------------------+-----------------------------
>>   Reporter:  charliep@…          |      Owner:  Charlie Perkins
>>       Type:  enhancement         |     Status:  new
>>   Priority:  minor               |  Milestone:
>> Component:  dymo                |    Version:
>>   Severity:  Active WG Document  |   Keywords:
>> --------------------------------+-----------------------------
>>
>> Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/7>
>> manet <http://tools.ietf.org/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
>


-- 
Regards,
Charlie P.


From trac+manet@trac.tools.ietf.org  Mon Jun 24 18:24:11 2013
Return-Path: <trac+manet@trac.tools.ietf.org>
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 3DF9E21E812C for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 18:24:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGDLaLoPZKAS for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 18:24:10 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8B021E804E for <manet@ietf.org>; Mon, 24 Jun 2013 18:24:10 -0700 (PDT)
Received: from localhost ([127.0.0.1]:58755 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+manet@trac.tools.ietf.org>) id 1UrHzM-0001PE-PI; Tue, 25 Jun 2013 03:24:08 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "manet issue tracker" <trac+manet@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: charliep@computer.org
X-Trac-Project: manet
Date: Tue, 25 Jun 2013 01:24:08 -0000
X-URL: http://tools.ietf.org/manet/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/8#comment:1
Message-ID: <076.16046b14872d1f7b70314e7d63b074a5@trac.tools.ietf.org>
References: <061.01e84a8c55d727234bea54462c8094cf@trac.tools.ietf.org>
X-Trac-Ticket-ID: 8
In-Reply-To: <061.01e84a8c55d727234bea54462c8094cf@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org
X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: manet@ietf.org
Subject: Re: [manet] #8: HopCount and alternate metrics in AODVv2
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: manet@ietf.org
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 01:24:11 -0000

#8: HopCount and alternate metrics in AODVv2


Comment (by charliep@computer.org):

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

 On 11/7/2012 1:29 PM, JP Vasseur (jvasseur) wrote:

 Completely agreeing. Although I love simplicity with only hop counts, it
 turns out not to always be the most relevant metric in MANET. It is not so
 rare to see shorter delays on longer paths in terms of hop counts. Same
 comment for Packet Delivery Ratio (some link may have really high ETX!).
 Not suggesting to adopt a similar model as in RFC6551, but adding a bit of
 flexibility will help in the future, even if we start with something very
 simple.

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

 On 11/7/2012 1:39 PM, Henning Rogge wrote:

 In my experience Hopcount metrics don't work well in wireless networks
 unless you have very specific links. Using hopcount as a metric means
 you optimize for LONG links, which are often the ones that do not work
 reasonable well. Without a well thought hysteresis your network might
 just dissolve into a huge mess, especially for multirate networks like
 IEEE802.11.

 Saying "hopcount is the most relevant metric in MANET" is at best
 shady... and at worst just wrong.

 I agree that <(CEP): typo deleted here> specifying the metric is a good
 idea (similar to the
 way it has been done in OLSRv2), but hopcount only is a poor choice
 for a metric.

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

-- 
-------------------------------------+------------------------------
 Reporter:  charliep@computer.org    |       Owner:  Charlie Perkins
     Type:  enhancement              |      Status:  new
 Priority:  major                    |   Milestone:
Component:  dymo                     |     Version:
 Severity:  Active WG Document       |  Resolution:
 Keywords:  route metric, hop count  |
-------------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/8#comment:1>
manet <http://tools.ietf.org/manet/>


From charliep@computer.org  Mon Jun 24 18:34:28 2013
Return-Path: <charliep@computer.org>
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 9DEAC11E80D7 for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 18:34:28 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMSexLQykU2V for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 18:34:23 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id B111111E80E1 for <manet@ietf.org>; Mon, 24 Jun 2013 18:34:23 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1UrI9F-0002Z4-1g for manet@ietf.org; Mon, 24 Jun 2013 21:34:21 -0400
Message-ID: <51C8F39B.30905@computer.org>
Date: Mon, 24 Jun 2013 18:34:19 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: manet@ietf.org
References: <061.01e84a8c55d727234bea54462c8094cf@trac.tools.ietf.org> <03B78081B371D44390ED6E7BADBB4A7722061AF6@xmb-rcd-x02.cisco.com> <CAGnRvuqdUo9n0suB+A3sDxy6atLSs9yF1vXfGuyZ-9CVicYo5Q@mail.gmail.com> <03B78081B371D44390ED6E7BADBB4A7722063860@xmb-rcd-x02.cisco.com>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A7722063860@xmb-rcd-x02.cisco.com>
Content-Type: multipart/alternative; boundary="------------070500050505040406020001"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867b034131bcb26132bc6bc22f2b8b4282350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Subject: Re: [manet] #8: HopCount and alternate metrics in AODVv2
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 01:34:28 -0000

This is a multi-part message in MIME format.
--------------070500050505040406020001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Hello folks,

I have collected together the comments to this issue and posted
them on the issue tracker.  The upshot is that the comments to
the mailing list supported the generalization of AODVv2 to support
alternate metrics.  This has been done, and the metric type (when
not the default) is to be determined by the contents of a new
message TLV, the Metric Type TLV which contains the metric type
(from RFC 6551) of the metric values in the address block Metric TLV.

No additional problems have been identified with the additional
specification to enable alternative metric types.  Unless new issues
are brought to the attention of the mailing list, I think it is safe to
close this issue.

Regards,
Charlie P.


On 11/8/2012 9:31 AM, JP Vasseur (jvasseur) wrote:
>
> On Nov 7, 2012, at 10:39 PM, Henning Rogge wrote:
>
>> On Wed, Nov 7, 2012 at 10:29 PM, JP Vasseur (jvasseur)
>> <jvasseur@cisco.com <mailto:jvasseur@cisco.com>> wrote:
>>> Hi Charlie,
>>>
>>> On Nov 7, 2012, at 11:56 AM, manet issue tracker wrote:
>>>
>>>> #8: HopCount and alternate metrics in AODVv2
>>>>
>>>> Most of the language in the current specification for route metrics is
>>>> actually specific to !HopCount.  It is proposed to rename existing 
>>>> metric
>>>> fields to actually *be* !HopCount, to improve clarity.
>>>>
>>>> Following common practice up until now, the default route metric for
>>>> AODVv2 is !HopCount.  Nevertheless, the document should allow for
>>>> alternate metrics to be used.  To be compatible with RFC 5444 and the
>>>> current reactive features, the following design guidelines are 
>>>> suggested.
>>>> * a new AddTLV of type "metric" should be supported.  The metric AddTLV
>>>>   would supply metric values for each of the addresses in the !AddBlk
>>>> * a metric 'type' should be supplied in a msg-TLV
>>>>
>>>> Whether or not the metric belongs in AODVv2 this year is a matter for
>>>> discussion.  The design can be quite straightforward, requiring only an
>>>> IANA registry for "metric type".  Given the flexibiity of RFC 5444 msg-
>>>> header format, very general metrics could be supported.  Metric 
>>>> type '0'
>>>> would be reserved for HopCount.
>>>
>>> Completely agreeing. Although I love simplicity with only hop 
>>> counts, it turns out not
>>> to always be the most relevant metric in MANET.
>>
>> In my experience Hopcount metrics don't work well in wireless networks
>> unless you have very specific links. Using hopcount as a metric means
>> you optimize for LONG links, which are often the ones that do not work
>> reasonable well. Without a well thought hysteresis your network might
>> just dissolve into a huge mess, especially for multirate networks like
>> IEEE802.11.
>>
>> Saying "hopcount is the most relevant metric in MANET" is at best
>> shady... and at worst just wrong.
>
> we agree this is what I wrote ;-) ... "*Although* I love simplicity 
> with only hop counts, it turns out *not*
> to always be the most relevant metric in MANET
>
>>
>>> It is not so rare to see shorter delays
>>> on longer paths in terms of hop counts. Same comment for Packet 
>>> Delivery Ratio (some
>>> link may have really high ETX!).
>>> Not suggesting to adopt a similar model as in RFC6551, but adding a 
>>> bit of flexibility will
>>> help in the future, even if we start with something very simple.
>>
>> I agree that not specifying the metric is a good idea (similar to the
>> way it has been done in OLSRv2), but hopcount only is a poor choice
>> for a metric.
>>
>
> indeed, this is why I was referring to the RFC6551 (being the editor 
> of the document) although we may
> not need all of these metrics.
>
> JP.
>
>> Henning Rogge
>>
>> -- 
>> Steven Hawkings about cosmic inflation: "An increase of billions of
>> billions of percent in a tiny fraction of a second. Of course, that
>> was before the present government."
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


-- 
Regards,
Charlie P.


--------------070500050505040406020001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix"><br>
      Hello folks,<br>
      <br>
      I have collected together the comments to this issue and posted<br>
      them on the issue tracker.&nbsp; The upshot is that the comments to<br>
      the mailing list supported the generalization of AODVv2 to support<br>
      alternate metrics.&nbsp; This has been done, and the metric type (when<br>
      not the default) is to be determined by the contents of a new<br>
      message TLV, the Metric Type TLV which contains the metric type<br>
      (from RFC 6551) of the metric values in the address block Metric
      TLV.<br>
      <br>
      No additional problems have been identified with the additional<br>
      specification to enable alternative metric types.&nbsp; Unless new
      issues<br>
      are brought to the attention of the mailing list, I think it is
      safe to<br>
      close this issue.<br>
      <br>
      Regards,<br>
      Charlie P.<br>
      <br>
      <br>
      On 11/8/2012 9:31 AM, JP Vasseur (jvasseur) wrote:<br>
    </div>
    <blockquote
cite="mid:03B78081B371D44390ED6E7BADBB4A7722063860@xmb-rcd-x02.cisco.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <br>
      <div>
        <div>On Nov 7, 2012, at 10:39 PM, Henning Rogge wrote:</div>
        <br class="Apple-interchange-newline">
        <blockquote type="cite">
          <div>On Wed, Nov 7, 2012 at 10:29 PM, JP Vasseur (jvasseur)<br>
            &lt;<a moz-do-not-send="true"
              href="mailto:jvasseur@cisco.com">jvasseur@cisco.com</a>&gt;
            wrote:<br>
            <blockquote type="cite">Hi Charlie,<br>
            </blockquote>
            <blockquote type="cite"><br>
            </blockquote>
            <blockquote type="cite">On Nov 7, 2012, at 11:56 AM, manet
              issue tracker wrote:<br>
            </blockquote>
            <blockquote type="cite"><br>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">#8: HopCount and alternate metrics
                in AODVv2<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite"><br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">Most of the language in the
                current specification for route metrics is<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">actually specific to !HopCount.
                &nbsp;It is proposed to rename existing metric<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">fields to actually *be* !HopCount,
                to improve clarity.<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite"><br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">Following common practice up until
                now, the default route metric for<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">AODVv2 is !HopCount.
                &nbsp;Nevertheless, the document should allow for<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">alternate metrics to be used. &nbsp;To
                be compatible with RFC 5444 and the<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">current reactive features, the
                following design guidelines are suggested.<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">* a new AddTLV of type "metric"
                should be supported. &nbsp;The metric AddTLV<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">&nbsp;&nbsp;would supply metric values for
                each of the addresses in the !AddBlk<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">* a metric 'type' should be
                supplied in a msg-TLV<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite"><br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">Whether or not the metric belongs
                in AODVv2 this year is a matter for<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">discussion. &nbsp;The design can be
                quite straightforward, requiring only an<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">IANA registry for "metric type".
                &nbsp;Given the flexibiity of RFC 5444 msg-<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">header format, very general
                metrics could be supported. &nbsp;Metric type '0'<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite">
              <blockquote type="cite">would be reserved for HopCount.<br>
              </blockquote>
            </blockquote>
            <blockquote type="cite"><br>
            </blockquote>
            <blockquote type="cite">Completely agreeing. Although I love
              simplicity with only hop counts, it turns out not<br>
            </blockquote>
            <blockquote type="cite">to always be the most relevant
              metric in MANET.<br>
            </blockquote>
            <br>
            In my experience Hopcount metrics don't work well in
            wireless networks<br>
            unless you have very specific links. Using hopcount as a
            metric means<br>
            you optimize for LONG links, which are often the ones that
            do not work<br>
            reasonable well. Without a well thought hysteresis your
            network might<br>
            just dissolve into a huge mess, especially for multirate
            networks like<br>
            IEEE802.11.<br>
            <br>
            Saying "hopcount is the most relevant metric in MANET" is at
            best<br>
            shady... and at worst just wrong.<br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>we agree this is what I wrote ;-) &#8230; "<b>Although</b> I love
          simplicity with only hop counts, it turns out
          <b>not</b></div>
        <div>to always be the most relevant metric in MANET</div>
        <br>
        <blockquote type="cite">
          <div><br>
            <blockquote type="cite">It is not so rare to see shorter
              delays<br>
            </blockquote>
            <blockquote type="cite">on longer paths in terms of hop
              counts. Same comment for Packet Delivery Ratio (some<br>
            </blockquote>
            <blockquote type="cite">link may have really high ETX!).<br>
            </blockquote>
            <blockquote type="cite">Not suggesting to adopt a similar
              model as in RFC6551, but adding a bit of flexibility will<br>
            </blockquote>
            <blockquote type="cite">help in the future, even if we start
              with something very simple.<br>
            </blockquote>
            <br>
            I agree that not specifying the metric is a good idea
            (similar to the<br>
            way it has been done in OLSRv2), but hopcount only is a poor
            choice<br>
            for a metric.<br>
            <br>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>indeed, this is why I was referring to the RFC6551 (being
          the editor of the document) although we may</div>
        <div>not need all of these metrics.</div>
        <div><br>
        </div>
        <div>JP.</div>
        <br>
        <blockquote type="cite">
          <div>Henning Rogge<br>
            <br>
            -- <br>
            Steven Hawkings about cosmic inflation: "An increase of
            billions of<br>
            billions of percent in a tiny fraction of a second. Of
            course, that<br>
            was before the present government."<br>
          </div>
        </blockquote>
      </div>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
manet mailing list
<a class="moz-txt-link-abbreviated" href="mailto:manet@ietf.org">manet@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/manet">https://www.ietf.org/mailman/listinfo/manet</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Regards,
Charlie P.</pre>
  </body>
</html>

--------------070500050505040406020001--

From charliep@computer.org  Mon Jun 24 18:48:00 2013
Return-Path: <charliep@computer.org>
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 D32D111E80ED for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 18:48:00 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y35W5WecEj5p for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 18:47:51 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id CD63521F9C35 for <manet@ietf.org>; Mon, 24 Jun 2013 18:47:51 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1UrIMJ-0004gP-A2; Mon, 24 Jun 2013 21:47:51 -0400
Message-ID: <51C8F6C5.4020503@computer.org>
Date: Mon, 24 Jun 2013 18:47:49 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: manet@ietf.org
References: <061.a0055255c275fede343be9cc794f90e9@trac.tools.ietf.org> <076.52442cdbde1e4756a95fb455111cef29@trac.tools.ietf.org>
In-Reply-To: <076.52442cdbde1e4756a95fb455111cef29@trac.tools.ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8674a47d7a487cf5eafe55f831b78af7d0350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Subject: Re: [manet] #9: Reserved value for AODVv2 SeqNum -- is it necessary
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 01:48:01 -0000

Hello folks,

This issue is trickier than most.  It turns out that specifying the 
operation
of intermediate RREP is easier if there is a reserved value for the AODVv2
Sequence Number field.  Other than making the code shorter by maybe
a dozen lines, and the inherent preferability of reducing the number of
special cases, I didn't see a strong push for deleting the specification for
the reserved value.

There are some other peripherally related discussion points on the
mailing list, but which were not keyed directly to issue #9.  I will
try to find them and post any new insights to the issue tracker. If there
aren't any objections, I think it would be expedient and appropriate to
keep the existing specification of the reserved SeqNum value (0).

If I understand the point below:
> It will be not necessary but may be used by router's processing checks,

I think it does not materially affect the outcome of the issue
resolution, but a more complete explanation would be interesting.

Regards,
Charlie P.


On 1/19/2013 1:27 PM, manet issue tracker wrote:
> #9: Reserved value for AODVv2 SeqNum -- is it necessary
>
>
> Comment (by abdussalambaryun@gmail.com):
>
>   Replying to [ticket:9 charliep@…]:
>   >
>   >
>   >  Whether or not to specify a reserved !SeqNum is not a trivial issue.
>   >  With recent revisions, it is now feasible to conduct a Route Discovery
>   >  cycle (RREQ / RREP) without need for indicating that a !SeqNum is
>   >  invalid, and there do not seem to be any other instances in the current
>   >  specification where a !SeqNum has to be reported as invalid.
>
>   It will be not necessary but may be used by router's processing checks,
>   >
>   >  If there is to be a reserved value for !SeqNum, it seems that 0 (zero)
>   >  is a good choice, so that rollover skips from 65535 to 1 bypassing the
>   >  reserved value of zero.
>   >
>
>   I agree
>


-- 
Regards,
Charlie P.


From charliep@computer.org  Mon Jun 24 20:05:59 2013
Return-Path: <charliep@computer.org>
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 9121B21E8053 for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 20:05:59 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Es74CUdfpIb for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 20:05:49 -0700 (PDT)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0013521E808B for <manet@ietf.org>; Mon, 24 Jun 2013 20:05:48 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1UrJZk-0000C1-9O for manet@ietf.org; Mon, 24 Jun 2013 23:05:48 -0400
Message-ID: <51C9090B.7020205@computer.org>
Date: Mon, 24 Jun 2013 20:05:47 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: manet@ietf.org
References: <061.c0c6fb135fcc7bb4ca27b05c03dc55ba@trac.tools.ietf.org>
In-Reply-To: <061.c0c6fb135fcc7bb4ca27b05c03dc55ba@trac.tools.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad863c0600440d671dd3d03112ffff783087350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Subject: Re: [manet] #12: INVALID_PREFIX_LENGTH -- is it useful?
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 03:06:00 -0000

Hello folks,

  INVALID_PREFIX_LENGTH has been written out of the specification
without any inconvenient side effects.  Unless there is any objection,
I think this issue can safely be closed.

Regards,
Charlie P.


On 1/9/2013 1:56 PM, manet issue tracker wrote:
> #12: INVALID_PREFIX_LENGTH -- is it useful?
>
>   In AODVv2, all routes have known prefix lengths, which
>   can be the same as the length of the IP address family of the route's
>   destination (in which case, they are known as "host routes").  Only
>   when there is no route, is it possible for a destination to have an
>   unknown prefix length.  In that case, the RERR message has only a
>   single destination address in its !AddrBlk, and since the !PrefixLength
>   is unknown, it is simply not included.
>
>   Since there are not any cases where INVALID_PREFIX_LENGTH has to
>   be assigned, it should be deleted from the specification.  For all
>   destinations that do not have explicitly known subnet prefixes, the
>   !PrefixLength must be reported to be the length of IP addresses for
>   the relevant address family (i.e., 4 for IPv4 or 16 for IPv6).
>


-- 
Regards,
Charlie P.


From trac+manet@trac.tools.ietf.org  Mon Jun 24 20:56:28 2013
Return-Path: <trac+manet@trac.tools.ietf.org>
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 0AF0E11E8105 for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 20:56:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2LyHxW01o8p for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 20:56:27 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0432E11E8103 for <manet@ietf.org>; Mon, 24 Jun 2013 20:56:26 -0700 (PDT)
Received: from localhost ([127.0.0.1]:42474 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+manet@trac.tools.ietf.org>) id 1UrKMg-0001cY-Nr; Tue, 25 Jun 2013 05:56:23 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "manet issue tracker" <trac+manet@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: charliep@computer.org
X-Trac-Project: manet
Date: Tue, 25 Jun 2013 03:56:22 -0000
X-URL: http://tools.ietf.org/manet/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/13#comment:1
Message-ID: <076.73ebb862d5ef7e579a6ffc9b8f320c6b@trac.tools.ietf.org>
References: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org>
X-Trac-Ticket-ID: 13
In-Reply-To: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org
X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: manet@ietf.org
Subject: Re: [manet] #13: Supporting monotonically nondecreasing but non-additive metrics
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: manet@ietf.org
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 03:56:28 -0000

#13: Supporting monotonically nondecreasing but non-additive metrics


Comment (by charliep@computer.org):

 On 1/10/2013 1:09 AM, Abdussalam Baryun wrote:

 I agree, that is important advantage of using metric and cost for AODVv2.

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

 On 1/10/2013 1:50 AM, Dearlove, Christopher (UK) wrote:

 Such a metric can, in general, lead to looping. Consider A, B, C, D, E in
 a ring with metric 2 on links A - B, B - C and C - D, and metric 1 on
 links D - E and E - A. Consider a packet from B routed to E. At B it is
 indifferent whether to go via A or C, so may pick C. At C it is
 indifferent whether to go via B or D, so may pick B.

 Of course in that case one can add the additional rule to not send back on
 link just arrived. But a more complicated case can send it in a longer
 loop. You could tie-break by number of hops, but that's actually a more
 complicated metric. However something like that is essential - consider a
 network all of whose links have metric 1. Whether that tie-breaker is, in
 general, sufficient is something not immediately obvious to me.

 And of course that's in general. A specific routing protocol may ensure
 that this doesn't happen. But that would also need work to prove.

 (The essential problem is that non-decreasing is not as good as
 increasing.)

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

 On 1/10/2013 2:30 AM, Abdussalam Baryun wrote:

 I don't think there is a route until they recieve RREP, the RREP is
 sent through one route. That packet you mentioned will go through the
 path of RREP. I don't think in AODVv2 the metric type and function
 allow loops.  comment in line;

 > Such a metric can, in general, lead to looping. Consider A, B, C, D, E
 in a
 > ring with metric 2 on links A - B, B - C and C - D, and metric 1 on
 links D
 > - E and E - A. Consider a packet from B routed to E. At B it is
 indifferent
 > whether to go via A or C, so may pick C. At C it is indifferent whether
 to
 > go via B or D, so may pick B.
 >

 At B the data packet will go through only one route which should be
 the one received RREP from. It will never receive a RREP from both
 neighbors A and C. At C it will never receive RREP from both nieghbors
 B and D.

 > Of course in that case one can add the additional rule to not send back
 on
 > link just arrived.

 AODV does not care about *links*, it care about *vectors*, I think
 they are different routings even if they may look into the same
 metric-type but different point of views.

 > (The essential problem is that non-decreasing is not as good as
 > increasing.)

 Is there a prove of that? I am not sure we can fix that, because it
 will always depend on why the engineer/applicant used that metric in
 the first place, if that engineer feels that point is true he/she
 should not use non-decreasing, but for some cases an engineer may like
 to use such metric so he/she can use it for a reason.

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

 On 1/10/2013 5:44 AM, Philippe Jacquet wrote:

 I agree with Chris, this may lead to loops if done careless.

 This metric is the min metric: you replace the + by the min operator, the
 cost of a route is the min bandwidth of the links on the route. The aim is
 to find the route with the max bandwidth, done via an adapted Dijkstra
 (also usable with OLSRv2).

 The problem with this metric is that it does not give an upperbound on the
 number of hops (indeed optimal routes may have unlimited hop count via
 loops), and in general it is better to use it with a lexicographical
 metric (bandwidth,hop-count) so that the optimal route will be the route
 with the min hop count among the routes with the largest bandwidth.

 Everything is computable via Dijkstra since (shortest path on links above
 bandwidth threshold).

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

-- 
-----------------------------------+------------------------------
 Reporter:  charliep@computer.org  |       Owner:  Charlie Perkins
     Type:  enhancement            |      Status:  new
 Priority:  minor                  |   Milestone:
Component:  dymo                   |     Version:
 Severity:  Active WG Document     |  Resolution:
 Keywords:  nondecreasing metrics  |
-----------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/13#comment:1>
manet <http://tools.ietf.org/manet/>


From trac+manet@trac.tools.ietf.org  Mon Jun 24 21:00:55 2013
Return-Path: <trac+manet@trac.tools.ietf.org>
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 BC61911E8108 for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 21:00:55 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIuzmbb2uKxW for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 21:00:55 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC9711E8107 for <manet@ietf.org>; Mon, 24 Jun 2013 21:00:55 -0700 (PDT)
Received: from localhost ([127.0.0.1]:43004 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+manet@trac.tools.ietf.org>) id 1UrKR4-0003ro-GV; Tue, 25 Jun 2013 06:00:54 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "manet issue tracker" <trac+manet@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: charliep@computer.org
X-Trac-Project: manet
Date: Tue, 25 Jun 2013 04:00:54 -0000
X-URL: http://tools.ietf.org/manet/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/13#comment:2
Message-ID: <076.fdf65bd609ab1b556dc0598000276232@trac.tools.ietf.org>
References: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org>
X-Trac-Ticket-ID: 13
In-Reply-To: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org
X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: manet@ietf.org
Subject: Re: [manet] #13: Supporting monotonically nondecreasing but non-additive metrics
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: manet@ietf.org
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 04:00:55 -0000

#13: Supporting monotonically nondecreasing but non-additive metrics


Comment (by charliep@computer.org):

 On 1/10/2013 8:58 AM, Abdussalam Baryun wrote:

 The AODVv2 insures the loop free as described in; In draft-dymo-25, page
 16

 or see the message on the list;
 http://www.ietf.org/mail-archive/web/manet/current/msg14316.html

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

 The abovementioned passages depend on the strict monotonicity of the
 metric, and will fail in general if the metric allows some links with zero
 cost (which can happen if the condition is relaxed to simply monotonic
 nondecreasing),

-- 
-----------------------------------+------------------------------
 Reporter:  charliep@computer.org  |       Owner:  Charlie Perkins
     Type:  enhancement            |      Status:  new
 Priority:  minor                  |   Milestone:
Component:  dymo                   |     Version:
 Severity:  Active WG Document     |  Resolution:
 Keywords:  nondecreasing metrics  |
-----------------------------------+------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/13#comment:2>
manet <http://tools.ietf.org/manet/>


From charliep@computer.org  Mon Jun 24 21:03:12 2013
Return-Path: <charliep@computer.org>
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 AEFBD21E8165 for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 21:03:12 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWIzbbYliaAl for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 21:03:08 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id F1F5521E812C for <manet@ietf.org>; Mon, 24 Jun 2013 21:03:07 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1UrKTB-0003RQ-94 for manet@ietf.org; Tue, 25 Jun 2013 00:03:05 -0400
Message-ID: <51C91677.2070500@computer.org>
Date: Mon, 24 Jun 2013 21:03:03 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: manet@ietf.org
References: <061.768213f7e4ba2b228e52bf8261395907@trac.tools.ietf.org> <076.fdf65bd609ab1b556dc0598000276232@trac.tools.ietf.org>
In-Reply-To: <076.fdf65bd609ab1b556dc0598000276232@trac.tools.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86e4fb2f8640237964e84695e463455531350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Subject: Re: [manet] #13: Supporting monotonically nondecreasing but non-additive metrics
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 04:03:12 -0000

Hello folks,

In the absence of a convincing use case for enabling nondecreasing metrics,
and in view of the problems to insure loop freedom, I think it is safe to
close this issue without enabling the feature.

Regards,
Charlie P.

On 6/24/2013 9:00 PM, manet issue tracker wrote:
> #13: Supporting monotonically nondecreasing but non-additive metrics
>
>
> Comment (by charliep@computer.org):
>
>   On 1/10/2013 8:58 AM, Abdussalam Baryun wrote:
>
>   The AODVv2 insures the loop free as described in; In draft-dymo-25, page
>   16
>
>   or see the message on the list;
>   http://www.ietf.org/mail-archive/web/manet/current/msg14316.html
>
>   -------------------------------------------------------------------------
>
>   The abovementioned passages depend on the strict monotonicity of the
>   metric, and will fail in general if the metric allows some links with zero
>   cost (which can happen if the condition is relaxed to simply monotonic
>   nondecreasing),
>


-- 
Regards,
Charlie P.


From trac+manet@trac.tools.ietf.org  Mon Jun 24 21:09:18 2013
Return-Path: <trac+manet@trac.tools.ietf.org>
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 B00D721E812C for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 21:09:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOI5zR+wjp72 for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 21:09:18 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 22D8E21E809B for <manet@ietf.org>; Mon, 24 Jun 2013 21:09:17 -0700 (PDT)
Received: from localhost ([127.0.0.1]:43651 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+manet@trac.tools.ietf.org>) id 1UrKZA-0008Op-8y; Tue, 25 Jun 2013 06:09:16 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "manet issue tracker" <trac+manet@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: charliep@computer.org
X-Trac-Project: manet
Date: Tue, 25 Jun 2013 04:09:16 -0000
X-URL: http://tools.ietf.org/manet/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/15#comment:1
Message-ID: <081.cc24f1550be16e62b8408b9fe1ec4ee2@trac.tools.ietf.org>
References: <066.51de40fe9c0e229a90ae823d91b65254@trac.tools.ietf.org>
X-Trac-Ticket-ID: 15
In-Reply-To: <066.51de40fe9c0e229a90ae823d91b65254@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org
X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: manet@ietf.org
Subject: Re: [manet] #15: Reactive Design Approach
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: manet@ietf.org
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 04:09:18 -0000

#15: Reactive Design Approach


Comment (by charliep@computer.org):

 I agree to leave gateway issues for a separate draft, and to concentrate
 on completing the reactive protocol without attempting any complete
 solution for the hybrid case.  A lot of thought has already gone into this
 matter.  I believe that a hybrid protocol is within reach, but that the
 necessary control signaling and parameter values are still a mysterious
 matter.

-- 
----------------------------------------+--------------------------------
 Reporter:  abdussalambaryun@gmail.com  |       Owner:  Abdussalam Baryun
     Type:  enhancement                 |      Status:  new
 Priority:  major                       |   Milestone:
Component:  dymo                        |     Version:
 Severity:  Active WG Document          |  Resolution:
 Keywords:  Design Approach             |
----------------------------------------+--------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/15#comment:1>
manet <http://tools.ietf.org/manet/>


From trac+manet@trac.tools.ietf.org  Mon Jun 24 21:11:52 2013
Return-Path: <trac+manet@trac.tools.ietf.org>
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 27A8621E805F for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 21:11:52 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48m6jL5QXkSW for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 21:11:51 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB1421F9A3F for <manet@ietf.org>; Mon, 24 Jun 2013 21:11:51 -0700 (PDT)
Received: from localhost ([127.0.0.1]:43794 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+manet@trac.tools.ietf.org>) id 1UrKbe-0003Bu-Ft; Tue, 25 Jun 2013 06:11:50 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "manet issue tracker" <trac+manet@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: charliep@computer.org
X-Trac-Project: manet
Date: Tue, 25 Jun 2013 04:11:50 -0000
X-URL: http://tools.ietf.org/manet/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/16#comment:1
Message-ID: <081.85e1af7d574f80935341e794286fd645@trac.tools.ietf.org>
References: <066.02811072057e3e608e2532e3a9c56d6d@trac.tools.ietf.org>
X-Trac-Ticket-ID: 16
In-Reply-To: <066.02811072057e3e608e2532e3a9c56d6d@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: charliep@computer.org, manet@ietf.org
X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: manet@ietf.org
Subject: Re: [manet] #16: The Reactive Protocol Duplicate Suppression Table
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: manet@ietf.org
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 04:11:52 -0000

#16: The Reactive Protocol Duplicate Suppression Table


Comment (by charliep@computer.org):

 The changes for proper handling of Duplicate Suppression have been made.
 Insofar as the base protocol specifies unicast RREP, the need for
 suppressing duplicate RREPs has been moved into the specification for that
 optional behavior.

-- 
----------------------------------------+--------------------------------
 Reporter:  abdussalambaryun@gmail.com  |       Owner:  Abdussalam Baryun
     Type:  enhancement                 |      Status:  new
 Priority:  major                       |   Milestone:
Component:  dymo                        |     Version:
 Severity:  Active WG Document          |  Resolution:
 Keywords:  Message suppression         |
----------------------------------------+--------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/16#comment:1>
manet <http://tools.ietf.org/manet/>


From charliep@computer.org  Mon Jun 24 21:20:34 2013
Return-Path: <charliep@computer.org>
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 D659211E810A for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 21:20:34 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuwS5nLqr48W for <manet@ietfa.amsl.com>; Mon, 24 Jun 2013 21:20:29 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id F020711E8109 for <manet@ietf.org>; Mon, 24 Jun 2013 21:20:28 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1UrKk0-0004RU-L1; Tue, 25 Jun 2013 00:20:28 -0400
Message-ID: <51C91A88.7080900@computer.org>
Date: Mon, 24 Jun 2013 21:20:24 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: manet@ietf.org
References: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> <081.203a92bb3f4f4d1dce29ad7af8d81cb5@trac.tools.ietf.org>
In-Reply-To: <081.203a92bb3f4f4d1dce29ad7af8d81cb5@trac.tools.ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86afbc096a0fd968cf103648321f19f623350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Subject: Re: [manet] #17: Proposed Reactive Protocols' Alternative Message Formats
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 04:20:35 -0000

Hello folks,

The changes have been made without any undue difficulty, and
no complaints have been brought to the attention of the mailing
list.  I think this issue can safely be closed now.

Regards,
Charlie P.


On 2/20/2013 11:11 AM, manet issue tracker wrote:
> #17: Proposed Reactive Protocols' Alternative Message Formats
>
> Changes (by charliep@computer.org):
>
>   * owner:  Abdussalam Baryun => charliep@computer.org
>   * status:  new => assigned
>
>
> Comment:
>
>   The new TLVs suggested by Henning Rogge have been incorporated into the
>   upcoming new revision for the AODVv2 specification.  I think it will
>   resolve this issue.  The Address TLVs have the effect of disambiguating
>   the roles of the addresses in the !AddrBlk; consequently the roles of the
>   addresses do not require positional significance otherwise.  After the
>   publication of the new revision, it should be determined whether this
>   issue can be closed.
>


-- 
Regards,
Charlie P.


From internet-drafts@ietf.org  Mon Jun 24 23:19:43 2013
Return-Path: <internet-drafts@ietf.org>
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 29D3C21E8064; Mon, 24 Jun 2013 23:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg1dgEfDuz41; Mon, 24 Jun 2013 23:19:42 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4EE21E808E; Mon, 24 Jun 2013 23:19:42 -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.51.p2
Message-ID: <20130625061942.27525.3569.idtracker@ietfa.amsl.com>
Date: Mon, 24 Jun 2013 23:19:42 -0700
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-12.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 06:19:43 -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	 Optimized Link St=
ate Routing Protocol version 2
	Author(s)       : Ulrich Herberg
                          Robert G. Cole
                          Thomas Heide Clausen
	Filename        : draft-ietf-manet-olsrv2-mib-12.txt
	Pages           : 87
	Date            : 2013-06-24

Abstract:
   This document defines the Management Information Base (MIB) module
   for configuring and managing the Optimized Link State Routing
   protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
   into configuration information, state information, performance
   information, and notifications.  This additional state and
   performance information is useful to troubleshoot problems and
   performance issues of the routing protocol.  Two levels of compliance
   allow this MIB module to be deployed on constrained routers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-12

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mib-12


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From iesg-secretary@ietf.org  Tue Jun 25 14:14:38 2013
Return-Path: <iesg-secretary@ietf.org>
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 C27F421E80E5; Tue, 25 Jun 2013 14:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.08
X-Spam-Level: 
X-Spam-Status: No, score=-102.08 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFx2b0ILX+uW; Tue, 25 Jun 2013 14:14:38 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6804A21E809F; Tue, 25 Jun 2013 14:14:37 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130625211437.29503.91501.idtracker@ietfa.amsl.com>
Date: Tue, 25 Jun 2013 14:14:37 -0700
Cc: manet chair <manet-chairs@tools.ietf.org>, manet mailing list <manet@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [manet] Protocol Action: 'Definition of Managed Objects for the Optimized	Link State Routing Protocol version 2' to Proposed Standard	(draft-ietf-manet-olsrv2-mib-12.txt)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jun 2013 21:14:38 -0000

The IESG has approved the following document:
- 'Definition of Managed Objects for the    Optimized Link State Routing
   Protocol version 2'
  (draft-ietf-manet-olsrv2-mib-12.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-olsrv2-mib/




Technical Summary

   This document defines the Management Information Base (MIB) module
   for configuring and managing the Optimized Link State Routing
   protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
   into state information, performance metrics, and notifications.  This
   additional state and performance information is useful to
   troubleshoot problems and performance issues of the routing protocol.
   Different levels of compliance allow implementers to use smaller
   subsets of all defined objects, allowing for this MIB module to be
   deployed on more constrained routers.

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.
  Early review by a MIB doctor was considered by the working group, however, the WG 
  consensus was that this review was unnecessary, as the WG contains sufficient 
  expertise to determine applicability of all objects, and correctness of the MIB. 

  A late MIB Doctor review was done by Randy Presuhn.

Personnel

  Stan Ratliff (sratliff@cisco.com) is the document shepherd.
  Adrian Farrel (Adrian@olddog.co.uk) is the Responsible AD.

From ulrich@herberg.name  Thu Jun 27 13:28:20 2013
Return-Path: <ulrich@herberg.name>
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 D2D6421F9F0F for <manet@ietfa.amsl.com>; Thu, 27 Jun 2013 13:28:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzds0yZ8E6E0 for <manet@ietfa.amsl.com>; Thu, 27 Jun 2013 13:28:20 -0700 (PDT)
Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9DA21F9CAB for <manet@ietf.org>; Thu, 27 Jun 2013 13:27:39 -0700 (PDT)
Received: by mail-ve0-f177.google.com with SMTP id cz10so1150613veb.36 for <manet@ietf.org>; Thu, 27 Jun 2013 13:27:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=A/Af/AdvzBCtFzmwA9/PQKZ8Wr+TnYxuAcmmA1eBNCU=; b=sqM9PAJEts7sQVR9vdetkxmS8bfpngPz2J9nV5ZHvBCRSDFuP+Wr0DwXTbSfWr1bHe bY+BwS4oasblgNXq5fQYJy+Gex16Wv10conUXzNBViEbzCnfWBr8Xe6ykeXUlRkywN/+ 28qwDquOCCXWcqYSj5J9hhbDco/45Ao4ypKUA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=A/Af/AdvzBCtFzmwA9/PQKZ8Wr+TnYxuAcmmA1eBNCU=; b=kOU59JR4WyiuPBoCBs2vyAjzTVZrNKswPb6nORKDFI/n8fYajLYUw+X1iNvpsCV7JS Wg1uxs8p+lA64aXNgNGvAs9V6DR3A0a++4CM3G57ONeOi83PY1Oet3Kue+dngg10mhT6 LVpDc9PQqUHU31OxvzbJhvzJKuRhS2pmPxdCcm0LpUxKnx7Yd2TDsppzkS+aJf3y09D4 LTuggCBqAsgwtp92+uT4B7CHj1N78kzSs7PP3ZMaXG5gVx2+H198/bE+QlZu5rVEFPu9 4qqWnIGMOJqUypPrdt7TdE04mKL5MVcAi9gBMRr6wlZg4+d70oJ7P0K3NspAwVSRj7y5 2rGw==
MIME-Version: 1.0
X-Received: by 10.58.15.193 with SMTP id z1mr4261832vec.40.1372364859376; Thu, 27 Jun 2013 13:27:39 -0700 (PDT)
Received: by 10.221.55.70 with HTTP; Thu, 27 Jun 2013 13:27:39 -0700 (PDT)
Date: Thu, 27 Jun 2013 13:27:39 -0700
Message-ID: <CAK=bVC_xXdaX2uVFADNR4pCbfYmEEa5Wt5hpq934mDvzkh5g-A@mail.gmail.com>
From: Ulrich Herberg <ulrich@herberg.name>
To: manet@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnd1QukGROtmtCXJqqCTGyisOiz7mCZXGif25ZdKJ86OiivjikaW0dAWyOJOJi7ImXuImq2
Subject: [manet] MANET session on Thursday, August 1, 3.20pm
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 20:28:21 -0000

FYI

On 6/27/13 1:25 PM, ""IETF Secretariat"" <agenda@ietf.org> wrote:

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

manet Session 1 (1:30:00)
    Thursday, Afternoon Session II 1520-1650
    Room Name: Charlottenburg 1
    ---------------------------------------------

From valerio.arnaboldi@iit.cnr.it  Sun Jun 30 02:45:50 2013
Return-Path: <valerio.arnaboldi@iit.cnr.it>
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 C469621F9DC1 for <manet@ietfa.amsl.com>; Sun, 30 Jun 2013 02:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.553
X-Spam-Level: *
X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[AWL=-0.928,  BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrorCvMvXF1i for <manet@ietfa.amsl.com>; Sun, 30 Jun 2013 02:45:46 -0700 (PDT)
Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) by ietfa.amsl.com (Postfix) with ESMTP id 33EF921F9D37 for <manet@ietf.org>; Sun, 30 Jun 2013 02:45:43 -0700 (PDT)
Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by mxbk.iit.cnr.it (Postfix) with ESMTPA id 38AFAC03FC for <manet@ietf.org>; Sun, 30 Jun 2013 11:45:40 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Valerio Arnaboldi<valerio.arnaboldi@iit.cnr.it>
To: manet@ietf.org
Message-Id: <20130630094544.33EF921F9D37@ietfa.amsl.com>
Date: Sun, 30 Jun 2013 02:45:43 -0700 (PDT)
Subject: [manet] IFIP/IEEE SustainIT 2013: Submission deadline for Industrial Track/Project Papers is July 5
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Jun 2013 09:45:50 -0000

-------------------------------------------------------------------	
*** Our apologies if you receive multiple copies of this e-mail ***
-------------------------------------------------------------------
	
                    CALL FOR INDUSTRIAL TRACK PAPERS

                     The Third IFIP Conference on
            Sustainable Internet and ICT for Sustainability
                            (SustainIT 2013)

           http://www.dicgim.unipa.it/networks/sustainit2013

                          October 30-31, 2013
                        Palermo, Sicily, Italy

- Technically sponsored by the IFIP TC6 WG 6.3 (Performance of
  Communication Systems)
- Technically co-sponsored by IEEE TCCC
  (Technical Committee on Computer Communications)
- In cooperation with IEEE TSGCC (Technical Subcommittee on Green
  Communications and Computing)
- Supported by EINS: The Network of Excellence in Internet Science

------------------------------------------------------------------------
SCOPE AND OVERVIEW
------------------------------------------------------------------------

SUSTAINIT 2013 will feature an industrial track providing a forum for researchers and developers from academia, industry, and government to interact and share latest research results achieved by national and international projects on the areas of Sustainable Internet and ICT for Sustainability. Towards this goal, SUSTAINIT seeks participations from all three entities. The industrial track offers the opportunity to present the latest findings by ongoing projects or the overview of recently approved projects. Industrial track paper submissions are
welcome in all aspects of Sustainable Internet and ICT for Sustainability, including algorithms, protocols, applications, hardware and tools, new research prototypes, testbeds, etc. Authors are asked to submit a paper of up to 5 pages (including figures, tables, and references) (one additional page is allowed upon a fee payment). The paper should highlight the main contributions and describe the details of the project, with a focus on the interaction with the audience and highlighting the environmental sustainability benefits either achieved or targeted. Please refer to the Submission Instructions below for more details.


IMPORTANT DATES
------------------------------------------------------------------------

- Industrial track paper submission deadline:         July 5, 2013
- Acceptance/Reject notification:         	      July 20, 2013
- Camera-ready version due:               	      August 5, 2013


INDUSTRIAL TRACK PAPER SUBMISSION
------------------------------------------------------------------------

Papers must be submitted electronically in PDF format through EDAS (http://edas.info/newPaper.php?c=14317). Manuscripts must be formatted in accordance with the IEEE Computer Society author guidelines (http://edas.info/newPaper.php?c=14317). Industrial track papers must be limited to 5 pages (one additional page is allowed upon a fee payment), single spacing, double column, and must strictly adhere to the template format. Detailed instructions for manuscript preparation and submission are available on the conference website
(http://www.dicgim.unipa.it/networks/sustainit2013/submission.html).

FOR MORE INFORMATION
------------------------------------------------------------------------
For questions about the industrial track paper submission and review process, please contact the SUSTAINIT 2013 Industrial Track Co-Chairs:

Maria Cristina Bueti, International Telecommunication Union (ITU) -
cristina (dot) bueti (at) itu (dot) int
Luca Valcarenghi, Scuola Superiore Sant'Anna, luca (dot) valcarenghi
(at) sssup (dot) it