From internet-drafts@ietf.org Wed May 1 09:15:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E5C21F99BD; Wed, 1 May 2013 09:15:22 -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=[AWL=0.000, 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 yhNM-ireQkbn; Wed, 1 May 2013 09:15:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DDD21F9A6F; Wed, 1 May 2013 09:15:20 -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.44.p4 Message-ID: <20130501161520.30885.16279.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2013 09:15:20 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-metrics-rationale-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 16:15:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group of t= he IETF. Title : Link Metrics for the Mobile Ad Hoc Network (MANET) Routi= ng Protocol OLSRv2 - Rationale Author(s) : Christopher Dearlove Thomas Heide Clausen Philippe Jacquet Filename : draft-ietf-manet-olsrv2-metrics-rationale-04.txt Pages : 30 Date : 2013-05-01 Abstract: OLSRv2 includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-metrics-rationale There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-metrics-rationale-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-metrics-rational= e-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abdussalambaryun@gmail.com Wed May 1 11:00:47 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D7A21F9ABC for ; Wed, 1 May 2013 11:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, 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 y+NvANaSqTPv for ; Wed, 1 May 2013 11:00:46 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E05FF21F9A85 for ; Wed, 1 May 2013 11:00:45 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id ma3so841062pbc.2 for ; Wed, 01 May 2013 11:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=h/pBTdzxSpbjsk0pJxk7jN5Q8AwuK4oHN0wbLBW1CIg=; b=WfqA7lnIFfJZrqlW3mmwB+fSRoI4wpvsZGTMWZ95bDQG+z90sYpBPX4avkCVfuHiZi DcwTksK7FBcjO3YDoJlQOIEZKhHGDO/RjGHsTyTzmEn9MyPeHyzlm2LbclYCEuIyv/cN iFMj1h8J2DIiuoPH/fN7WJiG/ESJU7nXe7GOvLtlSuosND5XoCO92ovcYPQJlD2XozBC gjxRWG3JPs0arncq4P1AcnNNsoXHav+/xelw1GxCBvcTuHM2+pWsXpjua+t4BEDWTZ71 dBsoZ7RwG5+B071n1hq55lYOwedB3RC7OvdaP24Y/FPLGRu+KgFi/mXxqYh8xLbKfQmq Gjow== MIME-Version: 1.0 X-Received: by 10.66.163.129 with SMTP id yi1mr6087695pab.93.1367431245623; Wed, 01 May 2013 11:00:45 -0700 (PDT) Received: by 10.68.230.35 with HTTP; Wed, 1 May 2013 11:00:45 -0700 (PDT) In-Reply-To: References: <000a01ce4436$3f94c440$bebe4cc0$@olddog.co.uk> Date: Wed, 1 May 2013 19:00:45 +0100 Message-ID: From: Abdussalam Baryun To: draft-ietf-manet-olsrv2-mib@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b86e74aa6790604dbabe5e9 Cc: manet Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 18:00:47 -0000 --047d7b86e74aa6790604dbabe5e9 Content-Type: text/plain; charset=ISO-8859-1 I didn't think it was out of place. However, I thought/hope no words deletes should occur after WGLC only if discussed (your delete was not discussed on list until my input). Do I have to review all versions updated after WGLC? some people may not, they may think it will be discussed to update I-Ds. AB On Tue, Apr 30, 2013 at 7:23 PM, Ulrich Herberg wrote: > AB, > > this sentence was out-of-place in section 9 and not related to > security considerations. > > Best regards > Ulrich > > On Tue, Apr 30, 2013 at 10:58 AM, Abdussalam Baryun > wrote: > > Not sure in new version -07 why deleted some words/statement in section > 9. > > > > AB > > > > > > > > On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg > wrote: > >> > >> Adrian, > >> > >> yes, that was my intention...but sometimes, good intentions are not > enough > >> ;-) > >> > >> I have submitted a new revision with the one-word change that Benoit > >> requested. > >> > >> Best regards > >> Ulrich > >> > >> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel > >> wrote: > >> > Hi Ulrich, > >> > > >> > Did you intend to post a new revision to make this change? > >> > > >> > Thanks, > >> > Adrian > >> > > >> >> -----Original Message----- > >> >> From: Ulrich Herberg [mailto:ulrich@herberg.name] > >> >> Sent: 15 April 2013 21:11 > >> >> To: Benoit Claise > >> >> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Farrel; > >> > pm-dir@ietf.org; > >> >> manet@ietf.org > >> >> Subject: Re: [manet] performance metrics directorate review of > >> >> draft-ietf- > >> >> manet-olsrv2-mib-06 > >> >> > >> >> Benoit, > >> >> > >> >> thank you very much for this review. I agree that using the term > >> >> "performance information" instead of "performance metrics" is a good > >> >> idea. We will make the change. > >> >> > >> >> Best regards > >> >> Ulrich > >> >> > >> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise > >> >> wrote: > >> >> > Dear all, > >> >> > > >> >> > I reviewed > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, > >> >> > from a > >> >> > performance metric directorate point of view. > >> >> > > >> >> > This draft doesn't contain any reference to RFC6390, but contains > >> >> > "performance metric". Hence this review was triggered. For details > >> >> > about the > >> >> > directorate, see > >> >> > http://www.ietf.org/iesg/directorate/performance-metrics.html > >> >> > > >> >> > > >> >> > Definition of Managed Objects for the Optimized Link State Routing > >> >> > Protocol version 2 > >> >> > > >> >> > 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 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. > >> >> > > >> >> > > >> >> > Basically, all performance metrics come from this table: > >> >> > > >> >> > o olsrv2InterfacePerfTable - records performance counters for > >> >> > each > >> >> > active OLSRv2 interface on this device. selected path to each > >> >> > destination for which any such path is known. This table has > >> >> > AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed > >> >> > via > >> >> > nhdpIfIndex from the NHDP-MIB. > >> >> > > >> >> > NHDP-MIB is RFC 6779: > >> >> > NhdpInterfacePerfEntry ::= > >> >> > SEQUENCE { > >> >> > nhdpIfHelloMessageXmits > >> >> > Counter32, > >> >> > nhdpIfHelloMessageRecvd > >> >> > Counter32, > >> >> > nhdpIfHelloMessageXmitAccumulatedSize > >> >> > Counter64, > >> >> > nhdpIfHelloMessageRecvdAccumulatedSize > >> >> > Counter64, > >> >> > nhdpIfHelloMessageTriggeredXmits > >> >> > Counter32, > >> >> > nhdpIfHelloMessagePeriodicXmits > >> >> > Counter32, > >> >> > nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount > >> >> > Counter32, > >> >> > nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount > >> >> > Counter32, > >> >> > nhdpIfHelloMessageXmitAccumulatedLostNeighborCount > >> >> > Counter32 > >> >> > } > >> >> > > >> >> > > >> >> > This draft contains similar objects in olsrv2InterfacePerfTable : > >> >> > > >> >> > Olsrv2InterfacePerfEntry ::= > >> >> > SEQUENCE { > >> >> > olsrv2IfTcMessageXmits > >> >> > Counter32, > >> >> > olsrv2IfTcMessageRecvd > >> >> > Counter32, > >> >> > olsrv2IfTcMessageXmitAccumulatedSize > >> >> > Counter64, > >> >> > olsrv2IfTcMessageRecvdAccumulatedSize > >> >> > Counter64, > >> >> > olsrv2IfTcMessageTriggeredXmits > >> >> > Counter32, > >> >> > olsrv2IfTcMessagePeriodicXmits > >> >> > Counter32, > >> >> > olsrv2IfTcMessageForwardedXmits > >> >> > Counter32, > >> >> > olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount > >> >> > Counter32 > >> >> > } > >> >> > > >> >> > > >> >> > Personally, I don't believe that those objects should be subject to > >> >> > the RFC > >> >> > 6390 template definition. (Performance Metric Definition Template, > >> >> > section > >> >> > 5.4.4, RFC 6390). > >> >> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was > >> >> > not > >> >> > subject to it > >> >> > Second reason: these objects are not really performance metrics, > but > >> >> > mainly > >> >> > basic monitoring objects. > >> >> > > >> >> > Since RFC 6779 uses the term performance information (in the > >> >> > abstract), I > >> >> > would propose that draft-ietf-manet-olsrv2-mib also uses this term, > >> >> > and not > >> >> > the "performance metric". That would avoid some confusion. However, > >> >> keeping > >> >> > the olsrv2InterfacePerfTable OID name is perfectly fine, for > >> >> > consistency > >> >> > reason with RFC 6779. > >> >> > > >> >> > Regards, Benoit > >> >> > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > manet mailing list > >> >> > manet@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/manet > >> >> > > >> > > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www.ietf.org/mailman/listinfo/manet > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > --047d7b86e74aa6790604dbabe5e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I didn't think it was out of place. However, I th= ought/hope=A0no words deletes should occur after WGLC only if discussed (yo= ur delete was not discussed on list=A0until my input). Do I have to review = all versions updated after WGLC? some people may not, they may=A0think it w= ill be discussed to update I-Ds.
=A0
AB
=A0
<= br>
On Tue, Apr 30, 2013 at 7:23 PM, Ulrich H= erberg <ulrich@herberg.name> wrote:
AB,

this sentence was out-of-place in section 9 and not related to
security considerations.

Best regards
Ulrich

On Tue, Apr 30, 2013 at 10:58 AM, Abdussalam Baryun
<abdussalambaryun@gmail.co= m> wrote:
> Not sure in new version -07 why deleted some words/statement in sectio= n 9.
>
> AB
>
>
>
> On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
>>
>> Adrian,
>>
>> yes, that was my intention...but sometimes, good intentions are no= t enough
>> ;-)
>>
>> I have submitted a new revision with the one-word change that Beno= it
>> requested.
>>
>> Best regards
>> Ulrich
>>
>> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel <adrian@olddog.co.uk>
>> wrote:
>> > Hi Ulrich,
>> >
>> > Did you intend to post a new revision to make this change? >> >
>> > Thanks,
>> > Adrian
>> >
>> >> -----Original Message-----
>> >> From: Ulrich Herberg [mailto:ulrich@herberg.name]
>> >> Sent: 15 April 2013 21:11
>> >> To: Benoit Claise
>> >> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Farrel;
>> > pm-dir@ietf.org;
>> >> manet@ietf.org
>> >> Subject: Re: [manet] performance metrics directorate revi= ew of
>> >> draft-ietf-
>> >> manet-olsrv2-mib-06
>> >>
>> >> Benoit,
>> >>
>> >> thank you very much for this review. I agree that using t= he term
>> >> "performance information" instead of "perf= ormance metrics" is a good
>> >> idea. We will make the change.
>> >>
>> >> Best regards
>> >> Ulrich
>> >>
>> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <bclaise@cisco.com>
>> >> wrote:
>> >> > Dear all,
>> >> >
>> >> > I reviewed http://tools.ietf.org/html/d= raft-ietf-manet-olsrv2-mib-06,
>> >> > from a
>> >> > performance metric directorate point of view.
>> >> >
>> >> > This draft doesn't contain any reference to RFC6= 390, but contains
>> >> > "performance metric". Hence this review wa= s triggered. For details
>> >> > about the
>> >> > directorate, see
>> >> > http://www.ietf.org/iesg/directorat= e/performance-metrics.html
>> >> >
>> >> >
>> >> > Definition of Managed Objects for the =A0Optimized L= ink State Routing
>> >> > Protocol version 2
>> >> >
>> >> > Abstract
>> >> >
>> >> > =A0 =A0This document defines the Management Informat= ion Base (MIB) module
>> >> > =A0 =A0for configuring and managing the Optimized Li= nk State Routing
>> >> > =A0 =A0protocol version 2 (OLSRv2). =A0The OLSRv2-MI= B module is structured
>> >> > =A0 =A0into state information, performance metrics, = and notifications.
>> >> > This
>> >> > =A0 =A0additional state and performance information = is useful to
>> >> > =A0 =A0troubleshoot problems and performance issues = of the routing
>> >> > protocol.
>> >> > =A0 =A0Different levels of compliance allow implemen= ters to use smaller
>> >> > =A0 =A0subsets of all defined objects, allowing for = this MIB module to be
>> >> > =A0 =A0deployed on more constrained routers.
>> >> >
>> >> >
>> >> > Basically, all performance metrics come from this ta= ble:
>> >> >
>> >> > =A0 =A0o =A0olsrv2InterfacePerfTable - records perfo= rmance counters for
>> >> > each
>> >> > =A0 =A0 =A0 active OLSRv2 interface on this device. = selected path to each
>> >> > =A0 =A0 =A0 destination for which any such path is k= nown. =A0This table has
>> >> > =A0 =A0 =A0 AUGMENTS { nhdpInterfacePerfEntry } and = as such it is indexed
>> >> > via
>> >> > =A0 =A0 =A0 nhdpIfIndex from the NHDP-MIB.
>> >> >
>> >> > NHDP-MIB is RFC 6779:
>> >> > =A0 =A0NhdpInterfacePerfEntry ::=3D
>> >> > =A0 =A0 =A0 SEQUENCE {
>> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmits
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageRecvd
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAccumulated= Size
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter64,
>> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageRecvdAccumulate= dSize
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter64,
>> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageTriggeredXmits<= br> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessagePeriodicXmits >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAccumulated= SymmetricNeighborCount
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAccumulated= HeardNeighborCount
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAccumulated= LostNeighborCount
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32
>> >> > =A0 =A0 =A0 }
>> >> >
>> >> >
>> >> > This draft contains similar objects in olsrv2Interfa= cePerfTable :
>> >> >
>> >> > =A0 =A0 Olsrv2InterfacePerfEntry ::=3D
>> >> > =A0 =A0 =A0 =A0SEQUENCE {
>> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageXmits
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
>> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageRecvd
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
>> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageXmitAccumulated= Size
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter64,
>> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageRecvdAccumulate= dSize
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter64,
>> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageTriggeredXmits<= br> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
>> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessagePeriodicXmits >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
>> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageForwardedXmits<= br> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
>> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageXmitAccumulated= MPRSelectorCount
>> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32
>> >> > =A0 =A0 =A0 =A0}
>> >> >
>> >> >
>> >> > Personally, I don't believe that those objects s= hould be subject to
>> >> > the RFC
>> >> > 6390 template definition. (Performance Metric Defini= tion Template,
>> >> > section
>> >> > 5.4.4, RFC 6390).
>> >> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB = [RFC 6779] was
>> >> > not
>> >> > subject to it
>> >> > Second reason: these objects are not really performa= nce metrics, but
>> >> > mainly
>> >> > basic monitoring objects.
>> >> >
>> >> > Since RFC 6779 uses the term performance information= (in the
>> >> > abstract), I
>> >> > would propose that draft-ietf-manet-olsrv2-mib also = uses this term,
>> >> > and not
>> >> > the "performance metric". That would avoid= some confusion. However,
>> >> keeping
>> >> > the olsrv2InterfacePerfTable OID name is perfectly f= ine, for
>> >> > consistency
>> >> > reason with RFC 6779.
>> >> >
>> >> > Regards, Benoit
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > manet mailing list
>> >> > manet@ietf.org=
>> >> > https://www.ietf.org/mailman/listinfo/manet
>> >> >
>> >
>> _______________________________________________
>> manet mailing list
>> manet@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

--047d7b86e74aa6790604dbabe5e9-- From iesg-secretary@ietf.org Wed May 1 11:53:22 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B54D21F99BF; Wed, 1 May 2013 11:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, 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 H8bQ6Eb4luk9; Wed, 1 May 2013 11:53:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA6521F991D; Wed, 1 May 2013 11:53:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130501185303.16952.32868.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2013 11:53:03 -0700 Cc: manet chair , manet mailing list , RFC Editor Subject: [manet] Document Action: 'Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale' to Informational RFC (draft-ietf-manet-olsrv2-metrics-rationale-04.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 18:53:22 -0000 The IESG has approved the following document: - 'Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale' (draft-ietf-manet-olsrv2-metrics-rationale-04.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-olsrv2-metrics-rationale/ Technical Summary OLSRv2 includes the ablity to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for and design considerations behind how link metrics were included in OLSRv2. Working Group Summary o OLSRv2 was first submitted as an individual draft in July 2005 (draft-clausen-manet-olsrv2-00), and accepted as a Working Group document in August 2005. o OLSRv2 is in the process of approval as a Proposed Standard. o A key difference between RFC3626 and OLSRv2 is the introduction of support for link metrics. An individual draft (draft-dearlove-olsrv2- metrics-00) was submitted in 2007, discussing the design options, culminating in 2010 with draft-dearlove-olsrv2-metrics-05 documenting Working Group consensus on this matter. Metrics support was, then, folded into OLSRv2. o This document retains and documents the design rationale, and important decisions for how metrics were integrated into OLSRv2. Thus, this document reflects WG consensus built up during the evolution of OLSRv2, and records the consensus view that lies behind OLSRv2. Document Quality There is a number of independent implementations of OLSRv2, as was indicated in the write-up for that I-D. This document does not propose a protocol, or mandate protocol behavior, but rather presents part of the design rationale for OLSRv2. Personnel Stan Ratliff (sratliff@cisco.com) is the Document Shepherd. Adrian Farrel (adrian@olddog.co.uk) is the Responsible Area Director RFC Editor Note Section 1 paras 4 and 5 Please move the explanation of TC from para 5 to para4 From ulrich@herberg.name Wed May 1 12:01:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8285221F9A07 for ; Wed, 1 May 2013 12:01:21 -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 D8WIiTb7tMqN for ; Wed, 1 May 2013 12:01:20 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id DF80F21F9B44 for ; Wed, 1 May 2013 12:01:15 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id pb11so1431221veb.39 for ; Wed, 01 May 2013 12:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=J3vf7gy5pBrzYOr1F9GvG+DMHYoGkFCV39Z1nMHVSbw=; b=qMXRm6/DS/177XwRzZZM1uzIDvXQEfkwcYPRqE8AP/lp9Yrd+Mu7879tb7nSXrC2+C Ge1cOsuY+tlgDsvUBnoq0d6I0XTdZXFzXsPr6YDtcB7PF5B4nJMHwG/4wKV0HjNtFaXc KZPvnVj/Pm75vLEAi0h3l86D91YsOmqPirb94= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=J3vf7gy5pBrzYOr1F9GvG+DMHYoGkFCV39Z1nMHVSbw=; b=EiQ3nV77TLvo2IZAP4H7nRp6uM6yF76rM6UgXrNw7xOAIfHku+0KYtwj3QP12xeAhn NZ0LO+c+JAxEz9SF+cj8+et8lrL0paAzXyg7zUYrtTm/K50aXu6R2nRPB3gtmCZ9ughe QHS+k/mbH4RJOygwB/2xo0akI2f3ZUMUjkayXE9sbeJK6uWjChxiIaLIxOmngi+ZQSbX BrvqmlqpYM5sMZxL3n98+TZvn4h5W46d0yxevL0VRXMJsifPZ7VLVrFm6HwssrRniIf5 4HVV/CHiI8W7V8CCijDG2WcnCrhM5nMh2s4SFx5utwf08Nw69mlEWKk4EoMgVrlYOS4o ks+w== MIME-Version: 1.0 X-Received: by 10.220.42.7 with SMTP id q7mr1163584vce.69.1367434874780; Wed, 01 May 2013 12:01:14 -0700 (PDT) Received: by 10.220.13.195 with HTTP; Wed, 1 May 2013 12:01:14 -0700 (PDT) In-Reply-To: <20130501185303.16952.32868.idtracker@ietfa.amsl.com> References: <20130501185303.16952.32868.idtracker@ietfa.amsl.com> Date: Wed, 1 May 2013 12:01:14 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQntpTD0W8LilBop/dFH3RLtvW2LGqSf5WAX1/qrB+bKnN5v2qKbNSuQmBsVkYcAbX70SCuR Subject: Re: [manet] Document Action: 'Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale' to Informational RFC (draft-ietf-manet-olsrv2-metrics-rationale-04.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 19:01:21 -0000 Very good job! Thank you Ulrich On Wed, May 1, 2013 at 11:53 AM, The IESG wrote: > The IESG has approved the following document: > - 'Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol > OLSRv2 - Rationale' > (draft-ietf-manet-olsrv2-metrics-rationale-04.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-olsrv2-metrics-rationale/ > > > > > Technical Summary > > OLSRv2 includes the ablity to assign metrics to links and to use > those metrics to allow routing by other than minimum hop count > routes. This document provides a historic record of the rationale > for and design considerations behind how link metrics were included > in OLSRv2. > > Working Group Summary > > o OLSRv2 was first submitted as an individual draft in July 2005 > (draft-clausen-manet-olsrv2-00), and accepted as a Working Group > document in August 2005. > > o OLSRv2 is in the process of approval as a Proposed Standard. > > o A key difference between RFC3626 and OLSRv2 is the introduction > of support for link metrics. An individual draft (draft-dearlove-olsrv2- > metrics-00) was submitted in 2007, discussing the design options, > culminating in 2010 with draft-dearlove-olsrv2-metrics-05 > documenting Working Group consensus on this matter. Metrics > support was, then, folded into OLSRv2. > > o This document retains and documents the design rationale, and > important decisions for how metrics were integrated into OLSRv2. > > Thus, this document reflects WG consensus built up during the evolution > of OLSRv2, and records the consensus view that lies behind OLSRv2. > > Document Quality > > There is a number of independent implementations of OLSRv2, as was > indicated in the write-up for that I-D. > > This document does not propose a protocol, or mandate protocol behavior, > but rather presents part of the design rationale for OLSRv2. > > Personnel > > Stan Ratliff (sratliff@cisco.com) is the Document Shepherd. > Adrian Farrel (adrian@olddog.co.uk) is the Responsible Area Director > > RFC Editor Note > > Section 1 paras 4 and 5 > Please move the explanation of TC from para 5 to para4 From vignesh@atc.tcs.com Thu May 2 03:52:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7B721F99AE for ; Thu, 2 May 2013 03:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] 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 JKhHvWklI4SL for ; Thu, 2 May 2013 03:52:21 -0700 (PDT) Received: from atcmail.atc.tcs.com (atcmail.atc.tcs.com [203.200.212.145]) by ietfa.amsl.com (Postfix) with ESMTP id E936621F994D for ; Thu, 2 May 2013 03:52:18 -0700 (PDT) Received: from [172.20.89.63] ([172.20.89.63]) (authenticated bits=0) by atcmail.atc.tcs.com (8.14.4/8.14.4) with ESMTP id r42AqEex025724 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 2 May 2013 16:22:14 +0530 Message-ID: <5182455D.805@atc.tcs.com> Date: Thu, 02 May 2013 16:22:13 +0530 From: Vigneswaran R User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: manet@ietf.org References: <20130325172118.14053.51653.idtracker@ietfa.amsl.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C1006DA31@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C1006DA31@xmb-aln-x03.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 10:52:42 -0000 Hello, Below are some minor things I noticed while going through the dlep-draft-04, id> 9. DLEP Data Items one of the Signal TLVs, documented in section [INSERT REFERENCE HERE]. suggestion> replace [INSERT REFERENCE HERE] with 10.1. id> 9.9 Current Data Rate (Transmit) The Current Data Rate Receive (CDRT) TLV is used in Neighbor Up, suggestion> change "Current Data Rate Receive" into "Current Data Rate Transmit" Regards, Vignesh On 03/25/2013 10:53 PM, Stan Ratliff (sratliff) wrote: > WG - > > As promised, DLEP-04. As I mentioned in Orlando, the changes are: > 1. Went back to modem-initiated discovery > 2. Inbound and outbound metrics > > I'm sure something got missed, so your review & comments are appreciated. > > Regards, > Stan > > > On Mar 25, 2013, at 1:21 PM, > wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. >> >> Title : Dynamic Link Exchange Protocol (DLEP) >> Author(s) : Stan Ratliff >> Bo Berry >> Greg Harrison >> Darryl Satterwhite >> Shawn Jury >> Filename : draft-ietf-manet-dlep-04.txt >> Pages : 48 >> Date : 2013-03-25 >> >> Abstract: >> When routing devices rely on modems to effect communications over >> wireless links, they need timely and accurate knowledge of the >> characteristics of the link (speed, state, etc.) in order to make >> forwarding decisions. In mobile or other environments where these >> characteristics change frequently, manual configurations or the >> inference of state through routing or transport protocols does not >> allow the router to make the best decisions. A bidirectional, event- >> driven communication channel between the router and the modem is >> necessary. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-manet-dlep-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From ulrich@herberg.name Thu May 2 07:34:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8ECD21F8696 for ; Thu, 2 May 2013 07:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, 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 GGkKsfoqy8kQ for ; Thu, 2 May 2013 07:34:03 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC3E21F842A for ; Thu, 2 May 2013 07:34:03 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so505367vbb.37 for ; Thu, 02 May 2013 07:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j6FWezWAvVn/RCo2amYPfn13Zu5hnY/HP4rsIjkK2+0=; b=jRLnwNj8sqz20Yew6PZPZlt2Qdb+JIFBRjSsP6AsaIT/UNXpvpSDDTzaNqaEAqhLH6 04wB/Y/M/cIV69e3WCH1D16kGoJsy/kvp0C7WFoSxsRKr+r5pusCDDmodbw1brGYXXeb L2ZSw8N/y6fPPSxw57h1b5Z8ylafV0bjDscgU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=j6FWezWAvVn/RCo2amYPfn13Zu5hnY/HP4rsIjkK2+0=; b=cjxlKpFmmylEZO6xk71TjYsOS7CgMPVwaMvVwRTqopIis0k1DfYhyYYMmEVpiC3HT0 qu7iSnzgejqlAIwCuXU6RBXEkDp7Pgjm9nLo8QX22O3dmoZqHSFwRvOO7rUb+OodyDrP 2/SYweXplbW5/Czgf2McebN7uP6szEzg8k3LJ+tTxf9c2tuLXPeRUpuzXjTjbDlHkSMA g5VCW5mCmA6HMPct3Q/F4/fBuUjxzfQXVa7iAuN3eUGcSwHmyoWZ7NS2VpG4T015mTHD ejAA8nu5/IT61Onz7O+E8DmzbTVmKmHa+sDCfUYnzzK0YQMEbkcCsAoHnXrGzGgbEIhI Ra4w== MIME-Version: 1.0 X-Received: by 10.59.6.101 with SMTP id ct5mr2263549ved.8.1367505242954; Thu, 02 May 2013 07:34:02 -0700 (PDT) Received: by 10.220.13.195 with HTTP; Thu, 2 May 2013 07:34:02 -0700 (PDT) In-Reply-To: References: <000a01ce4436$3f94c440$bebe4cc0$@olddog.co.uk> Date: Thu, 2 May 2013 07:34:02 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun , adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmkabM/u8xh5uym0KjWWxyurhfk1tEzRmx4l06SPBk/WxCVCuhKlGF89YalXrazj8vv2ts3 Cc: manet , draft-ietf-manet-olsrv2-mib@tools.ietf.org Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 14:34:05 -0000 AB, I let Adrian reply if he thinks the changes are significant enough to warrant a new WGLC. I think this is not the case. The sentence was probably a copy&paste mistake and does not provide any value in the Security Considerations section. Best regards Ulrich On Wed, May 1, 2013 at 11:00 AM, Abdussalam Baryun wrote: > I didn't think it was out of place. However, I thought/hope no words deletes > should occur after WGLC only if discussed (your delete was not discussed on > list until my input). Do I have to review all versions updated after WGLC? > some people may not, they may think it will be discussed to update I-Ds. > > AB > > > > On Tue, Apr 30, 2013 at 7:23 PM, Ulrich Herberg wrote: >> >> AB, >> >> this sentence was out-of-place in section 9 and not related to >> security considerations. >> >> Best regards >> Ulrich >> >> On Tue, Apr 30, 2013 at 10:58 AM, Abdussalam Baryun >> wrote: >> > Not sure in new version -07 why deleted some words/statement in section >> > 9. >> > >> > AB >> > >> > >> > >> > On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg >> > wrote: >> >> >> >> Adrian, >> >> >> >> yes, that was my intention...but sometimes, good intentions are not >> >> enough >> >> ;-) >> >> >> >> I have submitted a new revision with the one-word change that Benoit >> >> requested. >> >> >> >> Best regards >> >> Ulrich >> >> >> >> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel >> >> wrote: >> >> > Hi Ulrich, >> >> > >> >> > Did you intend to post a new revision to make this change? >> >> > >> >> > Thanks, >> >> > Adrian >> >> > >> >> >> -----Original Message----- >> >> >> From: Ulrich Herberg [mailto:ulrich@herberg.name] >> >> >> Sent: 15 April 2013 21:11 >> >> >> To: Benoit Claise >> >> >> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Farrel; >> >> > pm-dir@ietf.org; >> >> >> manet@ietf.org >> >> >> Subject: Re: [manet] performance metrics directorate review of >> >> >> draft-ietf- >> >> >> manet-olsrv2-mib-06 >> >> >> >> >> >> Benoit, >> >> >> >> >> >> thank you very much for this review. I agree that using the term >> >> >> "performance information" instead of "performance metrics" is a good >> >> >> idea. We will make the change. >> >> >> >> >> >> Best regards >> >> >> Ulrich >> >> >> >> >> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise >> >> >> wrote: >> >> >> > Dear all, >> >> >> > >> >> >> > I reviewed >> >> >> > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, >> >> >> > from a >> >> >> > performance metric directorate point of view. >> >> >> > >> >> >> > This draft doesn't contain any reference to RFC6390, but contains >> >> >> > "performance metric". Hence this review was triggered. For details >> >> >> > about the >> >> >> > directorate, see >> >> >> > http://www.ietf.org/iesg/directorate/performance-metrics.html >> >> >> > >> >> >> > >> >> >> > Definition of Managed Objects for the Optimized Link State >> >> >> > Routing >> >> >> > Protocol version 2 >> >> >> > >> >> >> > 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 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. >> >> >> > >> >> >> > >> >> >> > Basically, all performance metrics come from this table: >> >> >> > >> >> >> > o olsrv2InterfacePerfTable - records performance counters for >> >> >> > each >> >> >> > active OLSRv2 interface on this device. selected path to >> >> >> > each >> >> >> > destination for which any such path is known. This table >> >> >> > has >> >> >> > AUGMENTS { nhdpInterfacePerfEntry } and as such it is >> >> >> > indexed >> >> >> > via >> >> >> > nhdpIfIndex from the NHDP-MIB. >> >> >> > >> >> >> > NHDP-MIB is RFC 6779: >> >> >> > NhdpInterfacePerfEntry ::= >> >> >> > SEQUENCE { >> >> >> > nhdpIfHelloMessageXmits >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageRecvd >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedSize >> >> >> > Counter64, >> >> >> > nhdpIfHelloMessageRecvdAccumulatedSize >> >> >> > Counter64, >> >> >> > nhdpIfHelloMessageTriggeredXmits >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessagePeriodicXmits >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedLostNeighborCount >> >> >> > Counter32 >> >> >> > } >> >> >> > >> >> >> > >> >> >> > This draft contains similar objects in olsrv2InterfacePerfTable : >> >> >> > >> >> >> > Olsrv2InterfacePerfEntry ::= >> >> >> > SEQUENCE { >> >> >> > olsrv2IfTcMessageXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageRecvd >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageXmitAccumulatedSize >> >> >> > Counter64, >> >> >> > olsrv2IfTcMessageRecvdAccumulatedSize >> >> >> > Counter64, >> >> >> > olsrv2IfTcMessageTriggeredXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessagePeriodicXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageForwardedXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount >> >> >> > Counter32 >> >> >> > } >> >> >> > >> >> >> > >> >> >> > Personally, I don't believe that those objects should be subject >> >> >> > to >> >> >> > the RFC >> >> >> > 6390 template definition. (Performance Metric Definition Template, >> >> >> > section >> >> >> > 5.4.4, RFC 6390). >> >> >> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was >> >> >> > not >> >> >> > subject to it >> >> >> > Second reason: these objects are not really performance metrics, >> >> >> > but >> >> >> > mainly >> >> >> > basic monitoring objects. >> >> >> > >> >> >> > Since RFC 6779 uses the term performance information (in the >> >> >> > abstract), I >> >> >> > would propose that draft-ietf-manet-olsrv2-mib also uses this >> >> >> > term, >> >> >> > and not >> >> >> > the "performance metric". That would avoid some confusion. >> >> >> > However, >> >> >> keeping >> >> >> > the olsrv2InterfacePerfTable OID name is perfectly fine, for >> >> >> > consistency >> >> >> > reason with RFC 6779. >> >> >> > >> >> >> > Regards, Benoit >> >> >> > >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > manet mailing list >> >> >> > manet@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/manet >> >> >> > >> >> > >> >> _______________________________________________ >> >> manet mailing list >> >> manet@ietf.org >> >> https://www.ietf.org/mailman/listinfo/manet >> > >> > >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >> > > > From abdussalambaryun@gmail.com Fri May 3 03:02:30 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202EB21F958D for ; Fri, 3 May 2013 03:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=1.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-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 yW5qD5mpt5Bp for ; Fri, 3 May 2013 03:02:18 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD3921F8477 for ; Fri, 3 May 2013 03:02:18 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rl6so855598pac.14 for ; Fri, 03 May 2013 03:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8iiJu3OV3F01zZHkgyIi8KMOlnnwt3DE4UxGZTMtaFU=; b=t9urdpjB9/nXuNCDm4PixZujSxwnJMXGisgFwB6t2A3brfGtqhWmbeSwJWQa7/kfyn +jRgs0TR2mVkxaia8ISL4NvXpE7iofSvf/BgkWu2ig5OA3W8ojwe5KMesP24tti/I33W RqRz2+G/v4eve+I/AgWiUPcVkuq1Ob19gyMdpnTBYuqwR0VwRzGk2mFaiT4gPhDrX6DB Uu/wqoGDzvbS9VGOmqb3VXWgtclGLDNlIy38TtTNIFoZahU/skOKs/Hm7iwnfeI7WmrU 0WU3l8JYE1OSuyN9ajqcI3MNgb+exNnXzDui/i95WCyUEvyN9ji4zLtunYhwd0+hSuB/ R+3A== MIME-Version: 1.0 X-Received: by 10.66.224.73 with SMTP id ra9mr3590298pac.163.1367575337755; Fri, 03 May 2013 03:02:17 -0700 (PDT) Received: by 10.68.230.35 with HTTP; Fri, 3 May 2013 03:02:17 -0700 (PDT) In-Reply-To: References: <000a01ce4436$3f94c440$bebe4cc0$@olddog.co.uk> Date: Fri, 3 May 2013 11:02:17 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=e89a8ff24c8f35ed9804dbcd7299 Cc: manet , draft-ietf-manet-olsrv2-mib@tools.ietf.org Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 10:02:30 -0000 --e89a8ff24c8f35ed9804dbcd7299 Content-Type: text/plain; charset=ISO-8859-1 Hi Ulrich, Section 9 is not titled security consideration, that is section 8. The delete was in section 9. However, I agree to leave it to the AD or manet co-chair decisions, Best Regards AB On Thu, May 2, 2013 at 3:34 PM, Ulrich Herberg wrote: > AB, > > I let Adrian reply if he thinks the changes are significant enough to > warrant a new WGLC. I think this is not the case. The sentence was > probably a copy&paste mistake and does not provide any value in the > Security Considerations section. > > Best regards > Ulrich > > On Wed, May 1, 2013 at 11:00 AM, Abdussalam Baryun > wrote: > > I didn't think it was out of place. However, I thought/hope no words > deletes > > should occur after WGLC only if discussed (your delete was not discussed > on > > list until my input). Do I have to review all versions updated after > WGLC? > > some people may not, they may think it will be discussed to update I-Ds. > > > > AB > > > > > > > > On Tue, Apr 30, 2013 at 7:23 PM, Ulrich Herberg > wrote: > >> > >> AB, > >> > >> this sentence was out-of-place in section 9 and not related to > >> security considerations. > >> > >> Best regards > >> Ulrich > >> > >> On Tue, Apr 30, 2013 at 10:58 AM, Abdussalam Baryun > >> wrote: > >> > Not sure in new version -07 why deleted some words/statement in > section > >> > 9. > >> > > >> > AB > >> > > >> > > >> > > >> > On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg > >> > wrote: > >> >> > >> >> Adrian, > >> >> > >> >> yes, that was my intention...but sometimes, good intentions are not > >> >> enough > >> >> ;-) > >> >> > >> >> I have submitted a new revision with the one-word change that Benoit > >> >> requested. > >> >> > >> >> Best regards > >> >> Ulrich > >> >> > >> >> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel > > >> >> wrote: > >> >> > Hi Ulrich, > >> >> > > >> >> > Did you intend to post a new revision to make this change? > >> >> > > >> >> > Thanks, > >> >> > Adrian > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Ulrich Herberg [mailto:ulrich@herberg.name] > >> >> >> Sent: 15 April 2013 21:11 > >> >> >> To: Benoit Claise > >> >> >> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Farrel; > >> >> > pm-dir@ietf.org; > >> >> >> manet@ietf.org > >> >> >> Subject: Re: [manet] performance metrics directorate review of > >> >> >> draft-ietf- > >> >> >> manet-olsrv2-mib-06 > >> >> >> > >> >> >> Benoit, > >> >> >> > >> >> >> thank you very much for this review. I agree that using the term > >> >> >> "performance information" instead of "performance metrics" is a > good > >> >> >> idea. We will make the change. > >> >> >> > >> >> >> Best regards > >> >> >> Ulrich > >> >> >> > >> >> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise > > >> >> >> wrote: > >> >> >> > Dear all, > >> >> >> > > >> >> >> > I reviewed > >> >> >> > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, > >> >> >> > from a > >> >> >> > performance metric directorate point of view. > >> >> >> > > >> >> >> > This draft doesn't contain any reference to RFC6390, but > contains > >> >> >> > "performance metric". Hence this review was triggered. For > details > >> >> >> > about the > >> >> >> > directorate, see > >> >> >> > http://www.ietf.org/iesg/directorate/performance-metrics.html > >> >> >> > > >> >> >> > > >> >> >> > Definition of Managed Objects for the Optimized Link State > >> >> >> > Routing > >> >> >> > Protocol version 2 > >> >> >> > > >> >> >> > 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 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. > >> >> >> > > >> >> >> > > >> >> >> > Basically, all performance metrics come from this table: > >> >> >> > > >> >> >> > o olsrv2InterfacePerfTable - records performance counters > for > >> >> >> > each > >> >> >> > active OLSRv2 interface on this device. selected path to > >> >> >> > each > >> >> >> > destination for which any such path is known. This table > >> >> >> > has > >> >> >> > AUGMENTS { nhdpInterfacePerfEntry } and as such it is > >> >> >> > indexed > >> >> >> > via > >> >> >> > nhdpIfIndex from the NHDP-MIB. > >> >> >> > > >> >> >> > NHDP-MIB is RFC 6779: > >> >> >> > NhdpInterfacePerfEntry ::= > >> >> >> > SEQUENCE { > >> >> >> > nhdpIfHelloMessageXmits > >> >> >> > Counter32, > >> >> >> > nhdpIfHelloMessageRecvd > >> >> >> > Counter32, > >> >> >> > nhdpIfHelloMessageXmitAccumulatedSize > >> >> >> > Counter64, > >> >> >> > nhdpIfHelloMessageRecvdAccumulatedSize > >> >> >> > Counter64, > >> >> >> > nhdpIfHelloMessageTriggeredXmits > >> >> >> > Counter32, > >> >> >> > nhdpIfHelloMessagePeriodicXmits > >> >> >> > Counter32, > >> >> >> > nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount > >> >> >> > Counter32, > >> >> >> > nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount > >> >> >> > Counter32, > >> >> >> > nhdpIfHelloMessageXmitAccumulatedLostNeighborCount > >> >> >> > Counter32 > >> >> >> > } > >> >> >> > > >> >> >> > > >> >> >> > This draft contains similar objects in olsrv2InterfacePerfTable > : > >> >> >> > > >> >> >> > Olsrv2InterfacePerfEntry ::= > >> >> >> > SEQUENCE { > >> >> >> > olsrv2IfTcMessageXmits > >> >> >> > Counter32, > >> >> >> > olsrv2IfTcMessageRecvd > >> >> >> > Counter32, > >> >> >> > olsrv2IfTcMessageXmitAccumulatedSize > >> >> >> > Counter64, > >> >> >> > olsrv2IfTcMessageRecvdAccumulatedSize > >> >> >> > Counter64, > >> >> >> > olsrv2IfTcMessageTriggeredXmits > >> >> >> > Counter32, > >> >> >> > olsrv2IfTcMessagePeriodicXmits > >> >> >> > Counter32, > >> >> >> > olsrv2IfTcMessageForwardedXmits > >> >> >> > Counter32, > >> >> >> > olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount > >> >> >> > Counter32 > >> >> >> > } > >> >> >> > > >> >> >> > > >> >> >> > Personally, I don't believe that those objects should be subject > >> >> >> > to > >> >> >> > the RFC > >> >> >> > 6390 template definition. (Performance Metric Definition > Template, > >> >> >> > section > >> >> >> > 5.4.4, RFC 6390). > >> >> >> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] > was > >> >> >> > not > >> >> >> > subject to it > >> >> >> > Second reason: these objects are not really performance metrics, > >> >> >> > but > >> >> >> > mainly > >> >> >> > basic monitoring objects. > >> >> >> > > >> >> >> > Since RFC 6779 uses the term performance information (in the > >> >> >> > abstract), I > >> >> >> > would propose that draft-ietf-manet-olsrv2-mib also uses this > >> >> >> > term, > >> >> >> > and not > >> >> >> > the "performance metric". That would avoid some confusion. > >> >> >> > However, > >> >> >> keeping > >> >> >> > the olsrv2InterfacePerfTable OID name is perfectly fine, for > >> >> >> > consistency > >> >> >> > reason with RFC 6779. > >> >> >> > > >> >> >> > Regards, Benoit > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > manet mailing list > >> >> >> > manet@ietf.org > >> >> >> > https://www.ietf.org/mailman/listinfo/manet > >> >> >> > > >> >> > > >> >> _______________________________________________ > >> >> manet mailing list > >> >> manet@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/manet > >> > > >> > > >> > > >> > _______________________________________________ > >> > manet mailing list > >> > manet@ietf.org > >> > https://www.ietf.org/mailman/listinfo/manet > >> > > > > > > --e89a8ff24c8f35ed9804dbcd7299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ulrich,
=A0
Section 9 is not t= itled security consideration, that is section 8. The delete was in section = 9. However, I agree to leave it to the AD or manet=A0co-chair decisions,
=A0
Best Regards
AB


On Thu, May 2, 2013 at 3:34 PM, = Ulrich Herberg <ulrich@herberg.name> wrote:
AB,

I let Adrian reply if he thinks the changes are significant enough to
warrant a new WGLC. I think this is not the case. The sentence was
probably a copy&paste mistake and does not provide any value in the
Security Considerations section.

Best regards
Ulrich

On Wed, May 1, 2013 at 11:00 AM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> I didn't think it was out of place. However, I thought/hope no wor= ds deletes
> should occur after WGLC only if discussed (your delete was not discuss= ed on
> list until my input). Do I have to review all versions updated after W= GLC?
> some people may not, they may think it will be discussed to update I-D= s.
>
> AB
>
>
>
> On Tue, Apr 30, 2013 at 7:23 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
>>
>> AB,
>>
>> this sentence was out-of-place in section 9 and not related to
>> security considerations.
>>
>> Best regards
>> Ulrich
>>
>> On Tue, Apr 30, 2013 at 10:58 AM, Abdussalam Baryun
>> <abdussalambaryun= @gmail.com> wrote:
>> > Not sure in new version -07 why deleted some words/statement = in section
>> > 9.
>> >
>> > AB
>> >
>> >
>> >
>> > On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg <ulrich@herberg.name>
>> > wrote:
>> >>
>> >> Adrian,
>> >>
>> >> yes, that was my intention...but sometimes, good intentio= ns are not
>> >> enough
>> >> ;-)
>> >>
>> >> I have submitted a new revision with the one-word change = that Benoit
>> >> requested.
>> >>
>> >> Best regards
>> >> Ulrich
>> >>
>> >> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel <adrian@olddog.co.uk>
>> >> wrote:
>> >> > Hi Ulrich,
>> >> >
>> >> > Did you intend to post a new revision to make this c= hange?
>> >> >
>> >> > Thanks,
>> >> > Adrian
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Ulrich Herberg [mailto:ulrich@herberg.name]
>> >> >> Sent: 15 April 2013 21:11
>> >> >> To: Benoit Claise
>> >> >> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Fa= rrel;
>> >> > pm-dir@ietf.org;
>> >> >> manet@ietf.org=
>> >> >> Subject: Re: [manet] performance metrics directo= rate review of
>> >> >> draft-ietf-
>> >> >> manet-olsrv2-mib-06
>> >> >>
>> >> >> Benoit,
>> >> >>
>> >> >> thank you very much for this review. I agree tha= t using the term
>> >> >> "performance information" instead of &= quot;performance metrics" is a good
>> >> >> idea. We will make the change.
>> >> >>
>> >> >> Best regards
>> >> >> Ulrich
>> >> >>
>> >> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise &= lt;bclaise@cisco.com>
>> >> >> wrote:
>> >> >> > Dear all,
>> >> >> >
>> >> >> > I reviewed
>> >> >> > http://tools.ietf.org/html/dra= ft-ietf-manet-olsrv2-mib-06,
>> >> >> > from a
>> >> >> > performance metric directorate point of vie= w.
>> >> >> >
>> >> >> > This draft doesn't contain any referenc= e to RFC6390, but contains
>> >> >> > "performance metric". Hence this = review was triggered. For details
>> >> >> > about the
>> >> >> > directorate, see
>> >> >> > http://www.ietf.org/iesg/d= irectorate/performance-metrics.html
>> >> >> >
>> >> >> >
>> >> >> > Definition of Managed Objects for the =A0Op= timized Link State
>> >> >> > Routing
>> >> >> > Protocol version 2
>> >> >> >
>> >> >> > Abstract
>> >> >> >
>> >> >> > =A0 =A0This document defines the Management= Information Base (MIB)
>> >> >> > module
>> >> >> > =A0 =A0for configuring and managing the Opt= imized Link State Routing
>> >> >> > =A0 =A0protocol version 2 (OLSRv2). =A0The = OLSRv2-MIB module is
>> >> >> > structured
>> >> >> > =A0 =A0into state information, performance = metrics, and notifications.
>> >> >> > This
>> >> >> > =A0 =A0additional state and performance inf= ormation is useful to
>> >> >> > =A0 =A0troubleshoot problems and performanc= e issues of the routing
>> >> >> > protocol.
>> >> >> > =A0 =A0Different levels of compliance allow= implementers to use
>> >> >> > smaller
>> >> >> > =A0 =A0subsets of all defined objects, allo= wing for this MIB module to
>> >> >> > be
>> >> >> > =A0 =A0deployed on more constrained routers= .
>> >> >> >
>> >> >> >
>> >> >> > Basically, all performance metrics come fro= m this table:
>> >> >> >
>> >> >> > =A0 =A0o =A0olsrv2InterfacePerfTable - reco= rds performance counters for
>> >> >> > each
>> >> >> > =A0 =A0 =A0 active OLSRv2 interface on this= device. selected path to
>> >> >> > each
>> >> >> > =A0 =A0 =A0 destination for which any such = path is known. =A0This table
>> >> >> > has
>> >> >> > =A0 =A0 =A0 AUGMENTS { nhdpInterfacePerfEnt= ry } and as such it is
>> >> >> > indexed
>> >> >> > via
>> >> >> > =A0 =A0 =A0 nhdpIfIndex from the NHDP-MIB.<= br> >> >> >> >
>> >> >> > NHDP-MIB is RFC 6779:
>> >> >> > =A0 =A0NhdpInterfacePerfEntry ::=3D
>> >> >> > =A0 =A0 =A0 SEQUENCE {
>> >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmits<= br> >> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageRecvd<= br> >> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAc= cumulatedSize
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter64,
>> >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageRecvdA= ccumulatedSize
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter64,
>> >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageTrigge= redXmits
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessagePeriod= icXmits
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAc= cumulatedSymmetricNeighborCount
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAc= cumulatedHeardNeighborCount
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAc= cumulatedLostNeighborCount
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32
>> >> >> > =A0 =A0 =A0 }
>> >> >> >
>> >> >> >
>> >> >> > This draft contains similar objects in olsr= v2InterfacePerfTable :
>> >> >> >
>> >> >> > =A0 =A0 Olsrv2InterfacePerfEntry ::=3D
>> >> >> > =A0 =A0 =A0 =A0SEQUENCE {
>> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageXmits<= br> >> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageRecvd<= br> >> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageXmitAc= cumulatedSize
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter64,
>> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageRecvdA= ccumulatedSize
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter64,
>> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageTrigge= redXmits
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessagePeriod= icXmits
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageForwar= dedXmits
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageXmitAc= cumulatedMPRSelectorCount
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32
>> >> >> > =A0 =A0 =A0 =A0}
>> >> >> >
>> >> >> >
>> >> >> > Personally, I don't believe that those = objects should be subject
>> >> >> > to
>> >> >> > the RFC
>> >> >> > 6390 template definition. (Performance Metr= ic Definition Template,
>> >> >> > section
>> >> >> > 5.4.4, RFC 6390).
>> >> >> > First reason: NhdpInterfacePerfEntry, from = NHDP-MIB [RFC 6779] was
>> >> >> > not
>> >> >> > subject to it
>> >> >> > Second reason: these objects are not really= performance metrics,
>> >> >> > but
>> >> >> > mainly
>> >> >> > basic monitoring objects.
>> >> >> >
>> >> >> > Since RFC 6779 uses the term performance in= formation (in the
>> >> >> > abstract), I
>> >> >> > would propose that draft-ietf-manet-olsrv2-= mib also uses this
>> >> >> > term,
>> >> >> > and not
>> >> >> > the "performance metric". That wo= uld avoid some confusion.
>> >> >> > However,
>> >> >> keeping
>> >> >> > the olsrv2InterfacePerfTable OID name is pe= rfectly fine, for
>> >> >> > consistency
>> >> >> > reason with RFC 6779.
>> >> >> >
>> >> >> > Regards, Benoit
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > ___________________________________________= ____
>> >> >> > manet mailing list
>> >> >> > manet@iet= f.org
>> >> >> > https://www.ietf.org/mailman/listinfo/manet<= /a>
>> >> >> >
>> >> >
>> >> _______________________________________________
>> >> 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
>> >
>
>

--e89a8ff24c8f35ed9804dbcd7299-- From vignesh@atc.tcs.com Fri May 3 04:29:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819D821F859D for ; Fri, 3 May 2013 04:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] 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 mZjlSJSpJSTX for ; Fri, 3 May 2013 04:29:16 -0700 (PDT) Received: from atcmail.atc.tcs.com (atcmail.atc.tcs.com [203.200.212.145]) by ietfa.amsl.com (Postfix) with ESMTP id 72E0F21F8619 for ; Fri, 3 May 2013 04:29:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by atcmail.atc.tcs.com (8.14.4/8.14.4) with ESMTP id r43BT6Ts006771 for ; Fri, 3 May 2013 16:59:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 03 May 2013 16:59:06 +0530 From: vignesh To: In-Reply-To: <5182455D.805@atc.tcs.com> References: <20130325172118.14053.51653.idtracker@ietfa.amsl.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C1006DA31@xmb-aln-x03.cisco.com> <5182455D.805@atc.tcs.com> Message-ID: X-Sender: vignesh@atc.tcs.com Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 11:29:22 -0000 On 2013-05-02 16:22, Vigneswaran R wrote: > Hello, > > Below are some minor things I noticed while going through the > dlep-draft-04, > > id> 9. DLEP Data Items > > one of the Signal TLVs, documented in section [INSERT REFERENCE > HERE]. > > suggestion> replace [INSERT REFERENCE HERE] with 10.1. > > id> 9.9 Current Data Rate (Transmit) > > The Current Data Rate Receive (CDRT) TLV is used in Neighbor Up, > > suggestion> change "Current Data Rate Receive" into "Current Data Rate > Transmit" A few more, id> 9.15 Relative Link Quality (Transmit) The Transmit Link Quality Receive (RLQT) TLV is an OPTIONAL data suggestion> change "Transmit Link Quality Receive" into "Relative Link Quality Transmit" id> 9.15 Relative Link Quality (Transmit) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 1 |XMT Rel. Link | | | |Quality (RLQR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ suggestion> change "(RLQR)" into "(RLQT)" id> 9.17 Heartbeat Interval/Threshold +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 1 | Interval | Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length - 1 suggestion> change the value for Length to 2, in both places id> 9.21 Credit Request +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 0 | Reserved, MUST| | | | be set to 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length - 0 comment> I think, the Length should be 1 id> 10. DLEP Protocol Messages signal, as defined in section 11.1 of this document. The second TLV MUST be the Identification data item, defined in section 10.1 comment> It seems, Signals and Data Items are defined under section 10.1 and section 9 respectively. id> 10. DLEP Protocol Messages +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start of optional DLEP | | TLVs... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ suggestion> "Start of optional DLEP TLVs..." can be changed to "Start of optional and/or mandatory DLEP TLVs..." like the following (as some of the signals have mandatory data items). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start of optional and/or | | mandatory DLEP TLVs... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ id> 11. Peer Discovery Message Given the packet format described in section 11, the initial TLV Type suggestion> change "section 11" into "section 10" id> 13. Peer Offer ACK Message MUST contain an OPTIONAL Status data item, indicating success or suggestion> "OPTIONAL" can be removed. Regards, Vignesh > On 03/25/2013 10:53 PM, Stan Ratliff (sratliff) wrote: >> WG - >> >> As promised, DLEP-04. As I mentioned in Orlando, the changes are: >> 1. Went back to modem-initiated discovery >> 2. Inbound and outbound metrics >> >> I'm sure something got missed, so your review & comments are >> appreciated. >> >> Regards, >> Stan >> >> >> On Mar 25, 2013, at 1:21 PM, >> wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Mobile Ad-hoc Networks Working >>> Group of the IETF. >>> >>> Title : Dynamic Link Exchange Protocol (DLEP) >>> Author(s) : Stan Ratliff >>> Bo Berry >>> Greg Harrison >>> Darryl Satterwhite >>> Shawn Jury >>> Filename : draft-ietf-manet-dlep-04.txt >>> Pages : 48 >>> Date : 2013-03-25 >>> >>> Abstract: >>> When routing devices rely on modems to effect communications over >>> wireless links, they need timely and accurate knowledge of the >>> characteristics of the link (speed, state, etc.) in order to make >>> forwarding decisions. In mobile or other environments where these >>> characteristics change frequently, manual configurations or the >>> inference of state through routing or transport protocols does >>> not >>> allow the router to make the best decisions. A bidirectional, >>> event- >>> driven communication channel between the router and the modem is >>> necessary. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-manet-dlep-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-04 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From adrian@olddog.co.uk Fri May 3 05:22:41 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C61621F9488 for ; Fri, 3 May 2013 05:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=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 mOLLRhpahnpz for ; Fri, 3 May 2013 05:22:36 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1D78A21F8B65 for ; Fri, 3 May 2013 05:22:33 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r43CMUVe018204; Fri, 3 May 2013 13:22:30 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r43CMSDS018153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 3 May 2013 13:22:29 +0100 From: "Adrian Farrel" To: "'Abdussalam Baryun'" , "'Ulrich Herberg'" References: <000a01ce4436$3f94c440$bebe4cc0$@olddog.co.uk> In-Reply-To: Date: Fri, 3 May 2013 13:22:27 +0100 Message-ID: <047c01ce47f8$e0c63270$a2529750$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_047D_01CE4801.429066D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFnRQEkznsV8cZ3IzpjX0FGWcVNLwIdTujvAlTxTr0Cv+T0BwLW4wucAe99eUwBEe95uJlZD0EA Content-Language: en-gb Cc: 'manet' , draft-ietf-manet-olsrv2-mib@tools.ietf.org Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 12:22:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_047D_01CE4801.429066D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, How nice to be sending email to the MANET list again after such a long time away :-) AB is right that the text was removed from section 9 (Applicability Statement) and not the Security Considerations section (section 8). Ulrich is right that the text was out of place. The text in section 9 of -06 read: OLSRv2 is designed to allow routers to leverage information on discovered routers and generate unicast routing paths within the MANET. While this is undoubtedly true, it has nothing to do with the applicability of the MIB module defined in this document. That is the purpose of Section 9. Section 4 provides a brief overview of OLSRv2 (obviously deferring to draft-ietf-manet-olsrv2) and *that* is the correct place for a description of the purpose/function of OLSRv2. Re-reading section 4 I find it already has plenty of description of OLSRv2 without the need to explicitly include the text deleted from section 9. That is consistent with the review I did of the changes present in -07 before I put the document on the IESG agenda. So I am comfortable with things going forward as they are. In general, document editors have latitude to make textual edits that do not change the protocol specification in a document. At the extreme end of the spectrum, you would not expect an editor to seek working group consensus (two week poll of the WG called and judged by the chairs) on the placement of a comma or fixing a spelling mistake. Thus, the removal of this sort of misplaced text is easily within scope of what they can do without explaining themselves to the WG. Each new revision of a document is notified to the WG, and the diff files are easily available. Indeed, the announcement notice includes a link to the diff. Thus, those who are interested (and not everyone in the WG is interested in every document) can easily check what has happened. The pragmatic approach to document development is for the editors/authors to lead, and for the WG to pull them back if they have concerns. usually, the editors/authors will discuss the concerns that have been raised hoping to reach agreement/compromise. If there is need, the editors will ask the chairs to call consensus. Thanks, Adrian From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 03 May 2013 11:02 To: Ulrich Herberg Cc: adrian; draft-ietf-manet-olsrv2-mib@tools.ietf.org; manet Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06 Hi Ulrich, Section 9 is not titled security consideration, that is section 8. The delete was in section 9. However, I agree to leave it to the AD or manet co-chair decisions, Best Regards AB On Thu, May 2, 2013 at 3:34 PM, Ulrich Herberg wrote: AB, I let Adrian reply if he thinks the changes are significant enough to warrant a new WGLC. I think this is not the case. The sentence was probably a copy&paste mistake and does not provide any value in the Security Considerations section. Best regards Ulrich On Wed, May 1, 2013 at 11:00 AM, Abdussalam Baryun wrote: > I didn't think it was out of place. However, I thought/hope no words deletes > should occur after WGLC only if discussed (your delete was not discussed on > list until my input). Do I have to review all versions updated after WGLC? > some people may not, they may think it will be discussed to update I-Ds. > > AB > > > > On Tue, Apr 30, 2013 at 7:23 PM, Ulrich Herberg wrote: >> >> AB, >> >> this sentence was out-of-place in section 9 and not related to >> security considerations. >> >> Best regards >> Ulrich >> >> On Tue, Apr 30, 2013 at 10:58 AM, Abdussalam Baryun >> wrote: >> > Not sure in new version -07 why deleted some words/statement in section >> > 9. >> > >> > AB >> > >> > >> > >> > On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg >> > wrote: >> >> >> >> Adrian, >> >> >> >> yes, that was my intention...but sometimes, good intentions are not >> >> enough >> >> ;-) >> >> >> >> I have submitted a new revision with the one-word change that Benoit >> >> requested. >> >> >> >> Best regards >> >> Ulrich >> >> >> >> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel >> >> wrote: >> >> > Hi Ulrich, >> >> > >> >> > Did you intend to post a new revision to make this change? >> >> > >> >> > Thanks, >> >> > Adrian >> >> > >> >> >> -----Original Message----- >> >> >> From: Ulrich Herberg [mailto:ulrich@herberg.name] >> >> >> Sent: 15 April 2013 21:11 >> >> >> To: Benoit Claise >> >> >> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Farrel; >> >> > pm-dir@ietf.org; >> >> >> manet@ietf.org >> >> >> Subject: Re: [manet] performance metrics directorate review of >> >> >> draft-ietf- >> >> >> manet-olsrv2-mib-06 >> >> >> >> >> >> Benoit, >> >> >> >> >> >> thank you very much for this review. I agree that using the term >> >> >> "performance information" instead of "performance metrics" is a good >> >> >> idea. We will make the change. >> >> >> >> >> >> Best regards >> >> >> Ulrich >> >> >> >> >> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise >> >> >> wrote: >> >> >> > Dear all, >> >> >> > >> >> >> > I reviewed >> >> >> > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, >> >> >> > from a >> >> >> > performance metric directorate point of view. >> >> >> > >> >> >> > This draft doesn't contain any reference to RFC6390, but contains >> >> >> > "performance metric". Hence this review was triggered. For details >> >> >> > about the >> >> >> > directorate, see >> >> >> > http://www.ietf.org/iesg/directorate/performance-metrics.html >> >> >> > >> >> >> > >> >> >> > Definition of Managed Objects for the Optimized Link State >> >> >> > Routing >> >> >> > Protocol version 2 >> >> >> > >> >> >> > 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 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. >> >> >> > >> >> >> > >> >> >> > Basically, all performance metrics come from this table: >> >> >> > >> >> >> > o olsrv2InterfacePerfTable - records performance counters for >> >> >> > each >> >> >> > active OLSRv2 interface on this device. selected path to >> >> >> > each >> >> >> > destination for which any such path is known. This table >> >> >> > has >> >> >> > AUGMENTS { nhdpInterfacePerfEntry } and as such it is >> >> >> > indexed >> >> >> > via >> >> >> > nhdpIfIndex from the NHDP-MIB. >> >> >> > >> >> >> > NHDP-MIB is RFC 6779: >> >> >> > NhdpInterfacePerfEntry ::= >> >> >> > SEQUENCE { >> >> >> > nhdpIfHelloMessageXmits >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageRecvd >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedSize >> >> >> > Counter64, >> >> >> > nhdpIfHelloMessageRecvdAccumulatedSize >> >> >> > Counter64, >> >> >> > nhdpIfHelloMessageTriggeredXmits >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessagePeriodicXmits >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedLostNeighborCount >> >> >> > Counter32 >> >> >> > } >> >> >> > >> >> >> > >> >> >> > This draft contains similar objects in olsrv2InterfacePerfTable : >> >> >> > >> >> >> > Olsrv2InterfacePerfEntry ::= >> >> >> > SEQUENCE { >> >> >> > olsrv2IfTcMessageXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageRecvd >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageXmitAccumulatedSize >> >> >> > Counter64, >> >> >> > olsrv2IfTcMessageRecvdAccumulatedSize >> >> >> > Counter64, >> >> >> > olsrv2IfTcMessageTriggeredXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessagePeriodicXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageForwardedXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount >> >> >> > Counter32 >> >> >> > } >> >> >> > >> >> >> > >> >> >> > Personally, I don't believe that those objects should be subject >> >> >> > to >> >> >> > the RFC >> >> >> > 6390 template definition. (Performance Metric Definition Template, >> >> >> > section >> >> >> > 5.4.4, RFC 6390). >> >> >> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was >> >> >> > not >> >> >> > subject to it >> >> >> > Second reason: these objects are not really performance metrics, >> >> >> > but >> >> >> > mainly >> >> >> > basic monitoring objects. >> >> >> > >> >> >> > Since RFC 6779 uses the term performance information (in the >> >> >> > abstract), I >> >> >> > would propose that draft-ietf-manet-olsrv2-mib also uses this >> >> >> > term, >> >> >> > and not >> >> >> > the "performance metric". That would avoid some confusion. >> >> >> > However, >> >> >> keeping >> >> >> > the olsrv2InterfacePerfTable OID name is perfectly fine, for >> >> >> > consistency >> >> >> > reason with RFC 6779. >> >> >> > >> >> >> > Regards, Benoit >> >> >> > >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > manet mailing list >> >> >> > manet@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/manet >> >> >> > >> >> > >> >> _______________________________________________ >> >> manet mailing list >> >> manet@ietf.org >> >> https://www.ietf.org/mailman/listinfo/manet >> > >> > >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >> > > > ------=_NextPart_000_047D_01CE4801.429066D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

How nice to be sending email = to the MANET list again after such a long time away = :-)

 

AB is right that the text was = removed from section 9 (Applicability Statement) and not the Security = Considerations section (section 8).

 

Ulrich is right that the text = was out of place.

 

The text in section 9 of -06 = read:

   OLSRv2 is designed to = allow routers to leverage information on

   discovered routers and = generate unicast routing paths within the

   = MANET.

 

While this is undoubtedly = true, it has nothing to do with the applicability of the MIB module = defined in this document. That is the purpose of Section = 9.

 

Section 4 provides a brief = overview of OLSRv2 (obviously deferring to draft-ietf-manet-olsrv2) and = *that* is the correct place for a description of the purpose/function of = OLSRv2. Re-reading section 4 I find it already has plenty of description = of OLSRv2 without the need to explicitly include the text deleted from = section 9.

 

That is consistent with the = review I did of the changes present in -07 before I put the document on = the IESG agenda. So I am comfortable with things going forward as they = are.

 

In general, document editors = have latitude to make textual edits that do not change the protocol = specification in a document. At the extreme end of the spectrum, you = would not expect an editor to seek working group consensus (two week = poll of the WG called and judged by the chairs) on the placement of a = comma or fixing a spelling mistake. Thus, the removal of this sort of = misplaced text is easily within scope of what they can do without = explaining themselves to the WG.

 

Each new revision of a = document is notified to the WG, and the diff files are easily available. = Indeed, the announcement notice includes a link to the diff. Thus, those = who are interested (and not everyone in the WG is interested in every = document) can easily check what has happened.

 

The pragmatic approach to = document development is for the editors/authors to lead, and for the WG = to pull them back if they have concerns. usually, the editors/authors = will discuss the concerns that have been raised hoping to reach = agreement/compromise. If there is need, the editors will ask the chairs = to call consensus.

 

Thanks,

Adrian

 

From: Abdussalam Baryun = [mailto:abdussalambaryun@gmail.com]
Sent: 03 May 2013 = 11:02
To: Ulrich Herberg
Cc: adrian; = draft-ietf-manet-olsrv2-mib@tools.ietf.org; manet
Subject: Re: = [manet] performance metrics directorate review of = draft-ietf-manet-olsrv2-mib-06

 

Hi = Ulrich,

 

Section 9 is not titled security consideration, that = is section 8. The delete was in section 9. However, I agree to leave it = to the AD or manet co-chair decisions,

 

Best Regards

AB

 

On Thu, May 2, 2013 at 3:34 PM, Ulrich Herberg <ulrich@herberg.name> wrote:

AB,

I let Adrian reply if he thinks the changes = are significant enough to
warrant a new WGLC. I think this is not the = case. The sentence was
probably a copy&paste mistake and does not = provide any value in the
Security Considerations section.

Best = regards
Ulrich

On Wed, May 1, 2013 at 11:00 AM, Abdussalam = Baryun

<abdussalambaryun@gmail.com= > wrote:
> I didn't think it was out of place. However, I = thought/hope no words deletes
> should occur after WGLC only if = discussed (your delete was not discussed on
> list until my = input). Do I have to review all versions updated after WGLC?
> = some people may not, they may think it will be discussed to update = I-Ds.
>
> AB
>
>
>
> On Tue, Apr 30, = 2013 at 7:23 PM, Ulrich Herberg <ulrich@herberg.name> = wrote:
>>
>> AB,
>>
>> this sentence = was out-of-place in section 9 and not related to
>> security = considerations.
>>
>> Best regards
>> = Ulrich
>>
>> On Tue, Apr 30, 2013 at 10:58 AM, = Abdussalam Baryun
>> <abdussalambaryun@gmail.com= > wrote:
>> > Not sure in new version -07 why deleted = some words/statement in section
>> > 9.
>> = >
>> > AB
>> >
>> >
>> = >
>> > On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg = <ulrich@herberg.name>
>&g= t; > wrote:
>> >>
>> >> = Adrian,
>> >>
>> >> yes, that was my = intention...but sometimes, good intentions are not
>> >> = enough
>> >> ;-)
>> >>
>> = >> I have submitted a new revision with the one-word change that = Benoit
>> >> requested.
>> >>
>> = >> Best regards
>> >> Ulrich
>> = >>
>> >> On Sun, Apr 28, 2013 at 10:31 AM, Adrian = Farrel <adrian@olddog.co.uk>
>&g= t; >> wrote:
>> >> > Hi Ulrich,
>> = >> >
>> >> > Did you intend to post a new = revision to make this change?
>> >> >
>> = >> > Thanks,
>> >> > Adrian
>> = >> >
>> >> >> -----Original = Message-----
>> >> >> From: Ulrich Herberg = [mailto:ulrich@herberg.name]
>> = >> >> Sent: 15 April 2013 21:11
>> >> = >> To: Benoit Claise
>> >> >> Cc: draft-ietf-man= et-olsrv2-mib@tools.ietf.org; Adrian Farrel;
>> >> = > pm-dir@ietf.org;
>> = >> >> manet@ietf.org
>> >> = >> Subject: Re: [manet] performance metrics directorate review = of
>> >> >> draft-ietf-
>> >> = >> manet-olsrv2-mib-06
>> >> >>
>> = >> >> Benoit,
>> >> >>
>> = >> >> thank you very much for this review. I agree that = using the term
>> >> >> "performance = information" instead of "performance metrics" is a = good
>> >> >> idea. We will make the = change.
>> >> >>
>> >> >> Best = regards
>> >> >> Ulrich
>> >> = >>
>> >> >> On Mon, Apr 15, 2013 at 6:19 AM, = Benoit Claise <bclaise@cisco.com>
>> = >> >> wrote:
>> >> >> > Dear = all,
>> >> >> >
>> >> >> = > I reviewed
>> >> >> > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-= 06,
>> >> >> > from a
>> >> = >> > performance metric directorate point of view.
>> = >> >> >
>> >> >> > This draft = doesn't contain any reference to RFC6390, but contains
>> = >> >> > "performance metric". Hence this review = was triggered. For details
>> >> >> > about = the
>> >> >> > directorate, see
>> = >> >> > http://www.ietf.org/iesg/directorate/performance-metric= s.html
>> >> >> >
>> >> = >> >
>> >> >> > Definition of Managed = Objects for the  Optimized Link State
>> >> >> = > Routing
>> >> >> > Protocol version = 2
>> >> >> >
>> >> >> > = 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 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.
>> = >> >> >
>> >> >> >
>> = >> >> > Basically, all performance metrics come from this = table:
>> >> >> >
>> >> >> = >    o  olsrv2InterfacePerfTable - records performance = counters for
>> >> >> > each
>> = >> >> >       active OLSRv2 interface on = this device. selected path to
>> >> >> > = each
>> >> >> >       destination = for which any such path is known.  This table
>> >> = >> > has
>> >> >> >     =   AUGMENTS { nhdpInterfacePerfEntry } and as such it is
>> = >> >> > indexed
>> >> >> > = via
>> >> >> >       nhdpIfIndex = from the NHDP-MIB.
>> >> >> >
>> = >> >> > NHDP-MIB is RFC 6779:
>> >> = >> >    NhdpInterfacePerfEntry ::=3D
>> = >> >> >       SEQUENCE {
>> = >> >> >         =  nhdpIfHelloMessageXmits
>> >> >> >   =           Counter32,
>> >> = >> >         =  nhdpIfHelloMessageRecvd
>> >> >> >   =           Counter32,
>> >> = >> >         =  nhdpIfHelloMessageXmitAccumulatedSize
>> >> = >> >             = Counter64,
>> >> >> >       =    nhdpIfHelloMessageRecvdAccumulatedSize
>> >> = >> >             = Counter64,
>> >> >> >       =    nhdpIfHelloMessageTriggeredXmits
>> >> = >> >             = Counter32,
>> >> >> >       =    nhdpIfHelloMessagePeriodicXmits
>> >> = >> >             = Counter32,
>> >> >> >       =   =  nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
>>= >> >> >             = Counter32,
>> >> >> >       =   =  nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
>> = >> >> >             = Counter32,
>> >> >> >       =   =  nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
>> = >> >> >             = Counter32
>> >> >> >       = }
>> >> >> >
>> >> >> = >
>> >> >> > This draft contains similar = objects in olsrv2InterfacePerfTable :
>> >> >> = >
>> >> >> >     = Olsrv2InterfacePerfEntry ::=3D
>> >> >> >   =      SEQUENCE {
>> >> >> >   =         olsrv2IfTcMessageXmits
>> >> = >> >             =  Counter32,
>> >> >> >       =     olsrv2IfTcMessageRecvd
>> >> >> > =              Counter32,
>> = >> >> >           = olsrv2IfTcMessageXmitAccumulatedSize
>> >> >> > =              Counter64,
>> = >> >> >           = olsrv2IfTcMessageRecvdAccumulatedSize
>> >> >> > =              Counter64,
>> = >> >> >           = olsrv2IfTcMessageTriggeredXmits
>> >> >> > =              Counter32,
>> = >> >> >           = olsrv2IfTcMessagePeriodicXmits
>> >> >> >   =            Counter32,
>> >> = >> >           = olsrv2IfTcMessageForwardedXmits
>> >> >> > =              Counter32,
>> = >> >> >           = olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
>> >> = >> >             =  Counter32
>> >> >> >       =  }
>> >> >> >
>> >> >> = >
>> >> >> > Personally, I don't believe that = those objects should be subject
>> >> >> > = to
>> >> >> > the RFC
>> >> = >> > 6390 template definition. (Performance Metric Definition = Template,
>> >> >> > section
>> = >> >> > 5.4.4, RFC 6390).
>> >> >> = > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] = was
>> >> >> > not
>> >> >> = > subject to it
>> >> >> > Second reason: = these objects are not really performance metrics,
>> >> = >> > but
>> >> >> > mainly
>> = >> >> > basic monitoring objects.
>> >> = >> >
>> >> >> > Since RFC 6779 uses the = term performance information (in the
>> >> >> > = abstract), I
>> >> >> > would propose that = draft-ietf-manet-olsrv2-mib also uses this
>> >> >> = > term,
>> >> >> > and not
>> = >> >> > the "performance metric". That would = avoid some confusion.
>> >> >> > = However,
>> >> >> keeping
>> >> = >> > the olsrv2InterfacePerfTable OID name is perfectly fine, = for
>> >> >> > consistency
>> >> = >> > reason with RFC 6779.
>> >> >> = >
>> >> >> > Regards, Benoit
>> = >> >> >
>> >> >> >
>> = >> >> >
>> >> >> > = _______________________________________________
>> >> = >> > manet mailing list
>> >> >> > manet@ietf.org
>> >> = >> > https://www.ietf.org/mailman/listinfo/manet
>= > >> >> >
>> >> >
>> = >> _______________________________________________
>> = >> manet mailing list
>> >> manet@ietf.org
>> >> = https://www.ietf.org/mailman/listinfo/manet
>= > >
>> >
>> >
>> > = _______________________________________________
>> > manet = mailing list
>> > manet@ietf.org
>> > https://www.ietf.org/mailman/listinfo/manet
>= > >
>
>

 

------=_NextPart_000_047D_01CE4801.429066D0-- From internet-drafts@ietf.org Fri May 3 06:17:39 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF5821F9027; Fri, 3 May 2013 06:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.411 X-Spam-Level: X-Spam-Status: No, score=-98.411 tagged_above=-999 required=5 tests=[AWL=-2.094, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, RCVD_IN_XBL=3.033, 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 DfanE4zLD6V9; Fri, 3 May 2013 06:17:34 -0700 (PDT) Received: from jlonline.com (pip46.ptt.js.cn [61.155.13.222]) by ietfa.amsl.com (Postfix) with SMTP id 7562621F856D; Fri, 3 May 2013 06:17:32 -0700 (PDT) Received: from jlonline.com([10.100.0.22]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm95183c826; Fri, 03 May 2013 21:23:15 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm0517ed728; Tue, 30 Apr 2013 03:22:23 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id AISP action; Tue, 30 Apr 2013 03:22:19 +0800 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0847D21F9BB1; Mon, 29 Apr 2013 12:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1367262943; bh=Amb1r7GXuSvgQnV7T/qR5eSNNHu9G/0kX2x2AdKy5jk=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=q5O3KOBokzX0bwepeFfcXTproB3t+M3WZMRAehSMlcpDdB31Zs2YiZiJwS2xdjWEh L+xvhEEeCdoKUtWwpXpMJRozXjNBuV5D4qUNsu9cyVad+oqaJdTFXYdTKh3TwJw4+N BRNGCUkYeP9b3qNVeSaPZHpzShWh86cb9io6mFTY= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EAB21F9BA9; Mon, 29 Apr 2013 12:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 5tYNfDBtYopq; Mon, 29 Apr 2013 12:15:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5199321F9BB2; Mon, 29 Apr 2013 12:15:40 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130429191540.6566.84892.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 12:15:40 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-Msg-ID: ro9et64B X-AIMC-AUTH: (null) X-AIMC-MAILFROM: internet-drafts@ietf.org Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-07.txt X-BeenThere: manet@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:17:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Definition of Managed Objects for the Optimized Link State Routing Protocol version 2 Author(s) : Ulrich Herberg Robert G. Cole Thomas Heide Clausen Filename : draft-ietf-manet-olsrv2-mib-07.txt Pages : 76 Date : 2013-04-29 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 state information, performance information, 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. 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-mib-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From sratliff@cisco.com Fri May 3 06:50:48 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7181D21F9627 for ; Fri, 3 May 2013 06:50:48 -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 mCt7l4+IZJkV for ; Fri, 3 May 2013 06:50:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D3EB521F9389 for ; Fri, 3 May 2013 06:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5987; q=dns/txt; s=iport; t=1367589035; x=1368798635; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3V64a3Jc/xaRYDsn2UUrRejucGKjJ3MdAoQYwP03H1A=; b=cpMcad79OiPwkhLnfUcTmM3/XisFAdDrUUYv1x5pQdBOqcBg9NCKXN6N hz0n2+V3R0+FosOpkXmh7iYKrmVzKL4B3QtGzWbpEyb1gFM8shffmkid9 CTZFCsOf9IeY9zezs2GSJPGYbZT9pXUG0D0acaSXtQAliMLgwBUE/D1OS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAG3Ag1GtJV2Z/2dsb2JhbABQgwc3RL5seRZ0gh8BAQEDAQEBATc0CwULAgEIGAoUECcLJQIEDgUIAYd9BgcFwSqOdAIxB4JyYQOTXIR1kAyDDYIn X-IronPort-AV: E=Sophos;i="4.87,604,1363132800"; d="scan'208";a="206090079" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 03 May 2013 13:50:34 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r43DoYBF016639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 May 2013 13:50:34 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.3]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 3 May 2013 08:50:33 -0500 From: "Stan Ratliff (sratliff)" To: vignesh Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-04.txt Thread-Index: AQHOKX0z5IHQaN4zhUKX7SuqZaqtKpi2+6uAgDtLYICAAZyjAIAAJ4WA Date: Fri, 3 May 2013 13:50:33 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100D5BE2@xmb-rcd-x03.cisco.com> References: <20130325172118.14053.51653.idtracker@ietfa.amsl.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C1006DA31@xmb-aln-x03.cisco.com> <5182455D.805@atc.tcs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.118] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 13:50:48 -0000 Vignesh,=20 Thank you for the review and comment.=20 Regards, Stan On May 3, 2013, at 7:29 AM, vignesh wrote: > On 2013-05-02 16:22, Vigneswaran R wrote: >> Hello, >> Below are some minor things I noticed while going through the dlep-draft= -04, >> id> 9. DLEP Data Items >> >> one of the Signal TLVs, documented in section [INSERT REFERENCE >> HERE]. >> suggestion> replace [INSERT REFERENCE HERE] with 10.1. >> id> 9.9 Current Data Rate (Transmit) >> The Current Data Rate Receive (CDRT) TLV is used in Neighbor Up, >> suggestion> change "Current Data Rate Receive" into "Current Data Rate T= ransmit" >=20 > A few more, >=20 > id> 9.15 Relative Link Quality (Transmit) >=20 > The Transmit Link Quality Receive (RLQT) TLV is an OPTIONAL data >=20 > suggestion> change "Transmit Link Quality Receive" into "Relative Link Qu= ality Transmit" >=20 > id> 9.15 Relative Link Quality (Transmit) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |TLV Type =3DTBD |Length =3D 1 |XMT Rel. Link | > | | |Quality (RLQR) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > suggestion> change "(RLQR)" into "(RLQT)" >=20 > id> 9.17 Heartbeat Interval/Threshold > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |TLV Type =3DTBD |Length =3D 1 | Interval | Threshold | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Length - 1 >=20 > suggestion> change the value for Length to 2, in both places >=20 > id> 9.21 Credit Request > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |TLV Type =3DTBD |Length =3D 0 | Reserved, MUST| > | | | be set to 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Length - 0 >=20 > comment> I think, the Length should be 1 >=20 > id> 10. DLEP Protocol Messages > > signal, as defined in section 11.1 of this document. The second TLV > MUST be the Identification data item, defined in section 10.1 >=20 > comment> It seems, Signals and Data Items are defined under section 10.1 = and section 9 respectively. >=20 > id> 10. DLEP Protocol Messages > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Start of optional DLEP | > | TLVs... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > suggestion> "Start of optional DLEP TLVs..." can be changed to "Start of = optional and/or mandatory DLEP TLVs..." like the following (as some of the = signals have mandatory data items). >=20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Start of optional and/or | > | mandatory DLEP TLVs... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > id> 11. Peer Discovery Message > > Given the packet format described in section 11, the initial TLV Type >=20 > suggestion> change "section 11" into "section 10" >=20 > id> 13. Peer Offer ACK Message > > MUST contain an OPTIONAL Status data item, indicating success or >=20 > suggestion> "OPTIONAL" can be removed. >=20 >=20 > Regards, > Vignesh >=20 >> On 03/25/2013 10:53 PM, Stan Ratliff (sratliff) wrote: >>> WG - >>> As promised, DLEP-04. As I mentioned in Orlando, the changes are: >>> 1. Went back to modem-initiated discovery >>> 2. Inbound and outbound metrics >>> I'm sure something got missed, so your review & comments are appreciate= d. >>> Regards, >>> Stan >>> On Mar 25, 2013, at 1:21 PM, >>> wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. >>>> Title : Dynamic Link Exchange Protocol (DLEP) >>>> Author(s) : Stan Ratliff >>>> Bo Berry >>>> Greg Harrison >>>> Darryl Satterwhite >>>> Shawn Jury >>>> Filename : draft-ietf-manet-dlep-04.txt >>>> Pages : 48 >>>> Date : 2013-03-25 >>>> Abstract: >>>> When routing devices rely on modems to effect communications over >>>> wireless links, they need timely and accurate knowledge of the >>>> characteristics of the link (speed, state, etc.) in order to make >>>> forwarding decisions. In mobile or other environments where these >>>> characteristics change frequently, manual configurations or the >>>> inference of state through routing or transport protocols does not >>>> allow the router to make the best decisions. A bidirectional, event- >>>> driven communication channel between the router and the modem is >>>> necessary. >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-manet-dlep-04 >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-04 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Fri May 3 07:18:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE9E21F8BDE for ; Fri, 3 May 2013 07:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, 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 1iBNYZW381Se for ; Fri, 3 May 2013 07:18:55 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id CD2EE21F919D for ; Fri, 3 May 2013 07:18:54 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so1384521vbb.37 for ; Fri, 03 May 2013 07:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type; bh=YW1gNjcfkgrVMJGhy9J4n0eckESx44PbvGLEujaTZuc=; b=B5fcovbnEBPRpdxVfHMewOldEv9RmC37wSjuKwlFGThDs9Zv9dBQ+xsSR95lRTGF3A BWe8uaA1pIUI/uHb5HFU4zNlX/GN5wGqrGR4X5ygdtyFa6M3k+IOzQ6mLnHKkeLocaEd Okg+Ybb2wq2hRmtx+DgUrDeLDGWsXyPILqidM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:from:mime-version:in-reply-to:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=YW1gNjcfkgrVMJGhy9J4n0eckESx44PbvGLEujaTZuc=; b=BHnd+TL6CjkoyAJcbvITfCFjHuahksNyCBOD1KkL+MAWLGVdr/wnqpAFequxtvPRQN w+iWiZ9QtqtKCn4ya3H9rgm6+WUOrwS0PTFHeH8r0nR2VqXiJj3/xBXCAF+9XSxaA6Ck PIlyoDJTs5CWS/0J17AZRxYzkP9jmB2/lCOvCwzohFh19t9Y+A+x5QD0GnJTwBw2nZNS Ly5gavrT5JPY0U/RoWOk0CrnQ4D2Kd6DZBeQgObs8juw9GxRD4HTyxm62D8eRN/gMHc2 3nG5nbk8x5z+ZYLO7gP0SjVOr1kbd6mPS/cq8gRH8JfSBXtZ1mZFdPaJpf1NSEZaxup7 VXKg== X-Received: by 10.52.164.163 with SMTP id yr3mr2671204vdb.76.1367590734147; Fri, 03 May 2013 07:18:54 -0700 (PDT) References: <000a01ce4436$3f94c440$bebe4cc0$@olddog.co.uk> <047c01ce47f8$e0c63270$a2529750$@olddog.co.uk> From: Ulrich Herberg Mime-Version: 1.0 (1.0) In-Reply-To: <047c01ce47f8$e0c63270$a2529750$@olddog.co.uk> Date: Fri, 3 May 2013 07:18:52 -0700 Message-ID: <-798697908701614284@unknownmsgid> To: "" Content-Type: multipart/alternative; boundary=001a11c24ec6e844f804dbd1076e X-Gm-Message-State: ALoCoQmZ/ArMLus+ddziF0KscZ8Wd2uFt0b1Sm7YFqf9b6BTYt2DMFERExM0FMLIu5BGKOhEQj33 Cc: manet , "draft-ietf-manet-olsrv2-mib@tools.ietf.org" Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 14:18:56 -0000 --001a11c24ec6e844f804dbd1076e Content-Type: text/plain; charset=ISO-8859-1 Thank you for the clarification. Best regards Ulrich On May 3, 2013, at 5:22 AM, Adrian Farrel wrote: Hello, How nice to be sending email to the MANET list again after such a long time away :-) AB is right that the text was removed from section 9 (Applicability Statement) and not the Security Considerations section (section 8). Ulrich is right that the text was out of place. The text in section 9 of -06 read: OLSRv2 is designed to allow routers to leverage information on discovered routers and generate unicast routing paths within the MANET. While this is undoubtedly true, it has nothing to do with the applicability of the MIB module defined in this document. That is the purpose of Section 9. Section 4 provides a brief overview of OLSRv2 (obviously deferring to draft-ietf-manet-olsrv2) and *that* is the correct place for a description of the purpose/function of OLSRv2. Re-reading section 4 I find it already has plenty of description of OLSRv2 without the need to explicitly include the text deleted from section 9. That is consistent with the review I did of the changes present in -07 before I put the document on the IESG agenda. So I am comfortable with things going forward as they are. In general, document editors have latitude to make textual edits that do not change the protocol specification in a document. At the extreme end of the spectrum, you would not expect an editor to seek working group consensus (two week poll of the WG called and judged by the chairs) on the placement of a comma or fixing a spelling mistake. Thus, the removal of this sort of misplaced text is easily within scope of what they can do without explaining themselves to the WG. Each new revision of a document is notified to the WG, and the diff files are easily available. Indeed, the announcement notice includes a link to the diff. Thus, those who are interested (and not everyone in the WG is interested in every document) can easily check what has happened. The pragmatic approach to document development is for the editors/authors to lead, and for the WG to pull them back if they have concerns. usually, the editors/authors will discuss the concerns that have been raised hoping to reach agreement/compromise. If there is need, the editors will ask the chairs to call consensus. Thanks, Adrian *From:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] *Sent:* 03 May 2013 11:02 *To:* Ulrich Herberg *Cc:* adrian; draft-ietf-manet-olsrv2-mib@tools.ietf.org; manet *Subject:* Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06 Hi Ulrich, Section 9 is not titled security consideration, that is section 8. The delete was in section 9. However, I agree to leave it to the AD or manet co-chair decisions, Best Regards AB On Thu, May 2, 2013 at 3:34 PM, Ulrich Herberg wrote: AB, I let Adrian reply if he thinks the changes are significant enough to warrant a new WGLC. I think this is not the case. The sentence was probably a copy&paste mistake and does not provide any value in the Security Considerations section. Best regards Ulrich On Wed, May 1, 2013 at 11:00 AM, Abdussalam Baryun wrote: > I didn't think it was out of place. However, I thought/hope no words deletes > should occur after WGLC only if discussed (your delete was not discussed on > list until my input). Do I have to review all versions updated after WGLC? > some people may not, they may think it will be discussed to update I-Ds. > > AB > > > > On Tue, Apr 30, 2013 at 7:23 PM, Ulrich Herberg wrote: >> >> AB, >> >> this sentence was out-of-place in section 9 and not related to >> security considerations. >> >> Best regards >> Ulrich >> >> On Tue, Apr 30, 2013 at 10:58 AM, Abdussalam Baryun >> wrote: >> > Not sure in new version -07 why deleted some words/statement in section >> > 9. >> > >> > AB >> > >> > >> > >> > On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg >> > wrote: >> >> >> >> Adrian, >> >> >> >> yes, that was my intention...but sometimes, good intentions are not >> >> enough >> >> ;-) >> >> >> >> I have submitted a new revision with the one-word change that Benoit >> >> requested. >> >> >> >> Best regards >> >> Ulrich >> >> >> >> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel >> >> wrote: >> >> > Hi Ulrich, >> >> > >> >> > Did you intend to post a new revision to make this change? >> >> > >> >> > Thanks, >> >> > Adrian >> >> > >> >> >> -----Original Message----- >> >> >> From: Ulrich Herberg [mailto:ulrich@herberg.name] >> >> >> Sent: 15 April 2013 21:11 >> >> >> To: Benoit Claise >> >> >> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Farrel; >> >> > pm-dir@ietf.org; >> >> >> manet@ietf.org >> >> >> Subject: Re: [manet] performance metrics directorate review of >> >> >> draft-ietf- >> >> >> manet-olsrv2-mib-06 >> >> >> >> >> >> Benoit, >> >> >> >> >> >> thank you very much for this review. I agree that using the term >> >> >> "performance information" instead of "performance metrics" is a good >> >> >> idea. We will make the change. >> >> >> >> >> >> Best regards >> >> >> Ulrich >> >> >> >> >> >> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise >> >> >> wrote: >> >> >> > Dear all, >> >> >> > >> >> >> > I reviewed >> >> >> > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, >> >> >> > from a >> >> >> > performance metric directorate point of view. >> >> >> > >> >> >> > This draft doesn't contain any reference to RFC6390, but contains >> >> >> > "performance metric". Hence this review was triggered. For details >> >> >> > about the >> >> >> > directorate, see >> >> >> > http://www.ietf.org/iesg/directorate/performance-metrics.html >> >> >> > >> >> >> > >> >> >> > Definition of Managed Objects for the Optimized Link State >> >> >> > Routing >> >> >> > Protocol version 2 >> >> >> > >> >> >> > 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 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. >> >> >> > >> >> >> > >> >> >> > Basically, all performance metrics come from this table: >> >> >> > >> >> >> > o olsrv2InterfacePerfTable - records performance counters for >> >> >> > each >> >> >> > active OLSRv2 interface on this device. selected path to >> >> >> > each >> >> >> > destination for which any such path is known. This table >> >> >> > has >> >> >> > AUGMENTS { nhdpInterfacePerfEntry } and as such it is >> >> >> > indexed >> >> >> > via >> >> >> > nhdpIfIndex from the NHDP-MIB. >> >> >> > >> >> >> > NHDP-MIB is RFC 6779: >> >> >> > NhdpInterfacePerfEntry ::= >> >> >> > SEQUENCE { >> >> >> > nhdpIfHelloMessageXmits >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageRecvd >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedSize >> >> >> > Counter64, >> >> >> > nhdpIfHelloMessageRecvdAccumulatedSize >> >> >> > Counter64, >> >> >> > nhdpIfHelloMessageTriggeredXmits >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessagePeriodicXmits >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount >> >> >> > Counter32, >> >> >> > nhdpIfHelloMessageXmitAccumulatedLostNeighborCount >> >> >> > Counter32 >> >> >> > } >> >> >> > >> >> >> > >> >> >> > This draft contains similar objects in olsrv2InterfacePerfTable : >> >> >> > >> >> >> > Olsrv2InterfacePerfEntry ::= >> >> >> > SEQUENCE { >> >> >> > olsrv2IfTcMessageXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageRecvd >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageXmitAccumulatedSize >> >> >> > Counter64, >> >> >> > olsrv2IfTcMessageRecvdAccumulatedSize >> >> >> > Counter64, >> >> >> > olsrv2IfTcMessageTriggeredXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessagePeriodicXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageForwardedXmits >> >> >> > Counter32, >> >> >> > olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount >> >> >> > Counter32 >> >> >> > } >> >> >> > >> >> >> > >> >> >> > Personally, I don't believe that those objects should be subject >> >> >> > to >> >> >> > the RFC >> >> >> > 6390 template definition. (Performance Metric Definition Template, >> >> >> > section >> >> >> > 5.4.4, RFC 6390). >> >> >> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was >> >> >> > not >> >> >> > subject to it >> >> >> > Second reason: these objects are not really performance metrics, >> >> >> > but >> >> >> > mainly >> >> >> > basic monitoring objects. >> >> >> > >> >> >> > Since RFC 6779 uses the term performance information (in the >> >> >> > abstract), I >> >> >> > would propose that draft-ietf-manet-olsrv2-mib also uses this >> >> >> > term, >> >> >> > and not >> >> >> > the "performance metric". That would avoid some confusion. >> >> >> > However, >> >> >> keeping >> >> >> > the olsrv2InterfacePerfTable OID name is perfectly fine, for >> >> >> > consistency >> >> >> > reason with RFC 6779. >> >> >> > >> >> >> > Regards, Benoit >> >> >> > >> >> >> > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > manet mailing list >> >> >> > manet@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/manet >> >> >> > >> >> > >> >> _______________________________________________ >> >> manet mailing list >> >> manet@ietf.org >> >> https://www.ietf.org/mailman/listinfo/manet >> > >> > >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www.ietf.org/mailman/listinfo/manet >> > > > --001a11c24ec6e844f804dbd1076e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for the clarification.

Best regards
Ulrich

On May 3, 2013, at 5:22 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Hello,

=A0

How nice to be sending em= ail to the MANET list again after such a long time away :-)

=A0

AB is right that the text was removed from section 9 (Appli= cability Statement) and not the Security Considerations section (section 8)= .

=A0

Ulrich is right that the text was ou= t of place.

=A0

The text in section 9 of -06 read:

=A0=A0 OLSRv2 is designed to allow routers to leverage information on

<= p class=3D"MsoNormal"> =A0=A0 discovered routers and= generate unicast routing paths within the

=A0=A0 MANET.

=A0

While this is undoubtedly true, it h= as nothing to do with the applicability of the MIB module defined in this d= ocument. That is the purpose of Section 9.

=A0

Section 4 provides a brief overview = of OLSRv2 (obviously deferring to draft-ietf-manet-olsrv2) and *that* is th= e correct place for a description of the purpose/function of OLSRv2. Re-rea= ding section 4 I find it already has plenty of description of OLSRv2 withou= t the need to explicitly include the text deleted from section 9.

=A0

That is consistent with the review I= did of the changes present in -07 before I put the document on the IESG ag= enda. So I am comfortable with things going forward as they are.

=A0

In general, document editors have la= titude to make textual edits that do not change the protocol specification = in a document. At the extreme end of the spectrum, you would not expect an = editor to seek working group consensus (two week poll of the WG called and = judged by the chairs) on the placement of a comma or fixing a spelling mist= ake. Thus, the removal of this sort of misplaced text is easily within scop= e of what they can do without explaining themselves to the WG.

=A0

Each new revision of a document is n= otified to the WG, and the diff files are easily available. Indeed, the ann= ouncement notice includes a link to the diff. Thus, those who are intereste= d (and not everyone in the WG is interested in every document) can easily c= heck what has happened.

=A0

The pragmatic approach to document d= evelopment is for the editors/authors to lead, and for the WG to pull them = back if they have concerns. usually, the editors/authors will discuss the c= oncerns that have been raised hoping to reach agreement/compromise. If ther= e is need, the editors will ask the chairs to call consensus.

=A0

Thanks,

Adrian

=A0

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] <= br> Sent: 03 May 2013 11:02
To: Ulrich Herberg
Cc: a= drian; draft-= ietf-manet-olsrv2-mib@tools.ietf.org; manet
Subject: Re: [man= et] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-0= 6

=A0

= Hi Ulrich,

=A0

Section 9 is not titled security consideration, that is sect= ion 8. The delete was in section 9. However, I agree to leave it to the AD = or manet=A0co-chair decisions,

=A0

= Best Regards

AB

=A0

On Thu, May 2, 2013 at 3:34 PM, Ulrich Herberg <ulrich@herberg.name> wrote:

AB,

I let Adrian reply if he thinks the changes a= re significant enough to
warrant a new WGLC. I think this is not the case. The sentence was
proba= bly a copy&paste mistake and does not provide any value in the
Secur= ity Considerations section.

Best regards
Ulrich

On Wed, Ma= y 1, 2013 at 11:00 AM, Abdussalam Baryun

<abdussalambaryun@gmail.com> wrote:
> I didn't thin= k it was out of place. However, I thought/hope no words deletes
> sho= uld occur after WGLC only if discussed (your delete was not discussed on > list until my input). Do I have to review all versions updated after W= GLC?
> some people may not, they may think it will be discussed to up= date I-Ds.
>
> AB
>
>
>
> On Tue, Apr 3= 0, 2013 at 7:23 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
>>
>> AB,
>>
>> this sentence was out-of-p= lace in section 9 and not related to
>> security considerations.>>
>> Best regards
>> Ulrich
>>
>&= gt; On Tue, Apr 30, 2013 at 10:58 AM, Abdussalam Baryun
>> <abdussalambaryun= @gmail.com> wrote:
>> > Not sure in new version -07 why = deleted some words/statement in section
>> > 9.
>> >= ;
>> > AB
>> >
>> >
>> >
>= > > On Mon, Apr 29, 2013 at 8:17 PM, Ulrich Herberg <ulrich@herberg.name>
>> > wrot= e:
>> >>
>> >> Adrian,
>> >>
>= > >> yes, that was my intention...but sometimes, good intentions a= re not
>> >> enough
>> >> ;-)
>> >= ;>
>> >> I have submitted a new revision with the one-word change = that Benoit
>> >> requested.
>> >>
>>= ; >> Best regards
>> >> Ulrich
>> >> >> >> On Sun, Apr 28, 2013 at 10:31 AM, Adrian Farrel <adrian@olddog.co.uk>
>> &= gt;> wrote:
>> >> > Hi Ulrich,
>> >> &g= t;
>> >> > Did you intend to post a new revision to make this c= hange?
>> >> >
>> >> > Thanks,
>&= gt; >> > Adrian
>> >> >
>> >> >= ;> -----Original Message-----
>> >> >> From: Ulrich Herberg [mailto:ulrich@herberg.name]
>> >> >> = Sent: 15 April 2013 21:11
>> >> >> To: Benoit Claise >> >> >> Cc: draft-ietf-manet-olsrv2-mib@tools.ietf.org; Adrian Fa= rrel;
>> >> > pm-dir@i= etf.org;
>> >> >> manet@ietf.org=
>> >> >> Subject: Re: [manet] performance metrics= directorate review of
>> >> >> draft-ietf-
>>= ; >> >> manet-olsrv2-mib-06
>> >> >>
>> >> >> Benoit,
>>= ; >> >>
>> >> >> thank you very much for t= his review. I agree that using the term
>> >> >> "= ;performance information" instead of "performance metrics" i= s a good
>> >> >> idea. We will make the change.
>> >&= gt; >>
>> >> >> Best regards
>> >>= ; >> Ulrich
>> >> >>
>> >> >&g= t; On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <bclaise@cisco.com>
>> >> >> wrote:
>> >> >> > Dear a= ll,
>> >> >> >
>> >> >> > I= reviewed
>> >> >> > http://tools.ietf= .org/html/draft-ietf-manet-olsrv2-mib-06,
>> >> >> > from a
>> >> >> > p= erformance metric directorate point of view.
>> >> >> = >
>> >> >> > This draft doesn't contain any = reference to RFC6390, but contains
>> >> >> > "performance metric". Hence this = review was triggered. For details
>> >> >> > about = the
>> >> >> > directorate, see
>> >>= ; >> > http://www.ietf.org/iesg/directorate/perfo= rmance-metrics.html
>> >> >> >
>> >> >> >
>&= gt; >> >> > Definition of Managed Objects for the =A0Optimiz= ed Link State
>> >> >> > Routing
>> >&g= t; >> > Protocol version 2
>> >> >> >
>> >> >> > Abstract=
>> >> >> >
>> >> >> > =A0 = =A0This document defines the Management Information Base (MIB)
>> = >> >> > module
>> >> >> > =A0 =A0for configuring and managing the Opt= imized Link State Routing
>> >> >> > =A0 =A0protoco= l version 2 (OLSRv2). =A0The OLSRv2-MIB module is
>> >> >= > > structured
>> >> >> > =A0 =A0into state information, performance = metrics, and notifications.
>> >> >> > This
>= > >> >> > =A0 =A0additional state and performance informa= tion is useful to
>> >> >> > =A0 =A0troubleshoot problems and performanc= e issues of the routing
>> >> >> > protocol.
>= ;> >> >> > =A0 =A0Different levels of compliance allow im= plementers to use
>> >> >> > smaller
>> >> >> > = =A0 =A0subsets of all defined objects, allowing for this MIB module to
&= gt;> >> >> > be
>> >> >> > =A0 = =A0deployed on more constrained routers.
>> >> >> >
>> >> >> >
>&= gt; >> >> > Basically, all performance metrics come from thi= s table:
>> >> >> >
>> >> >> &= gt; =A0 =A0o =A0olsrv2InterfacePerfTable - records performance counters for=
>> >> >> > each
>> >> >> > =A0= =A0 =A0 active OLSRv2 interface on this device. selected path to
>&g= t; >> >> > each
>> >> >> > =A0 =A0 = =A0 destination for which any such path is known. =A0This table
>> >> >> > has
>> >> >> > =A0 = =A0 =A0 AUGMENTS { nhdpInterfacePerfEntry } and as such it is
>> &= gt;> >> > indexed
>> >> >> > via
>= ;> >> >> > =A0 =A0 =A0 nhdpIfIndex from the NHDP-MIB.
>> >> >> >
>> >> >> > NHDP-MIB= is RFC 6779:
>> >> >> > =A0 =A0NhdpInterfacePerfEn= try ::=3D
>> >> >> > =A0 =A0 =A0 SEQUENCE {
>= > >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmits
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>&= gt; >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageRecvd
&g= t;> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>>= ; >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAccumulat= edSize
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter64,
>&= gt; >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageRecvdAccumu= latedSize
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counte= r64,
>> >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessa= geTriggeredXmits
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>&= gt; >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessagePeriodicXmi= ts
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,>> >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitA= ccumulatedSymmetricNeighborCount
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32,
>&= gt; >> >> > =A0 =A0 =A0 =A0 =A0nhdpIfHelloMessageXmitAccumul= atedHeardNeighborCount
>> >> >> > =A0 =A0 =A0 =A0 = =A0 =A0 Counter32,
>> >> >> > =A0 =A0 =A0 =A0 =A0nh= dpIfHelloMessageXmitAccumulatedLostNeighborCount
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 Counter32
>&g= t; >> >> > =A0 =A0 =A0 }
>> >> >> ><= br>>> >> >> >
>> >> >> > This = draft contains similar objects in olsrv2InterfacePerfTable :
>> >> >> >
>> >> >> > =A0 =A0 = Olsrv2InterfacePerfEntry ::=3D
>> >> >> > =A0 =A0 = =A0 =A0SEQUENCE {
>> >> >> > =A0 =A0 =A0 =A0 =A0 ol= srv2IfTcMessageXmits
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
&g= t;> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageRecvd>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
&= gt;> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageXmitAcc= umulatedSize
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter64,
&g= t;> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageRecvdAcc= umulatedSize
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0= Counter64,
>> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfT= cMessageTriggeredXmits
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
&g= t;> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessagePeriodic= Xmits
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter= 32,
>> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessag= eForwardedXmits
>> >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0Counter32,
&g= t;> >> >> > =A0 =A0 =A0 =A0 =A0 olsrv2IfTcMessageXmitAccu= mulatedMPRSelectorCount
>> >> >> > =A0 =A0 =A0 =A0 = =A0 =A0 =A0Counter32
>> >> >> > =A0 =A0 =A0 =A0} >> >> >> >
>> >> >> >
>&= gt; >> >> > Personally, I don't believe that those objec= ts should be subject
>> >> >> > to
>> >= > >> > the RFC
>> >> >> > 6390 template definition. (Performance Metr= ic Definition Template,
>> >> >> > section
>&= gt; >> >> > 5.4.4, RFC 6390).
>> >> >> = > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was
>> >> >> > not
>> >> >> > subj= ect to it
>> >> >> > Second reason: these objects a= re not really performance metrics,
>> >> >> > but >> >> >> > mainly
>> >> >> > b= asic monitoring objects.
>> >> >> >
>> >= ;> >> > Since RFC 6779 uses the term performance information (i= n the
>> >> >> > abstract), I
>> >> >> = > would propose that draft-ietf-manet-olsrv2-mib also uses this
>&= gt; >> >> > term,
>> >> >> > and not=
>> >> >> > the "performance metric". That wo= uld avoid some confusion.
>> >> >> > However,
&g= t;> >> >> keeping
>> >> >> > the ols= rv2InterfacePerfTable OID name is perfectly fine, for
>> >> >> > consistency
>> >> >> &= gt; reason with RFC 6779.
>> >> >> >
>> &g= t;> >> > Regards, Benoit
>> >> >> >
>> >> >> >
>> >> >> >
>&= gt; >> >> > _______________________________________________<= br>>> >> >> > manet mailing list
>> >> = >> > manet@ietf.org
>> >> >> > https://www.ietf.org/mailman/listinfo/manet<= /a>
>> >> >> >
>> >> >
>>= ; >> _______________________________________________
>> >> manet mailing list
>> >> manet@ietf.org
>> >> https://www.ietf.or= g/mailman/listinfo/manet
>> >
>> >
>> >
>> > __________= _____________________________________
>> > manet mailing list>> > manet@ietf.org
>= ;> > https://www.ietf.org/mailman/listinfo/manet
>> >
>
>

= =A0

--001a11c24ec6e844f804dbd1076e-- From adrian@olddog.co.uk Sun May 5 14:46:21 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5A421F9779 for ; Sun, 5 May 2013 14:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, 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 Pu7rslWaKlug for ; Sun, 5 May 2013 14:46:04 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id C2BF621F9734 for ; Sun, 5 May 2013 14:46:03 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r45Lk2pm001558 for ; Sun, 5 May 2013 22:46:02 +0100 Received: from 950129200 (no-reverse-dns.mlnet.ie [31.216.236.149] (may be forged)) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r45Lk1Aw001540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 5 May 2013 22:46:01 +0100 From: "Adrian Farrel" To: References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> In-Reply-To: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> Date: Sun, 5 May 2013 22:45:59 +0100 Message-ID: <001301ce49d9$eef2e630$ccd8b290$@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: AQLIbQ6H1IyDn7st8lVcjlz0X0EuDZcC2ZJA Content-Language: en-gb Subject: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 21:46:21 -0000 heads up > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: 05 May 2013 16:15 > To: i-d-announce@ietf.org > Cc: ospf@ietf.org > Subject: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP Working Group of > the IETF. > > Title : Use of OSPF-MDR in Single-Hop Broadcast Networks > Author(s) : Richard G. Ogier > Filename : draft-ietf-ospf-manet-single-hop-mdr-02.txt > Pages : 6 > Date : 2013-05-05 > > 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 IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ospf-manet-single-hop-mdr-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-manet-single-hop-mdr-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From abdussalambaryun@gmail.com Tue May 7 02:36:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC93321F859D for ; Tue, 7 May 2013 02:36:27 -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 59so90dvGa1E for ; Tue, 7 May 2013 02:36:27 -0700 (PDT) Received: from mail-da0-x229.google.com (mail-da0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2722821F859B for ; Tue, 7 May 2013 02:36:26 -0700 (PDT) Received: by mail-da0-f41.google.com with SMTP id y19so233335dan.28 for ; Tue, 07 May 2013 02:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ypy8IwX5fpqpoytLePR8EtQEYLTYEVNcxK+TKD3fNh4=; b=uNj5jfk9bQdDVhZ1100VjnWH7eYBkrz+h9X5xJK10V6aIOTVdhmYjomPoT58t3KHuW asKdIp+TBIYIe6hv2mHGYMxrs7R0VAS/fTFDASpDE5YP8d/hdthyxHoWo0+x91fvOEFh engRR+dF9HELWSDgvLD9jqs7m/KYwT+c+E/NiSphd2h8Zzua/KYdkY50PSDADryzAcpR tC8wRdSP0TMkt00TIVQdg2FEdoP/06d5LuiXCVvYE9b0d0zfxkGgAD72VhzOsPb8Ef2S Xe2o4LHmXCaU72jBrq6uBYyNOoiwLMhls3XqQqMJv2Aj6Oe/kuGZ+QKKAbN40oCaCmRO 2cAQ== MIME-Version: 1.0 X-Received: by 10.66.74.226 with SMTP id x2mr1889903pav.190.1367919384869; Tue, 07 May 2013 02:36:24 -0700 (PDT) Received: by 10.68.230.35 with HTTP; Tue, 7 May 2013 02:36:24 -0700 (PDT) In-Reply-To: <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> Date: Tue, 7 May 2013 11:36:24 +0200 Message-ID: From: Abdussalam Baryun To: rich.ogier@earthlink.net Content-Type: text/plain; charset=ISO-8859-1 Cc: manet@ietf.org Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 09:36:27 -0000 Hi Ogier, I was interested to find the RFC5444 format (MANET messaging format) in the I-D. The document is for the manet case so why does it not use RFC5444 in its work? Do you think using RFC5444 is not a good idea in this I-D, please explain? AB On 5/5/13, Adrian Farrel wrote: > heads up > >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] >> On Behalf Of internet-drafts@ietf.org >> Sent: 05 May 2013 16:15 >> To: i-d-announce@ietf.org >> Cc: ospf@ietf.org >> Subject: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Open Shortest Path First IGP Working >> Group > of >> the IETF. >> >> Title : Use of OSPF-MDR in Single-Hop Broadcast Networks >> Author(s) : Richard G. Ogier >> Filename : draft-ietf-ospf-manet-single-hop-mdr-02.txt >> Pages : 6 >> Date : 2013-05-05 >> >> 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 IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ospf-manet-single-hop-mdr-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-manet-single-hop-mdr-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From emmanuel.baccelli@gmail.com Tue May 7 02:42:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C243821F898A for ; Tue, 7 May 2013 02:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_ABOUTYOU=0.5, 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 DyCtyq2xk4Zw for ; Tue, 7 May 2013 02:42:24 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF1921F8972 for ; Tue, 7 May 2013 02:42:24 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id eh20so304808obb.41 for ; Tue, 07 May 2013 02:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=p71wTNuAOBuW+gT+bpVoB/gxGVQkxYF+zO822aYof/o=; b=0rnxz+P6iHukAOXAgSB1VqNPePuR8DA8zxgcHhzk5/1aeeXVzBdukd8JjLOjqlijUS AE/N8MLftMajaMRGXkZmm6k/oOlYl6uC7y7kq3xa5X47o7VSeAsyK06+Xvy5csAHqZKK gxJGIiKjLWrIL2BtH9tn61owrd+LSJ78oQdERVRbTjaYE7dc5ESpagfQST9d66Ck2+Rg VZS5v1dxEJLxaZ4lNHJmiigt9txv6RkAZpxcIqQchluh02XHhY4w6kVXOrCaJ3BNopl8 gtSw25ZwSTTi1z4jLnXJpdoHJ20LQUIJIb5F3us/uVwFNWB0dgCismMAjYjL4OTgL2E1 ol+w== X-Received: by 10.60.56.168 with SMTP id b8mr345629oeq.5.1367919743848; Tue, 07 May 2013 02:42:23 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.100.196 with HTTP; Tue, 7 May 2013 02:42:03 -0700 (PDT) From: Emmanuel Baccelli Date: Tue, 7 May 2013 11:42:03 +0200 X-Google-Sender-Auth: UV3i5Zilde3XUi9-TEWA9JvqglU Message-ID: To: MANET IETF Content-Type: multipart/alternative; boundary=089e0149ca9669d54804dc1da210 Subject: [manet] Extension - MANIAC Challenge 2013 - Call for Papers/Coding X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 09:42:25 -0000 --089e0149ca9669d54804dc1da210 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks, we know that programmers are always late and therefore extend the deadline for the MANIAC Challenge 2013 until May 17, 2013. Note that we are not asking for a full conference submission. The focus of the Challenge is coding and clever strategies for offloading. Two weeks should be enough time to prepare a two page abstract sketching preliminary ideas about your mobile offloading strategy! The MANIAC Challenge is co-located with the 87th IETF/IRTF meeting in Berlin. MANIAC participants get free entrance to the IETF/IRTF. Winners of the challenge will be announced at the IRTF open meeting. Nice chance to present cool ideas in an inspiring environment! Make your students aware! You like to work on mobile ad hoc networking? You like to code? You like to compete? Join us and consider the following Call for Papers and Hacking! ** Call for Short Papers for the 3rd MANIAC Challenge ** Co-located with the 87th IETF meeting in Berlin, Germany July 27 - August 2, 2013 http://2013.maniacchallenge.org Sponsored by: Google, ISOC, IETF, IRTF, ANR, and BMBF The MANIAC Challenge is a competition to better understand cooperation and interoperability in ad hoc networks. Competing teams students/researchers come together to form a wireless ad hoc network, while simultaneously connected to a backbone of access points. The organizers will generate traffic coming from the backbone, destined to somewhere in the network. A hop-by-hop bidding contest decides the path of each data packet towards its destination. Each team usually consists of two to three people. Teams will be judged based on how much of the traffic they relay gets to its destination. To get their traffic across the network, each team must rely on other teams willingness to forward traffic for them. We have developed software and an API over Android to allow teams to program their nodes, in particular override forwarding decisions made by the routing protocol and participate in the hop-by-hop bidding contest. ------------------------------------------------ Topic of 3rd MANIAC Challenge: Mobile Offloading ------------------------------------------------ The specific focus of the MANIAC Challenge 2013 is on developing and comparatively evaluating strategies to offload infrastructure access points via customer ad hoc forwarding using handhelds (e.g., smartphones, tablets). The incentive for customers is discounted monthly fees, and the incentive for operators is decreased infrastructure costs. The idea is to demonstrate scenarios/strategies that do not degrade user experience while offering significant mobile offloading on the infrastructure. Details about the scenario and competition rules are available at http://2013.maniacchallenge.org/rules-setup. ---------- Submission ---------- We solicit the submission of short papers (max. 2 pages IEEE double-column format) describing strategies for mobile offloading. After being peer-reviewed, authors of selected submissions will be invited to participate in the MANIAC Challenge and to attend the IETF meeting. We highly encourage authors to continue the development of the offloading strategy during the review time. Please, submit your short paper via email to maniac2013@lists.fu-berlin.de. ------------- Participation ------------- Author participation will consist in attending the MANIAC Challenge in Berlin, Germany, July 27 - 28, 2013. Authors are also invited to attend the IETF/IRTF meeting July 28 - August 2, 2013. Participation in the MANIAC Challenge is free of charge. Registration costs (at full-time student rate) for the IETF/IRTF meeting are sponsored by ISOC. Authors bring an implementation of the strategy described in the paper submitted by the author, running on the common API and the common hardware used for the event: the Nexus 7 tablet. The MANIAC API and software will be released with the notification of acceptance. Hardware will be provided by the organizers if necessary. Each participant will then concurrently run its strategy during the contest, taking place on July 27th at the Freie Universit=E4t Berlin. The following day, a workshop will take place at the IETF venue, where we will summarize and discuss the results of the contest. The winners of the MANIAC Challenge 2013 will be announced during the IRTF Open Meeting, which is part of the IETF/IRTF week with high visibility. The IRTF Open Meeting usually will be attended by more than 100 experts from industry and academia working on Internet Engineering. Winners will take home some prizes to be determined with sponsors. Competin= g teams will be provided complimentary IETF registration enabling them to attend the 87th IETF meeting in Berlin, July 28 - August 2nd. Details about the submission and participation are available at http://2013.maniacchallenge.org/participation/ ------------ Mailing List ------------ If you are interested in the MANIAC Challenge 2013, please subscribe to the mailing list maniac2013-info@lists.fu-berlin.de. We will inform you about updates. https://lists.fu-berlin.de/listinfo/maniac2013-info#subscribe --------------- Important Dates --------------- - Deadline for short paper submission: May 17, 2013 (extended) - Notification of acceptance: May 20, 2013 (extended) - Release of API and software: May 12, 2013 - MANIAC challenge dates: July 27 - 28, 2013 - IETF/IRTF meeting: July 28 - August 2, 2013 ---------------- MANIAC Co-Chairs ---------------- - Emmanuel Baccelli (INRIA) - Oliver Hahm (INRIA) - Felix Juraschek (Freie Universit=E4t Berlin) - Thomas Schmidt (HAW Hamburg) - Heiko Will (Freie Universit=E4t Berlin) - Matthias W=E4hlisch (Freie Universit=E4t Berlin) ------- Contact ------- For questions, please contact maniac2013@lists.fu-berlin.de --089e0149ca9669d54804dc1da210 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Folks,

we know that programm= ers are always late and therefore extend the
deadline for the MAN= IAC Challenge 2013 until May 17, 2013. Note that we
are not askin= g for a full conference submission. The focus of the
Challenge is coding and clever strategies for offloading.
Two weeks should be enough time to prepare a two page abstract= sketching
preliminary ideas about your mobile offloading strateg= y!

The MANIAC Challenge is co-located with the 87th IETF/I= RTF meeting in
Berlin. MANIAC participants get free entrance to t= he IETF/IRTF. Winners
of the challenge will be announced at the I= RTF open meeting.

Nice chance to present cool ideas in an inspiring envir= onment! Make your
students aware!

You li= ke to work on mobile ad hoc networking?
You like to code?
You like to compete?
Join us and consider the following Call= for Papers and Hacking!


=A0 =A0 = =A0 =A0 ** =A0Call for Short Papers for the 3rd MANIAC Challenge =A0**

=A0 =A0 =A0 =A0 =A0Co-located with the 87th IETF meeting in Berl= in, Germany
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 July 27 -= August 2, 2013

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0http://2013.maniacchallenge.= org

=A0 =A0 =A0 =A0 =A0Sponsored by: Google, ISOC, IETF, IR= TF, ANR, and BMBF

The MANIAC Challenge is a compet= ition to better understand cooperation and
interoperability in ad= hoc networks. Competing teams students/researchers
come together to form a wireless ad hoc network, while simultaneously<= /div>
connected to a backbone of access points. The organizers will gen= erate
traffic coming from the backbone, destined to somewhere in = the network. A
hop-by-hop bidding contest decides the path of each data packet toward= s its
destination.

Each team usually con= sists of two to three people. Teams will be judged
based on how m= uch of the traffic they relay gets to its destination. To get
their traffic across the network, each team must rely on other teams
willingness to forward traffic for them. We have developed softwar= e and an
API over Android to allow teams to program their nodes, = in particular
override forwarding decisions made by the routing protocol and partici= pate
in the hop-by-hop bidding contest.

= ------------------------------------------------
Topic of 3rd MAN= IAC Challenge: Mobile Offloading
------------------------------------------------

<= div>The specific focus of the MANIAC Challenge 2013 is on developing and
comparatively evaluating strategies to offload infrastructure acces= s points
via customer ad hoc forwarding using handhelds (e.g., smartphones,
tablets). The incentive for customers is discounted monthly fees, an= d the
incentive for operators is decreased infrastructure costs. = The idea is to
demonstrate scenarios/strategies that do not degrade user experience w= hile
offering significant mobile offloading on the infrastructure= .
Details about the scenario and competition rules are available = at

----------
Submission
----------

We solicit t= he submission of short papers (max. 2 pages IEEE double-column
format) describing strategies for mobile offloading. After being
=
peer-reviewed, authors of selected submissions will be invited to
participate in the MANIAC Challenge and to attend the IETF meeting. W= e
highly encourage authors to continue the development of the offloading=
strategy during the review time.

Please= , submit your short paper via email to maniac2013@lists.fu-berlin.de.

-------------
Participation
-------= ------

Author participation will consist in attend= ing the MANIAC Challenge in
Berlin, Germany, July 27 - 28, 2013. = Authors are also invited to attend the
IETF/IRTF meeting July 28 - August 2, 2013. Participation in the MANIA= C
Challenge is free of charge. Registration costs (at full-time s= tudent rate)
for the IETF/IRTF meeting are sponsored by ISOC.

Authors bring an implementation of the strategy describ= ed in the paper
submitted by the author, running on the common AP= I and the common hardware
used for the event: the Nexus 7 tablet.= The MANIAC API and software will be
released with the notification of acceptance. Hardware will be provide= d by
the organizers if necessary.

Each p= articipant will then concurrently run its strategy during the
contest, taking place on July 27th at the Freie Universit=E4t Berlin. The
following day, a workshop will take place at the IETF venue, where= we will
summarize and discuss the results of the contest.

The winners of the MANIAC Challenge 2013 will be announ= ced during the IRTF
Open Meeting, which is part of the IETF/IRTF = week with high visibility. The
IRTF Open Meeting usually will be = attended by more than 100 experts from
industry and academia working on Internet Engineering.

<= /div>
Winners will take home some prizes to be determined with sponsors= . Competing
teams will be provided complimentary IETF registratio= n enabling them to attend
the 87th IETF meeting in Berlin, July 28 - August 2nd.

<= /div>
Details about the submission and participation are available at


------------
Mailing List
------------

If you are interested in the MA= NIAC Challenge 2013, please subscribe to
the mailing list maniac2013-info@lists.fu-ber= lin.de. We will inform you
about updates.

---------------
Impo= rtant Dates=A0
---------------
=A0- =A0Deadline for short paper submission:= =A0 May 17, 2013 (extended)
=A0- =A0Notification of acceptance: = =A0 =A0 =A0 =A0 =A0 =A0May 20, 2013 (extended)
=A0- =A0Release of= API and software: =A0 =A0 =A0 =A0 =A0 May 12, 2013
=A0- =A0MANIAC challenge dates: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0July 27= - 28, 2013=A0
=A0- =A0IETF/IRTF meeting: =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 July 28 - August 2, 2013

--------= --------
MANIAC Co-Chairs=A0
----------------

=A0- Emmanuel Baccelli (INRI= A)
=A0- Oliver Hahm (INRIA)
=A0- Felix Juraschek (Freie= Universit=E4t Berlin)
=A0- Thomas Schmidt (HAW Hamburg)
=A0- Heiko Will (Freie Universit=E4t Berlin)
=A0- Matthias W=E4hlisch (Freie Universit=E4t Berlin)

-------
Contact
-------
For question= s, please contact maniac20= 13@lists.fu-berlin.de

--089e0149ca9669d54804dc1da210-- From henning.rogge@fkie.fraunhofer.de Tue May 7 03:41:43 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E4721F8C7D for ; Tue, 7 May 2013 03:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 Fv1h9HjEfUBX for ; Tue, 7 May 2013 03:41:38 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB521F8C1A for ; Tue, 7 May 2013 03:41:37 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UZfKx-0003cv-SU for manet@ietf.org; Tue, 07 May 2013 12:41:35 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] 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 ) id 1UZfKx-00011r-Po for manet@ietf.org; Tue, 07 May 2013 12:41:35 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 7 May 2013 12:41:35 +0200 Message-ID: <5188DA58.2080704@fkie.fraunhofer.de> Date: Tue, 7 May 2013 12:41:28 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000208090906060303020800" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17163/Tue May 7 09:58:45 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 2f486c1bd65b83532f5a9ca975ef026a Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 10:41:43 -0000 --------------ms000208090906060303020800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 05/07/2013 11:36 AM, Abdussalam Baryun wrote: > Hi Ogier, > I was interested to find the RFC5444 format (MANET messaging format) > in the I-D. The document is for the manet case so why does it not use > RFC5444 in its work? Do you think using RFC5444 is not a good idea in > this I-D, please explain? Read the title of the document again... you will notice the "OSPF". the OSPF Manet-Extension has been developed in the OSPF working group=20 using the OSPF message format. 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 --------------ms000208090906060303020800 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 Fw0xMzA1MDcxMDQxMzRaMCMGCSqGSIb3DQEJBDEWBBTn3QMDPEYX8SL4jf2fUxnRn6y+nDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAiLLIAX59hg4XZgKQzK5U9qMfBYjzn7CmnkqWhpKBmKR7 uwcAywVOApOK4k6fvCXpYFyF3gcUkLKbsiaqx2JUsyYz6yDd7XzeTdpoq6j0OjfIbPol2TjQ 0+zSwr5RN0xoUaIzfmyDV2SxfCKCqUs1KolYEPtju5W5M1jH4VnVRK8JzW3muR3r10FkSgZ1 iRodcr8U/4BRi7O6glxT7FV5t5ne95Yv0vlPVZWtT61baUkjWS4rvhpwwjkAFVk+Zd8BODbj FeAf6PgNERWOWAT9NIlqOJrAwYUI8YpSY1GCPrYgOCU6fNEtGY6iGufC/UN+g3hR4u3WBdT/ Hw5Viyn1TQAAAAAAAA== --------------ms000208090906060303020800-- From ulrich@herberg.name Tue May 7 08:11:08 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B302B21F86B2 for ; Tue, 7 May 2013 08:11:08 -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 xS1OTvXwda8I for ; Tue, 7 May 2013 08:11:07 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id ADFDE21F8D0D for ; Tue, 7 May 2013 08:11:07 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id w8so585453vbf.0 for ; Tue, 07 May 2013 08:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n4d4W1r3prqVVsSEyuLxEUKABq13V8VJfolp9ZG0sq0=; b=hTw9FW6U/hcHuddMYwkNfVlQQFr1KfXsAp+Ql10LSN+kNRUlHsta91NaV3Hc8Fctfj +H0b6paHL9CwNBNRf2QM5ssGLWdhu3kS39i10bwTm3cHuJR+WR+KBurYqTJyp9fwA73W 0X0ly7webqdWJLOnxcb6D1aKXmrxKuJshKprE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=n4d4W1r3prqVVsSEyuLxEUKABq13V8VJfolp9ZG0sq0=; b=g26VkzRla8fntdUkUlQw+DwAXjyKzSvLWTJvOKTrZVuvVxsdTPR34D7T0GfxLt9wno xTPWUUMNMPiI2Bq/ToGE1pvHqtJtyuLfubsYdmZTdtLtQAWuDVB/+VZGxYDKwEOkvO4m +lwU0CSBwYaXWKJrsGpoL2hVbO4z0yCRMhAPQkhbTtcCz+xjXsgYG9o7JP2Gp/de4/KC iYHsGF0E9do7gIWN3/NbrkUh2AHDTBkl3Byw/kG0EcyeNqDkUsumPXf1qe3fcJbmLenw auvvYelkR15LA1aIwaII0T3kbc787cm54GtUngl3BO1b5p3e0r1MI2jH5RFzzjVWIkp+ M3OA== MIME-Version: 1.0 X-Received: by 10.52.111.231 with SMTP id il7mr1279766vdb.96.1367939467101; Tue, 07 May 2013 08:11:07 -0700 (PDT) Received: by 10.220.13.195 with HTTP; Tue, 7 May 2013 08:11:06 -0700 (PDT) In-Reply-To: <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> Date: Tue, 7 May 2013 08:11:06 -0700 Message-ID: From: Ulrich Herberg To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmNCo7dMKgGXR+/JW9n8/FsO1STZ88l+Wt5ObRTLr9TLGRHE94+2kZC8R5RzA01L8jqNZ4F Cc: rich.ogier@earthlink.net, manet@ietf.org Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 15:11:08 -0000 Hi, I was wondering about the use case of this protocol. In which scenarios is this used / why is it useful? (that may have been clear from the discussions on the OSPF mailing list, which I have not followed). I think it could be helpful to write that in the draft, together with an applicability statement. You already mention the 2-layer meshing as example use case for when there is a single-hop MANET. Which other cases do you have in mind (given that radio ranges are typically different on different interfaces)? Since this draft is experimental, what kinds of experiments are planned to be conducted? Shouldn't that be described in the draft? "NOT RECOMMENDED" is missing in the terminology from 2119 (per errata). It could be helpful to give guidance about the 2119 terminology in section 2 (i.e., what are the consequences of not selecting a value for AdjConnectivity etc. for each of the SHOULD, MAY, SHOULD NOT). Best regards Ulrich On Sun, May 5, 2013 at 2:45 PM, Adrian Farrel wrote: > heads up > >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >> On Behalf Of internet-drafts@ietf.org >> Sent: 05 May 2013 16:15 >> To: i-d-announce@ietf.org >> Cc: ospf@ietf.org >> Subject: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> This draft is a work item of the Open Shortest Path First IGP Working Group > of >> the IETF. >> >> Title : Use of OSPF-MDR in Single-Hop Broadcast Networks >> Author(s) : Richard G. Ogier >> Filename : draft-ietf-ospf-manet-single-hop-mdr-02.txt >> Pages : 6 >> Date : 2013-05-05 >> >> 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 IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ospf-manet-single-hop-mdr-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-manet-single-hop-mdr-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Tue May 7 10:11:04 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957C121F93D8 for ; Tue, 7 May 2013 10:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 8FSKa6vy1qE5 for ; Tue, 7 May 2013 10:10:59 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 45CE421F89E2 for ; Tue, 7 May 2013 10:10:59 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp6so648703pab.35 for ; Tue, 07 May 2013 10:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=s+XYW/nsgVPiXSj5Xyx/A/30h7wXOv2Ex3Z31h7HBvs=; b=QF/EOhMZkEwNdj77i/SqSN3V6ylMf7pDIq5if2ht8FuGwoMM9qs6vyaF4dLgZEj39t VAbSGtDbbjk1x152MZPmDakiDqmqZnlxnZedXhlkiEc9FFuZCXAO5JQU6dUIoMz6qpUb NT5zj08Tr0etQK5UXr/O6fEp17EQJ7JiZY6QAhoKXuFHXxJ3VUoNG4muJFGsxI2lm3s8 fEIsXWyZh+RI/0rp1zselKq+GuM2CmNQwg6sMp93dYKVYIbzECYs1WfMTda8U6nJVPmz JybW4FOq3JaZOfglSsv71nIBxuxOpRtmKLNbDQv9ky8dQA8GakUQgbD3WDtyq0kSfbhv xcpw== MIME-Version: 1.0 X-Received: by 10.68.193.138 with SMTP id ho10mr3354097pbc.163.1367946659052; Tue, 07 May 2013 10:10:59 -0700 (PDT) Received: by 10.68.230.35 with HTTP; Tue, 7 May 2013 10:10:58 -0700 (PDT) In-Reply-To: <5188DA58.2080704@fkie.fraunhofer.de> References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> <5188DA58.2080704@fkie.fraunhofer.de> Date: Tue, 7 May 2013 18:10:58 +0100 Message-ID: From: Abdussalam Baryun To: manet Content-Type: multipart/alternative; boundary=047d7b15af43af470c04dc23e6fe Cc: draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:11:04 -0000 --047d7b15af43af470c04dc23e6fe Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 7, 2013 at 11:41 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > On 05/07/2013 11:36 AM, Abdussalam Baryun wrote: > >> Hi Ogier, >> I was interested to find the RFC5444 format (MANET messaging format) >> in the I-D. The document is for the manet case so why does it not use >> RFC5444 in its work? Do you think using RFC5444 is not a good idea in >> this I-D, please explain? >> > > Read the title of the document again... you will notice the "OSPF". > > the OSPF Manet-Extension has been developed in the OSPF working group > using the OSPF message format. > > > I understand that you prefer using OSPF fomat for the I-D, which I was thinking of RFC5444. I read I-D and the extension is for manet not others. IMO it is ok all WGs may work together for the best of IETF protocols or formats. IMO that a routing protocol X that wants to be extended for MANET cases SHOULD include additional messaging type considering rfc5444 format, but if that protocol has a reason why not to use RFC5444 then it will be understood, AB --047d7b15af43af470c04dc23e6fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, May 7, 2013 at 11:41 AM, Henning Rogge <henning.rogge@f= kie.fraunhofer.de> wrote:
On 05/07/2013 11:36 AM, Abdussalam Baryu= n wrote:
Hi Ogier,
I was interested to find the RFC5444 format (MANET messaging format)
in the I-D. The document is for the manet case so why does it not use
RFC5444 in its work? Do you think using RFC5444 is not a good idea in
this I-D, please explain?

Read the title of the document again... you will notice the "OSPF"= ;.

the OSPF Manet-Extension has been developed in the OSPF working group using= the OSPF message format.

=A0

I understand that = you prefer using OSPF fomat for the I-D, which I was thinking of RFC5444. I= read I-D and=A0the extension is for manet not others. IMO it=A0is ok all= =A0WGs may work together for the best of IETF protocols or formats. IMO tha= t a routing protocol X=A0 that wants to=A0be extended for MANET cases=A0SHO= ULD include additional messaging type considering rfc5444 format, but if th= at protocol has a reason why not to use RFC5444 then it will be understood,=
=A0
AB

--047d7b15af43af470c04dc23e6fe-- From Chris.Dearlove@baesystems.com Tue May 7 10:21:00 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6907421F84D8 for ; Tue, 7 May 2013 10:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 dQWO2fi74swz for ; Tue, 7 May 2013 10:20:55 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 623C821F84EF for ; Tue, 7 May 2013 10:20:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,629,1363132800"; d="scan'208,217";a="335324096" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 07 May 2013 18:20:53 +0100 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r47HKqwa022980 for ; Tue, 7 May 2013 18:20:52 +0100 X-IronPort-AV: E=Sophos;i="4.87,629,1363132800"; d="scan'208,217";a="15372075" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds017.greenlnk.net with ESMTP; 07 May 2013 18:20:52 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.02.0328.009; Tue, 7 May 2013 18:20:53 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , manet Thread-Topic: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt Thread-Index: AQHOSwZdCyizLUxTNE+cIX4dQ0rfCJj5eAsAgABs0wCAABMhUA== Date: Tue, 7 May 2013 17:20:52 +0000 Message-ID: References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> <5188DA58.2080704@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25068C34GLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org" Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:21:01 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25068C34GLKXM0002VGREEN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is an extension to OSPF. It is not a protocol to run on the manet UDP port/IP protocol as specified by RFC 5498. As such it isn't constrained to use RFC 5444. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: 07 May 2013 18:11 To: manet Cc: draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. On Tue, May 7, 2013 at 11:41 AM, Henning Rogge > wrote: On 05/07/2013 11:36 AM, Abdussalam Baryun wrote: Hi Ogier, I was interested to find the RFC5444 format (MANET messaging format) in the I-D. The document is for the manet case so why does it not use RFC5444 in its work? Do you think using RFC5444 is not a good idea in this I-D, please explain? Read the title of the document again... you will notice the "OSPF". the OSPF Manet-Extension has been developed in the OSPF working group using the OSPF message format. I understand that you prefer using OSPF fomat for the I-D, which I was thinking of RFC5444. I read I-D and the extension is for manet not others. IMO it is ok all WGs may work together for the best of IETF protocols or formats. IMO that a routing protocol X that wants to be extended for MANET cases SHOULD include additional messaging type considering rfc5444 format, but if that protocol has a reason why not to use RFC5444 then it will be understood, AB ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25068C34GLKXM0002VGREEN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

This is an extension to OSPF. It is not a protocol to run on the manet UDP port/IP protocol as specified by RFC 5498. As such it isn't constrained to use RFC 5444.

 

--

Christopher Dearlove

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

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

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

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 07 May 2013 18:11
To: manet
Cc: draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org
Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt

 

 

*** WARNING ***

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

On Tue, May 7, 2013 at 11:41 AM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:

On 05/07/2013 11:36 AM, Abdussalam Baryun wrote:

Hi Ogier,
I was interested to find the RFC5444 format (MANET messaging format)
in the I-D. The document is for the manet case so why does it not use
RFC5444 in its work? Do you think using RFC5444 is not a good idea in
this I-D, please explain?

 

Read the title of the document again... you will notice the "OSPF".

the OSPF Manet-Extension has been developed in the OSPF working group using the OSPF message format.

 

I understand that you prefer using OSPF fomat for the I-D, which I was thinking of RFC5444. I read I-D and the extension is for manet not others. IMO it is ok all WGs may work together for the best of IETF protocols or formats. IMO that a routing protocol X  that wants to be extended for MANET cases SHOULD include additional messaging type considering rfc5444 format, but if that protocol has a reason why not to use RFC5444 then it will be understood,

 

AB

 


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25068C34GLKXM0002VGREEN_-- From sratliff@cisco.com Tue May 7 10:37:23 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B67821F8D27 for ; Tue, 7 May 2013 10:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cbfLVstbxbUP for ; Tue, 7 May 2013 10:37:19 -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 B880521F8E99 for ; Tue, 7 May 2013 10:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17101; q=dns/txt; s=iport; t=1367948238; x=1369157838; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wPMYom6EaoTSDRou6xjlnXRVj7I2lVqGeutbtsckPPs=; b=ZKQwTtbOLtoeugrq7juLUqGmdoGhALLCTUJmoJXQm9fjjf7M/QZw7bAg nhtYkpyjHjv9qDJrqq05hbCofFydwMLpJQO3G8T32DN+XhUUIrglJHE76 m7rqOQ3FYWrj5jgsqPshliIvSCYxkZAXo5LP2tJLTWwjaSA37pwb7rcOg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAFM7iVGtJV2Z/2dsb2JhbABQgkNEN7ZaiDCBChZ0gh8BAQECAgEBAVIZAwIGEAIBCBEEAQELHQcnCxQJCAIEDgUIiAQMsn6PA41xCg55LQQGAQYDgmthA5hVkBGDDoFpCRce X-IronPort-AV: E=Sophos;i="4.87,629,1363132800"; d="scan'208,217";a="207478639" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 07 May 2013 17:37:18 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r47HbHGb003930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 May 2013 17:37:17 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 7 May 2013 12:37:17 -0500 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: [manet] I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt Thread-Index: AQHOS0mEjoMdJi2/BkC9WmgY9ftl+Q== Date: Tue, 7 May 2013 17:37:17 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100EC435@xmb-aln-x03.cisco.com> References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> <5188DA58.2080704@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.42.190] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100EC435xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org" , manet Subject: Re: [manet] I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:37:23 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100EC435xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable AB, I agree with Chris. What you propose would almost have to be expressed as a= n "OSPF over RFC5444" draft. That would be a *huge* undertaking. I sincerel= y doubt there would be sufficient interest and/or cycles in MANET for such = an effort. Speaking only as a working group participant, I would not be int= erested in pursuing it. Regards, Stan On May 7, 2013, at 1:20 PM, Dearlove, Christopher (UK) wrote: This is an extension to OSPF. It is not a protocol to run on the manet UDP = port/IP protocol as specified by RFC 5498. As such it isn't constrained to = use RFC 5444. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: 07 May 2013 18:11 To: manet Cc: draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-0= 2.txt *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. On Tue, May 7, 2013 at 11:41 AM, Henning Rogge > wrote: On 05/07/2013 11:36 AM, Abdussalam Baryun wrote: Hi Ogier, I was interested to find the RFC5444 format (MANET messaging format) in the I-D. The document is for the manet case so why does it not use RFC5444 in its work? Do you think using RFC5444 is not a good idea in this I-D, please explain? Read the title of the document again... you will notice the "OSPF". the OSPF Manet-Extension has been developed in the OSPF working group using= the OSPF message format. I understand that you prefer using OSPF fomat for the I-D, which I was thin= king of RFC5444. I read I-D and the extension is for manet not others. IMO = it is ok all WGs may work together for the best of IETF protocols or format= s. IMO that a routing protocol X that wants to be extended for MANET cases= SHOULD include additional messaging type considering rfc5444 format, but i= f that protocol has a reason why not to use RFC5444 then it will be underst= ood, AB ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100EC435xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable AB, 

I agree with Chris. What you propose would almost have to be expressed= as an "OSPF over RFC5444" draft. That would be a *huge* undertak= ing. I sincerely doubt there would be sufficient interest and/or cycles in = MANET for such an effort. Speaking only as a working group participant, I would not be interested in pursuing it.&nbs= p;

Regards,
Stan

On May 7, 2013, at 1:20 PM, Dearlove, Christopher (UK) wrote:

This is an extension to OSPF. It is not a protocol to run= on the manet UDP port/IP protocol as specified by RFC 5498. As such it isn= 't constrained to use RFC 5444.
 
--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com<= span class=3D"Apple-converted-space"> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
 
From:&nbs= p;manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam= Baryun
Sent: 07 May 2013 = 18:11
To: manet
Cc: draft-ietf-ospf-manet-single-hop-mdr@tool= s.ietf.org
Subject: Re: [mane= t] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt
 
 <= /o:p>
*** WARNING ***

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

On Tue, May 7, 2013 at 11:41 AM, Henning Rogge <henning.rogge@fkie.fraunhofer.de> wrote:=
On 05/07/2013 11:36 AM, Abdussalam Baryun wrote:
Hi Ogier,
I was interested to find the RFC5444 format (MANET messaging format)
in the I-D. The document is for the manet case so why does it not use
RFC5444 in its work? Do you think using RFC5444 is not a good idea in
this I-D, please explain?
 

Read the title of the document again... you will notice the "OSPF"= ;.

the OSPF Manet-Extension has been developed in the OSPF working group using= the OSPF message format.

 

I understand that you prefer using OSPF fomat for the I-D, which I was thin= king of RFC5444. I read I-D and the extension is for manet not others.= IMO it is ok all WGs may work together for the best of IETF prot= ocols or formats. IMO that a routing protocol X  that wants to be extended for MANET cases SHOULD include additio= nal messaging type considering rfc5444 format, but if that protocol has a r= eason why not to use RFC5444 then it will be understood,
 
AB
 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

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

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100EC435xmbalnx03ciscoc_-- From jpmacker@gmail.com Tue May 7 11:28:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5151B21F91B8 for ; Tue, 7 May 2013 11:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 E7GHyBOqOoTK for ; Tue, 7 May 2013 11:28:27 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 808E521F9130 for ; Tue, 7 May 2013 11:28:27 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id m16so861040vca.30 for ; Tue, 07 May 2013 11:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=gwmlf/lLP1Ahrr1jvrnEO5l5L6nm3uI12o+3ZXbD74U=; b=tcrbvS6Q04UQkX3aq5rsUWLbAMJbeE+Od8ZpEvU9tOebNUmNwUxJCYL87hGc3WPcuM SLJRfgBCoMwugWjcdfvnb7bT0FNu8RganO7WOvBKWlKnn+mDIyd+3vT4RiZ4RQt/bAF9 DHSBDDeSvis7sVLotTR95GFQO3/5uH/X3MgetiS6N2JLsCPiFOAuB+O7h/QErixdPkfP hxCm7lLFywpX0RuETvXJ4+QEqcQeTpXYIz/BMMjBdm2jpg1cg0NBknoXtpC3nALFxiGv 3+Mnvw6tNx7nb6SC+i8/zcG0EpL3wVWlthOxgXK1kZfaJIQ1BiYEnufLKnAin9f6wc97 r+IQ== X-Received: by 10.52.165.99 with SMTP id yx3mr1788161vdb.34.1367951306901; Tue, 07 May 2013 11:28:26 -0700 (PDT) Received: from aes048153.nrl.navy.mil (aes048153.nrl.navy.mil. [132.250.48.153]) by mx.google.com with ESMTPSA id tn7sm22806886vdc.8.2013.05.07.11.28.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 11:28:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Joe Macker In-Reply-To: Date: Tue, 7 May 2013 14:28:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <22D7F15E-E328-4CB2-A07A-AAA6289D2285@gmail.com> References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1503) Cc: rich.ogier@earthlink.net, manet@ietf.org Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 18:28:32 -0000 AB: (A little history for clarification) This is related to existing past efforts to extend manet concepts to = OSPF formats and so it should use OSPF formats/TLVs,etc. The explicitly goal at that time was to have minimum impact on existing = OSPF design but gain some value from MANET enhancements. There are several EXPERIMENTAL RFCs already produced from that effort. The MANET and OSPF WG chairs were involved early on in helping to = establish and formulate this initial collaborative exchange between WGs. Hopefully this clarified the intent and some of the related history.. -Joe On May 7, 2013, at 5:36 AM, Abdussalam Baryun = wrote: > Hi Ogier, > I was interested to find the RFC5444 format (MANET messaging format) > in the I-D. The document is for the manet case so why does it not use > RFC5444 in its work? Do you think using RFC5444 is not a good idea in > this I-D, please explain? >=20 > AB >=20 > On 5/5/13, Adrian Farrel wrote: >> heads up >>=20 >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> [mailto:i-d-announce-bounces@ietf.org] >>> On Behalf Of internet-drafts@ietf.org >>> Sent: 05 May 2013 16:15 >>> To: i-d-announce@ietf.org >>> Cc: ospf@ietf.org >>> Subject: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the Open Shortest Path First IGP = Working >>> Group >> of >>> the IETF. >>>=20 >>> Title : Use of OSPF-MDR in Single-Hop Broadcast = Networks >>> Author(s) : Richard G. Ogier >>> Filename : draft-ietf-ospf-manet-single-hop-mdr-02.txt >>> Pages : 6 >>> Date : 2013-05-05 >>>=20 >>> 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. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-ospf-manet-single-hop-mdr-02 >>>=20 >>> A diff from the previous version is available at: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-manet-single-hop-mdr-02= >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=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 abdussalambaryun@gmail.com Wed May 8 03:19:45 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935D321F9130 for ; Wed, 8 May 2013 03:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.251, 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 Biy5aAXeeK-w for ; Wed, 8 May 2013 03:19:40 -0700 (PDT) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 573DE21F9154 for ; Wed, 8 May 2013 03:19:36 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id 3so1139955pdj.13 for ; Wed, 08 May 2013 03:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jCNTURoExFb2UMI8G7Y6VfV0/fqFlLSyT6Sar3ZfsK0=; b=pr+Ij9iMOR+s7CC37h/QHvqdbV3kJu8K0ay3tU8i1xZbV4Th9oLb4yqys5jdNB68+/ vzoUNlK2cXH6BtDlv/MkfOndqHilbK7n+auo5nG83Ckp+IqcZPy8/EalKgZaZpQZU+f/ Z57saNTyp4O3jp+aIDq5CQq9Lw+v/6BTuvQ3IFrIU+tNDTwkSlVBoU9YsaU+lJPgHZSk adXOTlR51w8rBxKZpKQE5vvwNtpNpr9NKJaufv+WVlv8ZyKYZy5c6yfNNWeXL50J5ngy Q/U1sNsPJjKRv0dwCAAeIR4fd2etzomQe0+eQJKLR5O4z2QggZlxshYuFkpoDzZb04tE 1H/Q== MIME-Version: 1.0 X-Received: by 10.68.193.138 with SMTP id ho10mr6710083pbc.163.1368008376093; Wed, 08 May 2013 03:19:36 -0700 (PDT) Received: by 10.68.143.132 with HTTP; Wed, 8 May 2013 03:19:35 -0700 (PDT) In-Reply-To: References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> <5188DA58.2080704@fkie.fraunhofer.de> Date: Wed, 8 May 2013 11:19:35 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=047d7b15af434e994004dc324556 Cc: "draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org" , manet Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 10:19:46 -0000 --047d7b15af434e994004dc324556 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 7, 2013 at 6:20 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > This is an extension to OSPF. It is not a protocol to run on the manet > UDP port/IP protocol as specified by RFC 5498. As such it isn't constrained > to use RFC 5444. > > > I agree that the extension is not for manet UDP port/ protocol number as in RFC5498. The extension is to OSPF for MANET (i.e. OSPF already has a protocol number to be used). I was thinking of a new RFC5444 packet specially for OSPF that is only used for this extension. Using only RFC5444 not using RFC5498, and not *OSPF over RFC5444*. AB > > > ** ** > > -- **** > > Christopher Dearlove**** > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124**** > > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687**** > > ** ** > > *From:* manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] *On Behalf > Of *Abdussalam Baryun > *Sent:* 07 May 2013 18:11 > *To:* manet > *Cc:* draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org > *Subject:* Re: [manet] FW: I-D Action: > draft-ietf-ospf-manet-single-hop-mdr-02.txt**** > > ** ** > > ** ** > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.** > Keep this in mind if you answer this message. > Please see this processon how to deal with suspicious emails. > ***** > > On Tue, May 7, 2013 at 11:41 AM, Henning Rogge < > henning.rogge@fkie.fraunhofer.de> wrote:**** > > On 05/07/2013 11:36 AM, Abdussalam Baryun wrote:**** > > Hi Ogier, > I was interested to find the RFC5444 format (MANET messaging format) > in the I-D. The document is for the manet case so why does it not use > RFC5444 in its work? Do you think using RFC5444 is not a good idea in > this I-D, please explain?**** > > ** ** > > Read the title of the document again... you will notice the "OSPF". > > the OSPF Manet-Extension has been developed in the OSPF working group > using the OSPF message format.**** > > **** > > I understand that you prefer using OSPF fomat for the I-D, which I was > thinking of RFC5444. I read I-D and the extension is for manet not others. > IMO it is ok all WGs may work together for the best of IETF protocols or > formats. IMO that a routing protocol X that wants to be extended for MANET > cases SHOULD include additional messaging type considering rfc5444 format, > but if that protocol has a reason why not to use RFC5444 then it will be > understood,**** > > **** > > AB**** > > ** ** > > ******************************************************************** > 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. > ******************************************************************** > > --047d7b15af434e994004dc324556 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, May 7, 2013 at 6:20 PM, Dearlove, Christopher (UK) &l= t;Chris.= Dearlove@baesystems.com> wrote:

This is an extension= to OSPF. It is not a protocol to run on the manet UDP port/IP protocol as = specified by RFC 5498. As such it isn't constrained to use RFC 5444.

=A0

=A0
I agree that the ext= ension is not for manet UDP port/ protocol number as in RFC5498. The extens= ion is to=A0OSPF for MANET (i.e. OSPF already has a protocol number to be u= sed). I was thinking of a new RFC5444 packet specially for OSPF that is onl= y used for this extension. Using only RFC5444 not using RFC5498, and not *O= SPF over RFC5444*.
=A0
AB
=A0

=A0

=A0

--

Christopher Dearlove=

Senior Principal Eng= ineer, 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|=A0 Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesy= stems.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

=A0

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 07 May 2013 18:11
To: manet
Cc: draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.or= g
Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-ho= p-mdr-02.txt

=A0

=A0

*** WARNING ***<= /span>

This message originates from outside ou= r organisation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

On Tue, May 7, 2013 at 11:41 AM, Henning Rogge <<= a href=3D"mailto:henning.rogge@fkie.fraunhofer.de" target=3D"_blank">hennin= g.rogge@fkie.fraunhofer.de> wrote:

On 05/07/2013 11:36 AM, Abdussalam Baryun wrote:<= /u>

Hi Ogier,
I was interested to find the RFC5444 format (MANET messaging format)
in the I-D. The document is for the manet case so why does it not use
RFC5444 in its work? Do you think using RFC5444 is not a good idea in
this I-D, please explain?

=A0

Read the title of the document again... you will notice the "OSPF&q= uot;.

the OSPF Manet-Extension has been developed in the OSPF working group using= the OSPF message format.

=A0

I understand that you prefer using OSPF fomat for th= e I-D, which I was thinking of RFC5444. I read I-D and=A0the extension is f= or manet not others. IMO it=A0is ok all=A0WGs may work together for the bes= t of IETF protocols or formats. IMO that a routing protocol X=A0 that wants to=A0be extended for MANET cases=A0SHOU= LD include additional messaging type considering rfc5444 format, but if tha= t protocol has a reason why not to use RFC5444 then it will be understood,<= u>

=A0

AB

=A0


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


--047d7b15af434e994004dc324556-- From abdussalambaryun@gmail.com Wed May 8 03:40:32 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CFD21F901B for ; Wed, 8 May 2013 03:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 Cb1ERCZOUdfm for ; Wed, 8 May 2013 03:40:28 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5A08321F8FE9 for ; Wed, 8 May 2013 03:40:28 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id p11so1144956pdj.12 for ; Wed, 08 May 2013 03:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EFDEmeFsi3Lx1m0uhq4ZlXk8cIQeFYkfOq7lPu2nZgQ=; b=BnLLp2oceCrL+jZGFQg4e2oq+eDmuz3zrN/6EuphE+a0KU0ja+n51B1O16KJOLbS6k S4wnlJ2IcMQrugLJOi5U8zK5m6hKiH02TAZG2gI1N8rAsVQ0YXrX/PKnfhuOGuF862Iz 4KY7rFST+ErwX7hRBAj02euI28AeEGLPkru7430GlbcWo/4RPIeBCifqW8gfdDAvtRZV SjotQLDn2uq0fpjAS93p7ctgivdlQIL/zUproqZeuc7VmNPut95v3gzmznTdmJgTEPa7 O7Z1UeIsEaS7yq6NS7XNgDHpop8MxhtAbSkyDngFcEIdjgMg7IG0oWhfGG2gcqJt9RXK Omaw== MIME-Version: 1.0 X-Received: by 10.68.13.228 with SMTP id k4mr6655187pbc.215.1368009628072; Wed, 08 May 2013 03:40:28 -0700 (PDT) Received: by 10.68.143.132 with HTTP; Wed, 8 May 2013 03:40:28 -0700 (PDT) In-Reply-To: <22D7F15E-E328-4CB2-A07A-AAA6289D2285@gmail.com> References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> <22D7F15E-E328-4CB2-A07A-AAA6289D2285@gmail.com> Date: Wed, 8 May 2013 11:40:28 +0100 Message-ID: From: Abdussalam Baryun To: Joe Macker Content-Type: multipart/alternative; boundary=bcaec5216315ee42c204dc328f81 Cc: "draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org" , manet Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 10:40:32 -0000 --bcaec5216315ee42c204dc328f81 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, Yes it helped me understand the intent, but I think it will be nice if some clarification goes into the I-D as well for future readers/users. Thanking you, AB On Tue, May 7, 2013 at 7:28 PM, Joe Macker wrote: > AB: > > (A little history for clarification) > This is related to existing past efforts to extend manet concepts to OSPF > formats and so it should use OSPF formats/TLVs,etc. > The explicitly goal at that time was to have minimum impact on existing > OSPF design but gain some value from MANET enhancements. > There are several EXPERIMENTAL RFCs already produced from that effort. > > The MANET and OSPF WG chairs were involved early on in helping to > establish and formulate this initial collaborative exchange between WGs. > Hopefully this clarified the intent and some of the related history.. > > -Joe > > On May 7, 2013, at 5:36 AM, Abdussalam Baryun > wrote: > > > Hi Ogier, > > I was interested to find the RFC5444 format (MANET messaging format) > > in the I-D. The document is for the manet case so why does it not use > > RFC5444 in its work? Do you think using RFC5444 is not a good idea in > > this I-D, please explain? > > > > AB > > > > On 5/5/13, Adrian Farrel wrote: > >> heads up > >> > >>> -----Original Message----- > >>> From: i-d-announce-bounces@ietf.org > >>> [mailto:i-d-announce-bounces@ietf.org] > >>> On Behalf Of internet-drafts@ietf.org > >>> Sent: 05 May 2013 16:15 > >>> To: i-d-announce@ietf.org > >>> Cc: ospf@ietf.org > >>> Subject: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >>> This draft is a work item of the Open Shortest Path First IGP Working > >>> Group > >> of > >>> the IETF. > >>> > >>> Title : Use of OSPF-MDR in Single-Hop Broadcast Networks > >>> Author(s) : Richard G. Ogier > >>> Filename : draft-ietf-ospf-manet-single-hop-mdr-02.txt > >>> Pages : 6 > >>> Date : 2013-05-05 > >>> > >>> 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 IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr > >>> > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-ospf-manet-single-hop-mdr-02 > >>> > >>> A diff from the previous version is available at: > >>> > http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-manet-single-hop-mdr-02 > >>> > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> I-D-Announce mailing list > >>> I-D-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>> Internet-Draft directories: http://www.ietf.org/shadow.html > >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> _______________________________________________ > >> 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 > > --bcaec5216315ee42c204dc328f81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,
=A0
Yes it helped me unde= rstand the intent, but I think it will be nice if some clarification goes i= nto the I-D as well for future readers/users. Thanking you,
=A0
AB


On Tue, May 7, 2013 at 7:28 PM, Joe Macker <jpmacker@gmail.com&= gt; wrote:
AB:

(A little history for clarification)
This is related to existing past efforts to extend manet concepts to OSPF f= ormats and so it should use OSPF formats/TLVs,etc.
The explicitly goal at that time was to have minimum impact on existing OSP= F design but gain some value from MANET enhancements.
There are several EXPERIMENTAL RFCs already produced from that effort.

The MANET and OSPF WG chairs were involved early on in helping to establish= and formulate this initial collaborative exchange between WGs.
Hopefully this clarified the intent and some of the related history..

-Joe

On May 7, 2013, at 5:36 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

> Hi Ogier,
> I was interested to find the RFC5444 format (MANET messaging format) > in the I-D. The document is for the manet case so why does it not use<= br> > RFC5444 in its work? Do you think using RFC5444 is not a good idea in<= br> > this I-D, please explain?
>
> AB
>
> On 5/5/13, Adrian Farrel <ad= rian@olddog.co.uk> wrote:
>> heads up
>>
>>> -----Original Message-----
>>> From: i-d-ann= ounce-bounces@ietf.org
>>> [mailto:i-d-a= nnounce-bounces@ietf.org]
>>> On Behalf Of inter= net-drafts@ietf.org
>>> Sent: 05 May 2013 16:15
>>> To: i-d-announce@ietf= .org
>>> Cc: ospf@ietf.org
>>> Subject: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.t= xt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts
>> directories.
>>> This draft is a work item of the Open Shortest Path First IGP = Working
>>> Group
>> of
>>> the IETF.
>>>
>>> =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Use of OSPF-MDR in Single-= Hop Broadcast Networks
>>> =A0 =A0 Author(s) =A0 =A0 =A0 : Richard G. Ogier
>>> =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-ospf-manet-single= -hop-mdr-02.txt
>>> =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 6
>>> =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-05-05
>>>
>>> Abstract:
>>> RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc netw= orks
>>> (MANETs) by specifying its operation on the new OSPF interface= of type
>>> MANET. =A0This document describes the use of OSPF-MDR in a sin= gle-hop
>>> broadcast network, which is a special case of a MANET in which= each
>>> router is a (one-hop) neighbor of each other router. =A0Unlike= an OSPF
>>> broadcast interface, such an interface can have a different co= st
>>> associated with each neighbor. =A0The document includes config= uration
>>> recommendations and simplified mechanisms that can be used in = single-hop
>>> broadcast networks.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draf= t-ietf-ospf-manet-single-hop-mdr
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-os= pf-manet-single-hop-mdr-02
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-ospf-manet-single-hop-mdr-02
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org=
>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> _______________________________________________
>> 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


--bcaec5216315ee42c204dc328f81-- From Chris.Dearlove@baesystems.com Wed May 8 03:47:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671D821F91CA for ; Wed, 8 May 2013 03:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 l6m7lKgxKWr9 for ; Wed, 8 May 2013 03:47:20 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 15EB521F91BF for ; Wed, 8 May 2013 03:47:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,632,1363132800"; d="scan'208,217";a="284437962" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 08 May 2013 11:47:18 +0100 Received: from baemasodc005.greenlnk.net ([10.108.52.29]) by baemasodc004.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r48AlHf0013798 for ; Wed, 8 May 2013 11:47:17 +0100 X-IronPort-AV: E=Sophos;i="4.87,632,1363132800"; d="scan'208,217";a="15213955" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 08 May 2013 11:47:17 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.244]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Wed, 8 May 2013 11:47:16 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt Thread-Index: AQHOS9WOhkZOv54tPkaGM9K8Sd+ShZj7Gr+Q Date: Wed, 8 May 2013 10:47:15 +0000 Message-ID: References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> <5188DA58.2080704@fkie.fraunhofer.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25068F8FGLKXM0002VGREEN_" MIME-Version: 1.0 Cc: "draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org" , manet Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 10:47:25 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25068F8FGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And the question would be why? (I can imagine a possible why. But that's imagine, not have an actual reaso= n. Someone might want sometime it is not a reason.) -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 08 May 2013 11:20 To: Dearlove, Christopher (UK) Cc: manet; draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-0= 2.txt *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. On Tue, May 7, 2013 at 6:20 PM, Dearlove, Christopher (UK) > wrote: This is an extension to OSPF. It is not a protocol to run on the manet UDP = port/IP protocol as specified by RFC 5498. As such it isn't constrained to = use RFC 5444. I agree that the extension is not for manet UDP port/ protocol number as in= RFC5498. The extension is to OSPF for MANET (i.e. OSPF already has a proto= col number to be used). I was thinking of a new RFC5444 packet specially fo= r OSPF that is only used for this extension. Using only RFC5444 not using R= FC5498, and not *OSPF over RFC5444*. AB -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: manet-bounces@ietf.org [mailto:manet-b= ounces@ietf.org] On Behalf Of Abdussalam Bar= yun Sent: 07 May 2013 18:11 To: manet Cc: draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-0= 2.txt *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. On Tue, May 7, 2013 at 11:41 AM, Henning Rogge > wrote: On 05/07/2013 11:36 AM, Abdussalam Baryun wrote: Hi Ogier, I was interested to find the RFC5444 format (MANET messaging format) in the I-D. The document is for the manet case so why does it not use RFC5444 in its work? Do you think using RFC5444 is not a good idea in this I-D, please explain? Read the title of the document again... you will notice the "OSPF". the OSPF Manet-Extension has been developed in the OSPF working group using= the OSPF message format. I understand that you prefer using OSPF fomat for the I-D, which I was thin= king of RFC5444. I read I-D and the extension is for manet not others. IMO = it is ok all WGs may work together for the best of IETF protocols or format= s. IMO that a routing protocol X that wants to be extended for MANET cases= SHOULD include additional messaging type considering rfc5444 format, but i= f that protocol has a reason why not to use RFC5444 then it will be underst= ood, AB ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25068F8FGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And the question would be= why?

 <= /p>

(I can imagine a possible= why. But that's imagine, not have an actual reason. Someone might want som= etime it is not a reason.)

 <= /p>

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

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

 <= /p>

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 08 May 2013 11:20
To: Dearlove, Christopher (UK)
Cc: manet; draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org
Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-ho= p-mdr-02.txt

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

On Tue, May 7, 2013 at 6:20 PM, Dearlove, Christophe= r (UK) <Chris.Dearlove@baesystems.com> wrote:

This is an extension to OSPF. It is not= a protocol to run on the manet UDP port/IP protocol as specified by RFC 5498. As such it isn't constrained to use RFC 5444.

 

 

I agree that the extension is not for manet UDP port= / protocol number as in RFC5498. The extension is to OSPF for MANET (i= .e. OSPF already has a protocol number to be used). I was thinking of a new= RFC5444 packet specially for OSPF that is only used for this extension. Using only RFC5444 not using RFC5498, and= not *OSPF over RFC5444*.

 

AB

 

 

 

--

Christopher Dearlove<= /p>

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

chris.dearlove@baesystems.com | http://www.baesy= stems.com

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

 

From: manet-bounces@i= etf.org [mailto:manet-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 07 May 2013 18:11
To: manet
Cc: draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org
Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-ho= p-mdr-02.txt

 

 =

*** WARNING ***

This message originates from outside our organ= isation, either from an external partner or the internet.
Ke= ep this in mind if you answer this message.
Pl= ease see this process on how to deal with suspicious emails.<= /i>

On Tue, May 7, 2013 at 11:41 AM, Henning Rogge <henning.rogge@fkie.f= raunhofer.de> wrote:

On 05/07/2013 11:36 AM, Abdussalam Baryun wrote:

Hi Ogier,
I was interested to find the RFC5444 format (MANET messaging format)
in the I-D. The document is for the manet case so why does it not use
RFC5444 in its work? Do you think using RFC5444 is not a good idea in
this I-D, please explain?

 

Read the title of the document again... you will notice the "OSPF&q= uot;.

the OSPF Manet-Extension has been developed in the OSPF working group using= the OSPF message format.

 

I understand that you prefer using OSPF fomat for the I-D, which I= was thinking of RFC5444. I read I-D and the extension is for manet no= t others. IMO it is ok all WGs may work together for the best of IETF protocols or formats. IMO that a routing protocol X&n= bsp; that wants to be extended for MANET cases SHOULD include add= itional messaging type considering rfc5444 format, but if that protocol has= a reason why not to use RFC5444 then it will be understood,

 

AB

 


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D25068F8FGLKXM0002VGREEN_-- From abdussalambaryun@gmail.com Wed May 8 06:16:44 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3387821F9378 for ; Wed, 8 May 2013 06:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 K2LUv71y0rRw for ; Wed, 8 May 2013 06:16:39 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 339BB21F9370 for ; Wed, 8 May 2013 06:16:39 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id jh10so1331260pab.17 for ; Wed, 08 May 2013 06:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3Gj5N/3OUTWN9D6GDpd8xr060UrbxsCYbP4LWLjnyaM=; b=Dj8oE25zR24szLSQCYiyfJRvUjONnHpWBzfj/E4GpmRmVRZ/SIF+jqGICPlrtgfGrQ +MHAQiSEC1DDWYTjuEKqyHaWm4Q5SYU+jeMEdAQCadsQEEVX7jm6yWR8eGBr4L66+tMp JhcfuiSr9cHrSQhZ/PizxAYQqQvV0vOHhwq1cyVnPee77aUS53NgtJfxiRaFSSzP5xUa UMbKTUTet3sezDdZ86n6SQNmefbViF5UlthOWyjmitKuj3rDmvckJ4Kc8z2uwQ+9TAnP O9JGKVYtteQmBtjGgNL9vQciRRCheWOzI+fEhnwc56M2BYq5tj/kDmWZ/RIysAoontEM DtAA== MIME-Version: 1.0 X-Received: by 10.66.222.228 with SMTP id qp4mr8009986pac.113.1368018998886; Wed, 08 May 2013 06:16:38 -0700 (PDT) Received: by 10.68.143.132 with HTTP; Wed, 8 May 2013 06:16:38 -0700 (PDT) In-Reply-To: References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> Date: Wed, 8 May 2013 14:16:38 +0100 Message-ID: From: Abdussalam Baryun To: rich.ogier@earthlink.net Content-Type: multipart/alternative; boundary=047d7b5d888779894d04dc34bebb Cc: "draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org" , manet Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 13:16:44 -0000 --047d7b5d888779894d04dc34bebb Content-Type: text/plain; charset=ISO-8859-1 I have another question, May DLEP improve OSPF within manet? if yes why not mentioned in the I-D, AB On Tue, May 7, 2013 at 10:36 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Ogier, > I was interested to find the RFC5444 format (MANET messaging format) > in the I-D. The document is for the manet case so why does it not use > RFC5444 in its work? Do you think using RFC5444 is not a good idea in > this I-D, please explain? > > AB > > On 5/5/13, Adrian Farrel wrote: > > heads up > > > >> -----Original Message----- > >> From: i-d-announce-bounces@ietf.org > >> [mailto:i-d-announce-bounces@ietf.org] > >> On Behalf Of internet-drafts@ietf.org > >> Sent: 05 May 2013 16:15 > >> To: i-d-announce@ietf.org > >> Cc: ospf@ietf.org > >> Subject: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> This draft is a work item of the Open Shortest Path First IGP Working > >> Group > > of > >> the IETF. > >> > >> Title : Use of OSPF-MDR in Single-Hop Broadcast Networks > >> Author(s) : Richard G. Ogier > >> Filename : draft-ietf-ospf-manet-single-hop-mdr-02.txt > >> Pages : 6 > >> Date : 2013-05-05 > >> > >> 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 IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-ospf-manet-single-hop-mdr-02 > >> > >> A diff from the previous version is available at: > >> > http://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-manet-single-hop-mdr-02 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > --047d7b5d888779894d04dc34bebb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have another question, May DLEP improve OSPF within= manet? if yes why not mentioned in the I-D,
=A0
AB


On Tu= e, May 7, 2013 at 10:36 AM, Abdussalam Baryun <abdussalambaryun@g= mail.com> wrote:
Hi Ogier,
I was interested to find the RFC5444 format (MANET messaging format)
in the I-D. The document is for the manet case so why does it not use
RFC5444 in its work? Do you think using RFC5444 is not a good idea in
this I-D, please explain?

AB

On 5/5/13, Adrian Farrel <adrian@= olddog.co.uk> wrote:
> heads up
>
>> -----Original Message-----
>> From: i-d-announc= e-bounces@ietf.org
>> [mailto:i-d-annou= nce-bounces@ietf.org]
>> On Behalf Of internet-= drafts@ietf.org
>> Sent: 05 May 2013 16:15
>> To: i-d-announce@ietf.org=
>> Cc: ospf@ietf.org
>> Subject: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt >>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
> directories.
>> =A0This draft is a work item of the Open Shortest Path First IGP W= orking
>> Group
> of
>> the IETF.
>>
>> =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Use of OSPF-MDR in Single-H= op Broadcast Networks
>> =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Richard G. Ogier
>> =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-ospf-manet-single-= hop-mdr-02.txt
>> =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 6
>> =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-05-05
>>
>> 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. =A0This document describes the use of OSPF-MDR in a single-= hop
>> broadcast network, which is a special case of a MANET in which eac= h
>> router is a (one-hop) neighbor of each other router. =A0Unlike an = OSPF
>> broadcast interface, such an interface can have a different cost >> associated with each neighbor. =A0The document includes configurat= ion
>> recommendations and simplified mechanisms that can be used in sing= le-hop
>> broadcast networks.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ie= tf-ospf-manet-single-hop-mdr
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-ospf-m= anet-single-hop-mdr-02
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Dd= raft-ietf-ospf-manet-single-hop-mdr-02
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> = ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org=
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

--047d7b5d888779894d04dc34bebb-- From abdussalambaryun@gmail.com Thu May 9 09:03:13 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA3F21F9347 for ; Thu, 9 May 2013 09:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, 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 UItgI5-jzW1O for ; Thu, 9 May 2013 09:03:12 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5546321F9485 for ; Thu, 9 May 2013 09:03:06 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q54so3042036wes.4 for ; Thu, 09 May 2013 09:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RB4BLr+RZ+jHGXoJfDOX8t0e81xPmcpskzxCzoBIk98=; b=gmvzc0IG4y8FTrl8MRi1F+dKDs8cPxpeuAAPjSTMw9BYwJB63lCtl+khgQwchTWEfe WpX8Y927IWa00mGMf3vv0QgXhwh7NGDCdbYQwyb1fS5B1g/GtB/+/FQkendz6+rrMKUr 4L9tJMcduA3/0dBDbCraz9cU8fLqSWMUrooFKJ+GOc6+aPuH/m81jh1laA3jcCc4X6jF lm4X81SQvZa2tPUXozrCb9f7hfB+ML6CteuNosGu9abGE1IBlbPmYSujXJRPKoh9BQJT 2VeUz0wWuqS1W0vZv3iVrOPXxqal8IGt/3w9lMYFseredTlZEfUceKk92tqbApvg3MU9 2J4A== MIME-Version: 1.0 X-Received: by 10.180.183.76 with SMTP id ek12mr18238378wic.30.1368115385265; Thu, 09 May 2013 09:03:05 -0700 (PDT) Received: by 10.180.80.135 with HTTP; Thu, 9 May 2013 09:03:05 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C1003F76F@xmb-aln-x03.cisco.com> References: <5FE80271-96B9-4D46-B2DC-47331C10CACD@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C1003F76F@xmb-aln-x03.cisco.com> Date: Thu, 9 May 2013 17:03:05 +0100 Message-ID: From: Abdussalam Baryun To: "manet-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=001a11c3465e8cfb2204dc4b2f75 Cc: "manet@ietf.org List" Subject: Re: [manet] Fwd: Public Warning under RFC 3934 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 16:03:13 -0000 --001a11c3465e8cfb2204dc4b2f75 Content-Type: text/plain; charset=ISO-8859-1 Please note that I still not receive an expalination of your warning, which I asked you in private on 8 March, and that I am not face-to-face participant but a remote participant, therefore; Please note that I don't accept your warning because I uynderstand it as a discouraging. Please note that I beleive that my inputs are technical and procedural related to IETF. Please note that I beleive that in IETF I have freedom of input and speech as long as it is related to work discussions. Please note that you did not send me a private notice warning before some time from your public warning, this makes me confused of the best practicing of RFC3934 section 2 (i.e. is for face-to-face but even if not it states that you make direct warning first). AB On Tue, Mar 5, 2013 at 3:11 PM, Stan Ratliff (sratliff) wrote: > > > Begin forwarded message: > > *From: *Stan Ratliff > *Subject: **Public Warning under RFC 3934* > *Date: *March 5, 2013 10:05:03 AM EST > *To: *Abdussalam Baryun > *Cc: *, " Adrian" < > adrian@olddog.co.uk>, "Stewart Bryant (stbryant)" > > Abdussalam, > > There have been many discussions, both on the MANET mailing list and in > private, about your posts to this list. After discussion with my co-chair > and with the Area Directors, we feel compelled to issue this formal warning > about your posting habits - you have been posting at a high rate, and your > posts typically do not contain sufficient content to advance the discussion. > > Therefore, this email constitutes a public warning under Section 2 of > RFC3934. Please cease this activity and restrict your emails to focused and > targeted technical contributions. Please ensure that all of your emails are > based on sufficient research, and that opinions you express are supported > by reasoned technical arguments. If you are unable to do this or continue > to post in the same volume and/or style, the chairs will follow with a > suspension of your posting privileges. > > Sincerely, > Stan > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11c3465e8cfb2204dc4b2f75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please note that I still not receive an expalina= tion of your warning, which I asked you in private on 8 March, and that I a= m not face-to-face participant but a remote participant, therefore;
=A0
Please note that I don't accept your warning because I uy= nderstand it as a discouraging.
Please note that I beleive = that my inputs are technical and procedural related to IETF.
Plea= se note that I beleive that in IETF I have freedom of input and speech as l= ong as it is related to work discussions.
Please note that you did not send me a private notice warning before s= ome time from your public warning, this makes me confused=A0of the best pra= cticing of RFC3934 section 2 (i.e. is for face-to-face but even if not it s= tates that you make direct warning first).
=A0
AB


On Tue, Mar 5, 2013 at 3:11 PM, Stan Ratliff (sratliff)= <sratliff@cisco.com> wrote:


Begin forwarded message:

From: Stan Ratliff <sratliff@cisco.com>
Subject: Public Warning under RFC 3934
Date: March 5, 2013 10:05:03 AM EST
To: Abdussalam Baryun <abdussalambaryun@gmail.com>

Abdussalam,

There have been many discussions, both on the MANET mailing list and in pri= vate, about your posts to this list. After discussion with my co-chair and = with the Area Directors, we feel compelled to issue this formal warning abo= ut your posting habits - you have been posting at a high rate, and your posts typically do not contain suffi= cient content to advance the discussion.

Therefore, this email constitutes a public warning under Section 2 of RFC39= 34. Please cease this activity and restrict your emails to focused and targ= eted technical contributions. Please ensure that all of your emails are bas= ed on sufficient research, and that opinions you express are supported by reasoned technical arguments. If you= are unable to do this or continue to post in the same volume and/or style,= the chairs will follow with a suspension of your posting privileges.

Sincerely,
Stan


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


--001a11c3465e8cfb2204dc4b2f75-- From sratliff@cisco.com Thu May 9 10:06:12 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2BB21F8693 for ; Thu, 9 May 2013 10:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pggR1yj8C8DY for ; Thu, 9 May 2013 10:06:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4A421F861B for ; Thu, 9 May 2013 10:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9020; q=dns/txt; s=iport; t=1368119167; x=1369328767; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=E8YXbH/onm8PINtDxM1X8r6Se6QGsmsYEQ2mEaDt6Mc=; b=P3WPOlziYUoPyxpLwajYYg5d4olj2vD/x8LLDLp0WUAs7KrchOeFVPk7 U0lS1UfHiF8R/RteK6vPE6nP79XT3SIvZaNETFtyYu1JYNcDt25MQCrDY 130fc1lkhTgmumZwRwMbWQX0XsjEIuTgHPADeILzrBbI9rVdZE1q8bHlJ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FADrWi1GtJV2Y/2dsb2JhbABSgwc3wAp6FnSCHwEBAQQBAQFrBQYQAgEIEQMBAgsdByEGCxQJCAIEDgUIh3IDDwy1XQ2IGgSMUoEUgREgDQQGAQaCbmEDiGKMZo13hSKDD4FpCRcDGw X-IronPort-AV: E=Sophos;i="4.87,642,1363132800"; d="scan'208,217";a="205451915" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 09 May 2013 17:06:06 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r49H65le028170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 17:06:05 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Thu, 9 May 2013 12:06:05 -0500 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] Public Warning under RFC 3934 Thread-Index: AQHOTNd9ffIMUeaiqkqZT448gT9v/g== Date: Thu, 9 May 2013 17:06:04 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C100F0936@xmb-aln-x03.cisco.com> References: <5FE80271-96B9-4D46-B2DC-47331C10CACD@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C1003F76F@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.118] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100F0936xmbalnx03ciscoc_" MIME-Version: 1.0 Cc: "manet-chairs@tools.ietf.org" , "manet@ietf.org List" Subject: Re: [manet] Public Warning under RFC 3934 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 17:06:12 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100F0936xmbalnx03ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AB, I am in receipt of this email. Will respond within 24 hours. Since this ema= il includes the WG mailing list, I feel it incumbent upon me that the respo= nse also include the list - unless, or course, you object. Regards, Stan On May 9, 2013, at 12:03 PM, Abdussalam Baryun wrote: Please note that I still not receive an expalination of your warning, which= I asked you in private on 8 March, and that I am not face-to-face particip= ant but a remote participant, therefore; Please note that I don't accept your warning because I uynderstand it as a = discouraging. Please note that I beleive that my inputs are technical and procedural rela= ted to IETF. Please note that I beleive that in IETF I have freedom of input and speech = as long as it is related to work discussions. Please note that you did not send me a private notice warning before some t= ime from your public warning, this makes me confused of the best practicing= of RFC3934 section 2 (i.e. is for face-to-face but even if not it states t= hat you make direct warning first). AB On Tue, Mar 5, 2013 at 3:11 PM, Stan Ratliff (sratliff) > wrote: Begin forwarded message: From: Stan Ratliff > Subject: Public Warning under RFC 3934 Date: March 5, 2013 10:05:03 AM EST To: Abdussalam Baryun > Cc: >, "> Adrian" >, "Stewart Bryant (stbryant)" > Abdussalam, There have been many discussions, both on the MANET mailing list and in pri= vate, about your posts to this list. After discussion with my co-chair and = with the Area Directors, we feel compelled to issue this formal warning abo= ut your posting habits - you have been posting at a high rate, and your pos= ts typically do not contain sufficient content to advance the discussion. Therefore, this email constitutes a public warning under Section 2 of RFC39= 34. Please cease this activity and restrict your emails to focused and targ= eted technical contributions. Please ensure that all of your emails are bas= ed on sufficient research, and that opinions you express are supported by r= easoned technical arguments. If you are unable to do this or continue to po= st in the same volume and/or style, the chairs will follow with a suspensio= n of your posting privileges. Sincerely, Stan _______________________________________________ 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 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100F0936xmbalnx03ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable AB,

I am in receipt of this email. Will respond within 24 hours. Since thi= s email includes the WG mailing list, I feel it incumbent upon me that the = response also include the list - unless, or course, you object. 

Regards,
Stan

On May 9, 2013, at 12:03 PM, Abdussalam Baryun wrote:

Please note that I still not receive an expalination of your warning, = which I asked you in private on 8 March, and that I am not face-to-face par= ticipant but a remote participant, therefore;
 
Please note that I don't accept your warning because I uynderstand it = as a discouraging.
Please note that I beleive that my inputs are technical and procedural= related to IETF.
Please note that I beleive that in IETF I have freedom of input and sp= eech as long as it is related to work discussions.
Please note that you did not send me a private notice warning before s= ome time from your public warning, this makes me confused of the best = practicing of RFC3934 section 2 (i.e. is for face-to-face but even if not i= t states that you make direct warning first).
 
AB


On Tue, Mar 5, 2013 at 3:11 PM, Stan Ratliff (sr= atliff) <sratliff@cisco.= com> wrote:


Begin forwarded message:

From: Stan Ratliff <sratliff@cisco.com>
Subject: Public Warning under RFC 3934
Date: March 5, 2013 10:05:03 AM EST
To: Abdussalam Baryun <abdussalambaryun@gmail.com>

Abdussalam,

There have been many discussions, both on the MANET mailing list and in pri= vate, about your posts to this list. After discussion with my co-chair and = with the Area Directors, we feel compelled to issue this formal warning abo= ut your posting habits - you have been posting at a high rate, and your posts typically do not contain suffi= cient content to advance the discussion.

Therefore, this email constitutes a public warning under Section 2 of RFC39= 34. Please cease this activity and restrict your emails to focused and targ= eted technical contributions. Please ensure that all of your emails are bas= ed on sufficient research, and that opinions you express are supported by reasoned technical arguments. If you= are unable to do this or continue to post in the same volume and/or style,= the chairs will follow with a suspension of your posting privileges.

Sincerely,
Stan


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


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

--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C100F0936xmbalnx03ciscoc_-- From abdussalambaryun@gmail.com Thu May 9 11:47:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A9721F8546 for ; Thu, 9 May 2013 11:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, 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 D56LwXNo3QGF for ; Thu, 9 May 2013 11:47:55 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8A99321F8503 for ; Thu, 9 May 2013 11:47:52 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q55so3298667wes.40 for ; Thu, 09 May 2013 11:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=U1I3G4ykYaC7/H6QbxyjSB0vV4dcrM7tIMzrMTdqO1I=; b=PEPxVl6h8wQ0mU9AziTKX6CNDwYu8KnBgk24SgNDcKBxI0x709ovMGBYz31KJIyVaO /+y3I+rjRzbfRegctdoDHBum3pZguOvfP45pOCif0AivT84yuaNcG8mzP+BAvQK2DL2H n/oxMyfoS7sxKOiuWNPtpYITYqU6olPqNUm6vJru3x5cPFrMaQHLGVAkRz7EK52XpL57 wV0Y93c6x/O3TL++AnHitnfSAjw0+0PbdeL35BE2YTRz9dgsDHd40x2hLbKEW5uTDsYU sS+D6WEYvLMaUP8pygRVbgvxdfoh2YL4T8XXKUxD0xaSE4VDA1X1eLKZb/DtYoCP9Oqx JxpA== MIME-Version: 1.0 X-Received: by 10.195.13.47 with SMTP id ev15mr20004527wjd.18.1368125271694; Thu, 09 May 2013 11:47:51 -0700 (PDT) Received: by 10.180.80.135 with HTTP; Thu, 9 May 2013 11:47:51 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C100F0936@xmb-aln-x03.cisco.com> References: <5FE80271-96B9-4D46-B2DC-47331C10CACD@cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C1003F76F@xmb-aln-x03.cisco.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C100F0936@xmb-aln-x03.cisco.com> Date: Thu, 9 May 2013 19:47:51 +0100 Message-ID: From: Abdussalam Baryun To: "Stan Ratliff (sratliff)" Content-Type: multipart/alternative; boundary=047d7bd91ebcd3e51404dc4d7caa Cc: "manet-chairs@tools.ietf.org" , "manet@ietf.org List" Subject: Re: [manet] Public Warning under RFC 3934 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 18:47:56 -0000 --047d7bd91ebcd3e51404dc4d7caa Content-Type: text/plain; charset=ISO-8859-1 Hi Stan, I did not mean to get respond on the list. Please note that I object. Thanking you, AB On Thu, May 9, 2013 at 6:06 PM, Stan Ratliff (sratliff) wrote: > AB, > > I am in receipt of this email. Will respond within 24 hours. Since this > email includes the WG mailing list, I feel it incumbent upon me that the > response also include the list - unless, or course, you object. > > Regards, > Stan > > On May 9, 2013, at 12:03 PM, Abdussalam Baryun wrote: > > Please note that I still not receive an expalination of your warning, > which I asked you in private on 8 March, and that I am not face-to-face > participant but a remote participant, therefore; > > Please note that I don't accept your warning because I uynderstand it as a > discouraging. > Please note that I beleive that my inputs are technical and procedural > related to IETF. > Please note that I beleive that in IETF I have freedom of input and speech > as long as it is related to work discussions. > Please note that you did not send me a private notice warning before some > time from your public warning, this makes me confused of the best > practicing of RFC3934 section 2 (i.e. is for face-to-face but even if not > it states that you make direct warning first). > > AB > > > On Tue, Mar 5, 2013 at 3:11 PM, Stan Ratliff (sratliff) < > sratliff@cisco.com> wrote: > >> >> >> Begin forwarded message: >> >> *From: *Stan Ratliff >> *Subject: **Public Warning under RFC 3934* >> *Date: *March 5, 2013 10:05:03 AM EST >> *To: *Abdussalam Baryun >> *Cc: *, " Adrian" < >> adrian@olddog.co.uk>, "Stewart Bryant (stbryant)" >> >> Abdussalam, >> >> There have been many discussions, both on the MANET mailing list and in >> private, about your posts to this list. After discussion with my co-chair >> and with the Area Directors, we feel compelled to issue this formal warning >> about your posting habits - you have been posting at a high rate, and your >> posts typically do not contain sufficient content to advance the discussion. >> >> Therefore, this email constitutes a public warning under Section 2 of >> RFC3934. Please cease this activity and restrict your emails to focused and >> targeted technical contributions. Please ensure that all of your emails are >> based on sufficient research, and that opinions you express are supported >> by reasoned technical arguments. If you are unable to do this or continue >> to post in the same volume and/or style, the chairs will follow with a >> suspension of your posting privileges. >> >> Sincerely, >> Stan >> >> >> >> _______________________________________________ >> 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 > > > --047d7bd91ebcd3e51404dc4d7caa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stan,
=A0
I did not mean to ge= t respond on the list.=A0Please note that I object. Thanking you,
=A0
AB


On Thu, May 9, 2013 at 6:06 PM, Stan Ratliff (sratliff) &= lt;sratliff@cisco.c= om> wrote:
AB,

I am in receipt of this email. Will respond within 24 hours. Since thi= s email includes the WG mailing list, I feel it incumbent upon me that the = response also include the list - unless, or course, you object.=A0

Regards,
Stan

On May 9, 2013, at 12:03 PM, Abdussalam Baryun wrote:

Please note that I still not receive an expalination of your warning, = which I asked you in private on 8 March, and that I am not face-to-face par= ticipant but a remote participant, therefore;
=A0
Please note that I don't accept your warning because I uynderstand= it as a discouraging.
Please note that I beleive that my inputs are technical and procedural= related to IETF.
Please note that I beleive that in IETF I have freedom of input and sp= eech as long as it is related to work discussions.
Please note that you did not send me a private notice warning before s= ome time from your public warning, this makes me confused=A0of the best pra= cticing of RFC3934 section 2 (i.e. is for face-to-face but even if not it s= tates that you make direct warning first).
=A0
AB


On Tue, Mar 5, 2013 at 3:11 PM, Stan Ratliff (sr= atliff) <sratliff@cisco.= com> wrote:


Begin forwarded message:

From: Stan Ratliff <sratliff@cisco.com>
Subject: Public Warning under RFC 3934
Date: March 5, 2013 10:05:03 AM EST
To: Abdussalam Baryun <abdussalambaryun@gmail.com>

Abdussalam,

There have been many discussions, both on the MANET mailing list and in pri= vate, about your posts to this list. After discussion with my co-chair and = with the Area Directors, we feel compelled to issue this formal warning abo= ut your posting habits - you have been posting at a high rate, and your posts typically do not contain suffi= cient content to advance the discussion.

Therefore, this email constitutes a public warning under Section 2 of RFC39= 34. Please cease this activity and restrict your emails to focused and targ= eted technical contributions. Please ensure that all of your emails are bas= ed on sufficient research, and that opinions you express are supported by reasoned technical arguments. If you= are unable to do this or continue to post in the same volume and/or style,= the chairs will follow with a suspension of your posting privileges.

Sincerely,
Stan


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


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


--047d7bd91ebcd3e51404dc4d7caa-- From internet-drafts@ietf.org Thu May 9 14:06:51 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C8C21F901B; Thu, 9 May 2013 14:06:51 -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 kY4QIC0Wlwuo; Thu, 9 May 2013 14:06:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CE621F8FD0; Thu, 9 May 2013 14:06:35 -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.44.p7 Message-ID: <20130509210635.7175.76289.idtracker@ietfa.amsl.com> Date: Thu, 09 May 2013 14:06:35 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-08.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 21:06:51 -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-08.txt Pages : 76 Date : 2013-05-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 state information, performance information, 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. 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-mib-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trac+manet@trac.tools.ietf.org Fri May 10 16:19:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560E921F91CE for ; Fri, 10 May 2013 16:19:25 -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 m-ltOUxDV+uC for ; Fri, 10 May 2013 16:19:24 -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 A23E421F914C for ; Fri, 10 May 2013 16:19:23 -0700 (PDT) Received: from localhost ([127.0.0.1]:53026 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uawar-0004pC-OG; Sat, 11 May 2013 01:19:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" 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, abdussalambaryun@gmail.com X-Trac-Project: manet Date: Fri, 10 May 2013 23:19:17 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/17#comment:3 Message-ID: <081.bb8a680dbfe5a2f3ae7323baa871531c@trac.tools.ietf.org> References: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: charliep@computer.org, abdussalambaryun@gmail.com, 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] #17: Proposed Reactive Protocols' Alternative Message Formats X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 23:19:25 -0000 #17: Proposed Reactive Protocols' Alternative Message Formats Comment (by charliep@computer.org): After reviewing this issue and subsequent comments, I suggest that we close this issue. I agree that incorporating Henning's proposed revision should have the effect of relieving concerns about positional independence for the base spec, and the debate about whether positional dependence is bad or good can go on as a separate matter if there is still interest. -- ----------------------------------------+---------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Type: enhancement | charliep@computer.org Priority: major | Status: assigned Component: dymo | Milestone: milestone1 Severity: Active WG Document | Version: Keywords: RFC5444, Address TLVs | Resolution: ----------------------------------------+---------------------------------- Ticket URL: manet From abdussalambaryun@gmail.com Sat May 11 06:28:56 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE19121F8F0F for ; Sat, 11 May 2013 06:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[AWL=-0.146, 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 mblSueBYI1aM for ; Sat, 11 May 2013 06:28:52 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id 929BA21F8F03 for ; Sat, 11 May 2013 06:28:52 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id y14so3392858pdi.34 for ; Sat, 11 May 2013 06:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+esQqlnvjfdXLUfUZAHWImtq6EkOruY1jFpyWiVOdpE=; b=Ks8zDDaBCxWtJg1N2E2RQx+UN79FzHcvmKPWTnEUs2KAL/vUlP/BJv6jcBdw1t/rdU thy9ZRKsdNo2+DKmxXKSt3PIhOclT+RJg+J8RH/gMzBYC/pa0W8KumVEfG/P0sYxln+B 92sWBcRpTFvZxR3kb2JEYc8u0U1mj692monhux9yT1nQoR1cBdQOgkaTwusEjhduCKry WJN4DPvIfW/c6s0HZBEV72K1s8CQPm7xhAK0FMKF6IFosTVGtpvfLPF6bnk7X7Ew2Lkk jON8JvhCy0pTiKaPNGChcZBSEEf/LYWkBb1mVg5IkyVqgYHSyP9FdV6qhpJRVPAn5xGW 3LiQ== MIME-Version: 1.0 X-Received: by 10.68.193.138 with SMTP id ho10mr21490398pbc.163.1368278932243; Sat, 11 May 2013 06:28:52 -0700 (PDT) Received: by 10.68.143.132 with HTTP; Sat, 11 May 2013 06:28:52 -0700 (PDT) In-Reply-To: References: <20130505151526.3223.18240.idtracker@ietfa.amsl.com> <001301ce49d9$eef2e630$ccd8b290$@olddog.co.uk> <5188DA58.2080704@fkie.fraunhofer.de> Date: Sat, 11 May 2013 15:28:52 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org" , manet Subject: Re: [manet] FW: I-D Action: draft-ietf-ospf-manet-single-hop-mdr-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 13:28:57 -0000 Hi Chris, >(I can imagine a possible why. But that's imagine, not have an actual reason. Someone might want sometime it is not a reason.) I know that the want-source came from the document and I as possible user that need to know the reason of not using RFC5444. The RFC5444 wants all manet routers to use it. If it was not discussed, there is no harm in discussing issues related, I think discussing I-Ds are always reasonable in any way. The I-D is an experimental work in progress, so I am asking to know more, so I can make a decision to use it or not. my comments below; > And the question would be why? > The intention of using RFC5444 is to improve OSPF in MANETs or to improve the document applicability. Within MANETs I may have: NHDP, AODVv2, OLSRv2, and SMF, that are all using RFC5444. The I-D is looking into single hop broadcast networks, proposing new interface manet type, and working within the MANET. I want to reduce the OSPF flooding overhead, I think/imagine RFC5444 may be used for that need. Furthermore, OSPF may cover areas of different networks, so MANET has different security attacks from other nets, so IMO having using similar RFC5444-sec can help a OSPF packet-type to manet scurity requirements. There are experimental documents [1-2] and other informational [3-4] that should be considered for such discussion. [1] Danilov, C., et al. (2009) Experimental and Field Demonstration of A 802.11-based Ground-UAV Mobile Ad-Hoc Network, MILCOM. [2] Fuertes, et al., (2012) Routing across wired and wireless mesh networks: Experimental Compound Internetworking with OSPF, 8th Intl wireless comm and mobile comp conf. [3] Chakeres, et al. (2007), Connecting MANET Multicast, MILCOM. [4] Goyal, et al. (2013), Improving Convergence Speed and Scalability in OSPF: a survey, IEEE comm survey journal. Regards AB On 5/8/13, Dearlove, Christopher (UK) wrote: > And the question would be why? > > (I can imagine a possible why. But that's imagine, not have an actual > reason. Someone might want sometime it is not a reason.) > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 08 May 2013 11:20 > To: Dearlove, Christopher (UK) > Cc: manet; draft-ietf-ospf-manet-single-hop-mdr@tools.ietf.org > Subject: Re: [manet] FW: I-D Action: > draft-ietf-ospf-manet-single-hop-mdr-02.txt > > > *** WARNING *** > This message originates from outside our organisation, either from an > external partner or the internet. > Keep this in mind if you answer this message. > Please see this > process > on how to deal with suspicious emails. > On Tue, May 7, 2013 at 6:20 PM, Dearlove, Christopher (UK) > > > wrote: > This is an extension to OSPF. It is not a protocol to run on the manet UDP > port/IP protocol as specified by RFC 5498. As such it isn't constrained to > use RFC 5444. > > > I agree that the extension is not for manet UDP port/ protocol number as in > RFC5498. The extension is to OSPF for MANET (i.e. OSPF already has a > protocol number to be used). I was thinking of a new RFC5444 packet > specially for OSPF that is only used for this extension. Using only RFC5444 > not using RFC5498, and not *OSPF over RFC5444*. > > AB > > From trac+manet@trac.tools.ietf.org Fri May 17 08:15:11 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E9621F9672 for ; Fri, 17 May 2013 08:15: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 sfbWDMd0kNiS for ; Fri, 17 May 2013 08:15:09 -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 9731821F90D2 for ; Fri, 17 May 2013 08:15:08 -0700 (PDT) Received: from localhost ([127.0.0.1]:43831 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UdMN9-0001dH-B2; Fri, 17 May 2013 17:15:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "manet issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com X-Trac-Project: manet Date: Fri, 17 May 2013 15:15:07 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/1#comment:2 Message-ID: <076.9ac9872e430883442b18f6e4707c6532@trac.tools.ietf.org> References: <061.72177d73cfafe05daea3d2d786e8793b@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <061.72177d73cfafe05daea3d2d786e8793b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, 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] #1: Discussion about naming for the IETF reactive protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Reply-To: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 15:15:12 -0000 #1: Discussion about naming for the IETF reactive protocol Comment (by abdussalambaryun@gmail.com): I hope to close this issue, as no objection to the new name AODVv2. For progress, could we start closing the discussion tickets, or there is another way to progress the protocol. Please advise, AB -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: task | Status: new Priority: minor | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: Keywords: reactive naming | -----------------------------------+------------------------------ Ticket URL: manet From abdussalambaryun@gmail.com Fri May 17 08:24:37 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F05A21F8633 for ; Fri, 17 May 2013 08:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 FtSH1DJ5UbN5 for ; Fri, 17 May 2013 08:24:33 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C27C21F86C3 for ; Fri, 17 May 2013 08:24:31 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id 6so3452133pdd.17 for ; Fri, 17 May 2013 08:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=awrZ0+A1itEcoRmdsgScjlkmWi0SxZ2mJjkdMKfw/l8=; b=iyzMP7kzhb/OlzdA5CaCbaYxQNyuSTZ/3D2gcuFEsQkAKzzMAi6PtSZKsa638qoQSh 5ei6E150i1HwEDbIqvi3sQ84GBr02Enef665JURnkmDciFJnApYN2eut6H/7kTchzRQV ApwXXWhepFOaNeVBtqDASYY2gViRbewaDzN+DcNOyR34d6Ewym/FX1phRemD5lDWoNAQ fzN24qJ8K5wxweVwAsU1AIC/GLsWwTzfDBkkHnnF6TrR3kZyyq95ZRFbfpc4Qso1VhKO 1FS0nJA6cdXAnupSYIS2uXNmqENHdCl/8Ndritr2VTodBaU288IQbdVRC0UN5t+6IPAC yzug== MIME-Version: 1.0 X-Received: by 10.68.13.228 with SMTP id k4mr47934400pbc.215.1368804271005; Fri, 17 May 2013 08:24:31 -0700 (PDT) Received: by 10.68.143.132 with HTTP; Fri, 17 May 2013 08:24:30 -0700 (PDT) In-Reply-To: <081.bb8a680dbfe5a2f3ae7323baa871531c@trac.tools.ietf.org> References: <066.0bddf25fdd852b2ecb82f1beeb15666f@trac.tools.ietf.org> <081.bb8a680dbfe5a2f3ae7323baa871531c@trac.tools.ietf.org> Date: Fri, 17 May 2013 17:24:30 +0200 Message-ID: From: Abdussalam Baryun To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 15:24:37 -0000 Hi Charlie, This ticket is still for DYMO drafts, but now we have AODVv2 draft, I hope that all tickets refer to the new document, or what do you think, AB On 5/11/13, manet issue tracker wrote: > #17: Proposed Reactive Protocols' Alternative Message Formats > > > Comment (by charliep@computer.org): > > After reviewing this issue and subsequent comments, I suggest that we > close this issue. I agree that incorporating Henning's proposed revision > should have the effect of relieving concerns about positional independence > for the base spec, and the debate about whether positional dependence is > bad or good can go on as a separate matter if there is still interest. > > -- > ----------------------------------------+---------------------------------- > Reporter: abdussalambaryun@gmail.com | Owner: > Type: enhancement | charliep@computer.org > Priority: major | Status: assigned > Component: dymo | Milestone: milestone1 > Severity: Active WG Document | Version: > Keywords: RFC5444, Address TLVs | Resolution: > ----------------------------------------+---------------------------------- > > Ticket URL: > manet > > From jpmacker@gmail.com Sat May 18 18:04:25 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F6E21F8B98; Sat, 18 May 2013 18:04:25 -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, 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 wudTKhzguMHv; Sat, 18 May 2013 18:04:23 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D9A3221F8B65; Sat, 18 May 2013 18:04:22 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id eg20so2732590lab.41 for ; Sat, 18 May 2013 18:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=vE8kL+koQtyoZCULrvWP3O+/uFuOR5BE7nzM0X4s4wg=; b=aHZKx04/b+S0E7DTHGtfyFiNfwQqha1FaX/kvgifQyRQOiLwwzIsy/kPASDvTX+gvm YiiQwRd1XXpYGo9dVtyW+HfMwkkeVBYjmpXX26hC2a21Z3gL/6Ew3CZ3H6aZzsVYlYpF 8aqt+xmMHbvcV7q2HXXcoFy/FkVHIFqyen4sVeXMrps9rSdwqwdQFTnTyW4sauS/i/UY Vlne70HydXDw409t7cf+0UsxHOb+E33eTFbpoKcKBq8XmXbhlaOZcR8OWtP83xqRDeIC x1a1c84JdRH3Fttxa+Z+kxMvz42WsQkGmT50tI/KmNAF46IphYFfhJAIVKjPTx2bGfwI Bmww== MIME-Version: 1.0 X-Received: by 10.112.125.130 with SMTP id mq2mr24905908lbb.103.1368925461696; Sat, 18 May 2013 18:04:21 -0700 (PDT) Received: by 10.112.4.39 with HTTP; Sat, 18 May 2013 18:04:21 -0700 (PDT) Date: Sat, 18 May 2013 21:04:21 -0400 Message-ID: From: Joseph Macker To: iesg-secretary@ietf.org, Adrian Farrel , "manet@ietf.org" Content-Type: multipart/alternative; boundary=089e0122866cde594d04dd07cb7d Subject: [manet] Publication Request for draft-ietf-manet-nhdp-sec-threats-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 01:04:25 -0000 --089e0122866cde594d04dd07cb7d Content-Type: text/plain; charset=ISO-8859-1 Please publish draft-ietf-manet-nhdp-sec-threats-03 as an Informational RFC. The Shepherds Writeup has been uploaded and is replicated below. As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The type of document is Informational. It provides discussion and analyses useful for the internet and represents working group consensus. The document indicates "Information" (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: 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 for this document. Adrian Farrel (adrian@olddog.co.uk) is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has personally reviewed the document, and believes it is ready for forwarding to the IESG for publication. The shepherd has also run the id-nits tools. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had adequate review from both key working group members and from key non-WG members. The shepherd does not have any concerns about the depth or breadth of the reviews that have been performed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The shepherd does not have any concerns about the document needing additional review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. IPR disclosures were not necessary, therefore, none have been filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Working group consensus behind this document is solid. The document represents rough consensus of the working group as a whole, the document passed WGLC with minimal comments and consensus to move forward with publication. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Working group consensus behind this document is solid. There have a few minor complaints that we do not believe represent consensus opinion. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None required. (13) Have all references within this document been identified as either normative or informative? The document has split its references into normative and informative (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The shepherd has verified that document IANA consideration section exists, and is consistent with the body of the document. No actions for IANA have been requested. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None required. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None required. --089e0122866cde594d04dd07cb7d Content-Type: text/html; charset=ISO-8859-1
Please publish draft-ietf-manet-nhdp-sec-threats-03 as an Informational RFC. The Shepherds Writeup has been uploaded and is replicated below.

As required by RFC 4858, this is the current template for the Document 
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The type of document is Informational.  It provides discussion and analyses useful for the internet and represents working group consensus.  The document indicates "Information" 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:


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 for this document.  Adrian Farrel (adrian@olddog.co.uk) is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has personally reviewed the document, and believes it is ready for forwarding to the IESG for publication.  The shepherd has also run the id-nits tools.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?  

The document has had adequate review from both key working group members and from key non-WG members. The shepherd does not have any concerns about the depth or breadth of the reviews that have been performed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The shepherd does not have any concerns about the document needing additional review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns. 

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

IPR disclosures were not necessary, therefore, none have been filed.

(9) How solid is the WG consensus behind this document? Does it 
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?   

Working group consensus behind this document is solid. The document represents rough consensus of the working group as a whole, the document passed WGLC with minimal comments and consensus to move forward with publication.

(10) Has anyone threatened an appeal or otherwise indicated extreme 
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.) 

Working group consensus behind this document is solid.  There have a few minor complaints that we do not believe represent consensus opinion.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None required.

(13) Have all references within this document been identified as
either normative or informative?

The document has split its references into normative and informative

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in 
the Last Call procedure. 

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


The shepherd has verified that document IANA consideration section exists, and is consistent with the body of the document. No actions for IANA have been requested.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None required.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None required.



--089e0122866cde594d04dd07cb7d-- From mukulrshukla@gmail.com Sun May 19 06:46:50 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BF121F8673 for ; Sun, 19 May 2013 06:46: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, 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 BZxysrOL3mrv for ; Sun, 19 May 2013 06:46:50 -0700 (PDT) Received: from mail-ie0-x242.google.com (mail-ie0-x242.google.com [IPv6:2607:f8b0:4001:c03::242]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDD621F8613 for ; Sun, 19 May 2013 06:46:50 -0700 (PDT) Received: by mail-ie0-f194.google.com with SMTP id s9so4124884iec.5 for ; Sun, 19 May 2013 06:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GwThP17SDD9s6FDpq+kAm/7AuWMSgbItuAnBWyVK134=; b=PY/1nXT9hSyAKRvwzPTlgkI8rLAZUpEInQn7Wi5lLCQ49MAA9MyV5kYvf6jcgVGODA OhOS+gO3E3ZpYwDcAJyP4s9B+bfbosHZtrfel7nWuYpBAgNeDwoeXn+HKL44vqNOtohM 4/kZKn1XZ+CRDdKXZ7bRtujiyIZVRYk1c3xni6I7gwMk99M1BqyvH6umpFXO+jvSbDyv r6t0KASKHggNdrYwEkKBzTR/tkGolx74WCh/0yw6dIplUGz9DACtVbbVPjjF8l7hUmZp xPA2nTpZ4GmuM2raAOQfTftXtNHdjZKD/ZdSevB5w7CdsmfeSjZ8AlHPzxo5TM+Kz2+u yXCw== MIME-Version: 1.0 X-Received: by 10.50.128.102 with SMTP id nn6mr2999933igb.26.1368971209739; Sun, 19 May 2013 06:46:49 -0700 (PDT) Received: by 10.64.170.198 with HTTP; Sun, 19 May 2013 06:46:49 -0700 (PDT) Date: Sun, 19 May 2013 19:16:49 +0530 Message-ID: From: Mukul Shukla To: manet@ietf.org Content-Type: multipart/alternative; boundary=089e013a1920aa150f04dd1272d2 Subject: [manet] Need AODV implementations X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 13:46:50 -0000 --089e013a1920aa150f04dd1272d2 Content-Type: text/plain; charset=ISO-8859-1 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 --089e013a1920aa150f04dd1272d2 Content-Type: text/html; charset=ISO-8859-1
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
--089e013a1920aa150f04dd1272d2-- From adrian@olddog.co.uk Thu May 23 14:47:57 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4246821F8617 for ; Thu, 23 May 2013 14:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 76iF2fYbMtI0 for ; Thu, 23 May 2013 14:47:42 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 5380221F90EB for ; Thu, 23 May 2013 13:59:52 -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 r4NKxnIj009439; Thu, 23 May 2013 21:59:50 +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 r4NKxmQ2009433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 May 2013 21:59:49 +0100 From: "Adrian Farrel" To: Date: Thu, 23 May 2013 21:59:48 +0100 Message-ID: <04d601ce57f8$76ad0700$64071500$@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: Ac5X+F6mNs9w91NXT06vpY60J37ohQ== Content-Language: en-gb Cc: manet@ietf.org Subject: [manet] AD review of draft-ietf-manet-nhdp-sec-threats 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:47:57 -0000 Hi, Thanks for this document which I found readable and comprehensible. I have done my usual AD review to find issues and concerns that I think should be resolved before the document advances to IETF last call and IESG review. Since I am not a security weenie^H^H^H^H expert, my comments are sparse. Therefore I am kicking off IETF last call at once. Please handle my comments as part of the last call. (I have also sent a heads-up to the Security ADs that this document definitely needs attention from the Security Directorate.) Thanks for the work, Adrian --- I know it is not the intent of this document to propose solutions or mitigations to any of the threats described. However, I think two things would be useful: 1. Please add a statement of exactly this point to the Abstract and to the end of the Introduction. 2. Please consider adding a short section that may drive new work by suggesting which threats need to be addressed in new protocol work, which in deployment, and which by applications. --- The assumption stated in the Introduction... This document is based on the assumption that no additional security mechanism (such as IPsec) is used in the IP layer. ...is perfectly fine. You might add a note to explain why this is a reasonable assumption (i.e., it is particularly hard to configure security associations in this type of network) and you might also add a note about whether none, some, or all of the threats would go away if this problem could be resolved. From ulrich@herberg.name Thu May 23 15:28:26 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3767F21F90CD for ; Thu, 23 May 2013 15:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 8S8Kw2AknSL0 for ; Thu, 23 May 2013 15:28:21 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D52D221F988C for ; Thu, 23 May 2013 14:46:19 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id hf12so2680983vcb.3 for ; Thu, 23 May 2013 14:46:19 -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=E/FEaDdx7lFzOkF6xk/dn/OqX85f0Mm1BOQXpEhfN9U=; b=kji5pkYyi5BHFObDoBRGxhbVZkyK9BrghzrgS+HFWzzoTagF2hMPC6ku7uXmYjri01 Ru/1UKC3cfacsms9FdlO9MBti3ku8xIlFLwbCWhW/+OcY4ZGDD9E2Vskpmv6j4bgbeVW ibLxn9pV60CJj16QqB1/ySJ1BQ9y40Y3nDQYQ= 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=E/FEaDdx7lFzOkF6xk/dn/OqX85f0Mm1BOQXpEhfN9U=; b=fMGhqk+ohvLslsIsZ7AlreSmggLpjekUmZiIcd+EVl3g/pO+ZEZjPfNzdR12+D0HzA SWY2LoBI5wMPMrxEAUk5FcmK16tOHwW2EHu916J27Wk6OaBpgx5s3s1AbMS3obg47I9T tmp3BimiGIHvFhCZwJBK4KmnCy0owTdIbT5M0jNM6c5b6Cl/r9LkvkCwAIFVtV12NkjL ak4pskH38Ft9Ajvpg8sJyvlpmv4VhVh5bczeDW9CoJCJx9dw1TmIBke9lRB4Hdwg1Kob Zsk7L6/snES8mQznDatGZXEmQoYJO1A6gdLstKpRstY3t1IgJpER1YA93LTGQ9Fmrjnf hmKQ== MIME-Version: 1.0 X-Received: by 10.52.233.34 with SMTP id tt2mr5637459vdc.70.1369345579257; Thu, 23 May 2013 14:46:19 -0700 (PDT) Received: by 10.220.195.134 with HTTP; Thu, 23 May 2013 14:46:19 -0700 (PDT) In-Reply-To: <04d601ce57f8$76ad0700$64071500$@olddog.co.uk> References: <04d601ce57f8$76ad0700$64071500$@olddog.co.uk> Date: Thu, 23 May 2013 14:46:19 -0700 Message-ID: From: Ulrich Herberg To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl+phlQZI5ch40oiUymfHlHCHNE9Ewgk0pWAGpwrNCaP8nJjdib/5AwHqE4PPcW0b+R6bum Cc: manet@ietf.org, draft-ietf-manet-nhdp-sec-threats.all@tools.ietf.org Subject: Re: [manet] AD review of draft-ietf-manet-nhdp-sec-threats X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:28:26 -0000 Adrian, thank you very much for your review. We will address your comments as part of the IETF LC, like you suggested. Best regards Ulrich On Thu, May 23, 2013 at 1:59 PM, Adrian Farrel wrote: > Hi, > > Thanks for this document which I found readable and comprehensible. > > I have done my usual AD review to find issues and concerns that I think > should be resolved before the document advances to IETF last call and > IESG review. > > Since I am not a security weenie^H^H^H^H expert, my comments are sparse. > Therefore I am kicking off IETF last call at once. Please handle my > comments as part of the last call. (I have also sent a heads-up to the > Security ADs that this document definitely needs attention from the > Security Directorate.) > > Thanks for the work, > Adrian > > --- > > I know it is not the intent of this document to propose solutions or > mitigations to any of the threats described. However, I think two things > would be useful: > > 1. Please add a statement of exactly this point to the Abstract and to > the end of the Introduction. > > 2. Please consider adding a short section that may drive new work by > suggesting which threats need to be addressed in new protocol work, > which in deployment, and which by applications. > > --- > > The assumption stated in the Introduction... > This document is based on the assumption that no additional security > mechanism (such as IPsec) is used in the IP layer. > ...is perfectly fine. You might add a note to explain why this is a > reasonable assumption (i.e., it is particularly hard to configure > security associations in this type of network) and you might also add a > note about whether none, some, or all of the threats would go away if > this problem could be resolved. > From iesg-secretary@ietf.org Thu May 23 15:38:27 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F7A21F9501; Thu, 23 May 2013 15:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.254, 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 HwbCJR1xNcwL; Thu, 23 May 2013 15:38:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 894AD21F9893; Thu, 23 May 2013 15:22:42 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Sender: Message-ID: <20130523222242.3631.36122.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 15:22:42 -0700 Cc: manet@ietf.org Subject: [manet] Last Call: (Security Threats for NHDP) to Informational RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:38:27 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' 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. From adrian@olddog.co.uk Fri May 24 02:26:24 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C6B21F938E; Fri, 24 May 2013 02:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=-1.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, TRACKER_ID=2.003] 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 WSGGS42lVeff; Fri, 24 May 2013 02:26:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4EA21F933B; Fri, 24 May 2013 02:26:17 -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 r4O9QDjw014798; Fri, 24 May 2013 10:26:13 +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 r4O9QBpO014773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 10:26:12 +0100 From: "Adrian Farrel" To: "'Benoit Claise'" , "'Nguyen, James H CIV USARMY CERDEC \(US\)'" References: <201305231512.r4NFCMN4006908@irp-view13.cisco.com> <3DC26342A93F204C804384C87DDBECBF3DADF508@ucolhp9k.easf.csd.disa.mil> <519F25A0.70502@cisco.com> In-Reply-To: <519F25A0.70502@cisco.com> Date: Fri, 24 May 2013 10:26:10 +0100 Message-ID: <056b01ce5860$bafed290$30fc77b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_056F_01CE5869.1CC9F150" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt5VD+u7/ZzOgrC0mFlTA9gvmqaQJjdZgFAly+7hKZrvMTAA== Content-Language: en-gb Cc: draft-nguyen-manet-ecds-mib@tools.ietf.org, draft-ietf-manet-smf-mib@tools.ietf.org, manet@ietf.org, pm-dir@ietf.org, 'Fred Baker' Subject: Re: [manet] draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 09:26:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_056F_01CE5869.1CC9F150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Benoit, Thanks for cutting me in on this thread. I do think this type of discussion should take place on WG mailing lists so I am copying MANET on this reply. It appears that the phrase "performance metric" causes alarm bells to ring in several fire stations around the world. Although I strongly resent words or phrases being captured for more specific and focused meaning than they deserve, it is also clear that the pain caused by having a hundred firemen show up on your doorstep at 3am is sufficient (unless you like firemen at 3am ;-) to warrant taking Benoit's advice. - Avoid the term "performance metric" unless you mean it in the sense of RFC 6390 (or be prepared to have a fight) - Use the term "performance information" or maybe "performance counters" Adrian From: Benoit Claise [mailto:bclaise@cisco.com] Sent: 24 May 2013 09:33 To: Nguyen, James H CIV USARMY CERDEC (US) Cc: Fred Baker; draft-nguyen-manet-ecds-mib@tools.ietf.org; me; draft-ietf-manet-smf-mib@tools.ietf.org; pm-dir@ietf.org; Adrian Farrel Subject: Re: draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED) Hi James, draft-ietf-manet-smf-mib authors, Agreed, RFC 6390 doesn't apply here. See the email exchange regarding draft-ietf-manet-olsrv2-mib below, which I reviewed part of the performance metric directorate. Like Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to use "performance information" instead of "performance metrics" in your draft. Benoit, thank you very much for this review. I agree that using the term "performance information" instead of "performance metrics" is a good idea. We will make the change. Best regards Ulrich On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise wrote: Dear all, I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a performance metric directorate point of view. This draft doesn't contain any reference to RFC6390, but contains "performance metric". Hence this review was triggered. For details about the directorate, see http://www.ietf.org/iesg/directorate/performance-metrics.html Definition of Managed Objects for the Optimized Link State Routing Protocol version 2 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 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. Basically, all performance metrics come from this table: o olsrv2InterfacePerfTable - records performance counters for each active OLSRv2 interface on this device. selected path to each destination for which any such path is known. This table has AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via nhdpIfIndex from the NHDP-MIB. NHDP-MIB is RFC 6779: NhdpInterfacePerfEntry ::= SEQUENCE { nhdpIfHelloMessageXmits Counter32, nhdpIfHelloMessageRecvd Counter32, nhdpIfHelloMessageXmitAccumulatedSize Counter64, nhdpIfHelloMessageRecvdAccumulatedSize Counter64, nhdpIfHelloMessageTriggeredXmits Counter32, nhdpIfHelloMessagePeriodicXmits Counter32, nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount Counter32, nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount Counter32, nhdpIfHelloMessageXmitAccumulatedLostNeighborCount Counter32 } This draft contains similar objects in olsrv2InterfacePerfTable : Olsrv2InterfacePerfEntry ::= SEQUENCE { olsrv2IfTcMessageXmits Counter32, olsrv2IfTcMessageRecvd Counter32, olsrv2IfTcMessageXmitAccumulatedSize Counter64, olsrv2IfTcMessageRecvdAccumulatedSize Counter64, olsrv2IfTcMessageTriggeredXmits Counter32, olsrv2IfTcMessagePeriodicXmits Counter32, olsrv2IfTcMessageForwardedXmits Counter32, olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount Counter32 } Personally, I don't believe that those objects should be subject to the RFC 6390 template definition. (Performance Metric Definition Template, section 5.4.4, RFC 6390). First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not subject to it Second reason: these objects are not really performance metrics, but mainly basic monitoring objects. Since RFC 6779 uses the term performance information (in the abstract), I would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not the "performance metric". That would avoid some confusion. However, keeping the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency reason with RFC 6779. Regards, Benoit Regards, Benoit Classification: UNCLASSIFIED Caveats: NONE Fred, There are two counters that are defined for performance metrics. Please see below. As we stated it in Section 9 "Applicability Statement," ECDS-MIB is an extension of SMF-MIB. Thus, ECDS-MIB's inherited SMF-MIB's performance metrics. As I can see, ECDS-MIB does apply 6390's (i), (ii), (iii), and somewhat (iv). Please let me know if you have any suggestion to improve the draft. (i) the degree to which its absence would cause significant loss of information on the behavior or performance of the application or system being measured (ii) the correlation between the Performance Metric, the QoS, and the QoE delivered to the user (person or other application) (iii) the degree to which the Performance Metric is able to support the identification and location of problems affecting service quality (iv) the requirement to develop policies (Service Level Agreement, and potentially Service Level Contract) based on the Performance Metric -- -- E-CDS Performance Group -- ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 3 } ecdsInEcdsChange OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates how many times the current node is configured to be in E-CDS." ::= { ecdsPerformanceGroup 1 } ecdsCurrentRtrPriValueChange OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates how many times the Router Priority of the current node has been changed." ::= { ecdsPerformanceGroup 2 } James Nguyen US Army CERDEC S&TCD Email: james.h.nguyen4.civ@mail.mil Phone: 443-395-5628 -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Thursday, May 23, 2013 11:12 AM To: draft-nguyen-manet-ecds-mib@tools.ietf.org Cc: bclaise@cisco.com Subject: draft-nguyen-manet-ecds-mib and Performance Metrics Hi: I have a question for you. Your document mentions performance metrics. Would you kindly take a look at RFC 6390 to see if any of its considerations apply to it? "No" is an acceptable response, of course; the point is to ask the question. 6390 Guidelines for Considering New Performance Metric Development. A. Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also BCP0170) (Status: BEST CURRENT PRACTICE) Classification: UNCLASSIFIED Caveats: NONE ------=_NextPart_000_056F_01CE5869.1CC9F150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Benoit,

 

Thanks for cutting me in on = this thread.

 

I do think this type of = discussion should take place on WG mailing lists so I am copying MANET = on this reply.

 

It appears that the phrase = "performance metric" causes alarm bells to ring in several = fire stations around the world. Although I strongly resent words or = phrases being captured for more specific and focused meaning than they = deserve, it is also clear that the pain caused by having a hundred = firemen show up on your doorstep at 3am is sufficient (unless you like = firemen at 3am ;-) to warrant taking Benoit's = advice.

 

- Avoid the term = "performance metric" unless you mean it in = the

 sense of RFC 6390 (or be = prepared to have a fight)

- Use the term = "performance information" or maybe = "performance

  = counters"

 

<VBS>

 

Adrian

 

From: = Benoit Claise [mailto:bclaise@cisco.com]
Sent: 24 May 2013 = 09:33
To: Nguyen, James H CIV USARMY CERDEC (US)
Cc: = Fred Baker; draft-nguyen-manet-ecds-mib@tools.ietf.org; me; = draft-ietf-manet-smf-mib@tools.ietf.org; pm-dir@ietf.org; Adrian = Farrel
Subject: Re: draft-nguyen-manet-ecds-mib and = Performance Metrics (UNCLASSIFIED)

 

Hi James, = draft-ietf-manet-smf-mib authors,

Agreed, RFC 6390 doesn't apply = here.
See the email exchange regarding draft-ietf-manet-olsrv2-mib = below, which I reviewed part of the performance metric = directorate.
Like Ulrich did for draft-ietf-manet-olsrv2-mib, it = might better to use "performance information" instead of = "performance metrics" in your = draft.

Benoit,
 =

thank you very much for this review. I agree that using =
the term
"performance information" =
instead of "performance metrics" is a =
good
idea. We will make the =
change.
 
Best =
regards
Ulrich
 
On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <bclaise@cisco.com> =
wrote:
Dear =
all,
 
I reviewed http:/=
/tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from =
a
performance metric directorate point of =
view.
 
This draft =
doesn't contain any reference to RFC6390, but =
contains
"performance metric". Hence this =
review was triggered. For details about =
the
directorate, see
ht=
tp://www.ietf.org/iesg/directorate/performance-metrics.html
 
 
Defin=
ition of Managed Objects for the  =
Optimized Link State Routing
Protocol =
version =
2
 
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 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.
 
 
Basically, all performance metrics come from this =
table:
 
   o  olsrv2InterfacePerfTable - =
records performance counters for each
      active =
OLSRv2 interface on this device. selected path to =
each
      =
destination for which any such path is known.  This table =
has
      =
AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed =
via
      =
nhdpIfIndex from the =
NHDP-MIB.
 
NHDP-MIB is =
RFC 6779:
   NhdpInterfacePerfEntry =
::=3D
      =
SEQUENCE {
       &nbs=
p; nhdpIfHelloMessageXmits
       &nbs=
p;    Counter32,
       &nbs=
p; nhdpIfHelloMessageRecvd
       &nbs=
p;    Counter32,
       &nbs=
p; =
nhdpIfHelloMessageXmitAccumulatedSize
       &nbs=
p;    Counter64,
       &nbs=
p; =
nhdpIfHelloMessageRecvdAccumulatedSize
       &nbs=
p;    Counter64,
       &nbs=
p; nhdpIfHelloMessageTriggeredXmits
       &nbs=
p;    Counter32,
       &nbs=
p; nhdpIfHelloMessagePeriodicXmits
       &nbs=
p;    Counter32,
       &nbs=
p; =
nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount=

       &nbs=
p;    Counter32,
       &nbs=
p; =
nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
       &nbs=
p;    Counter32,
       &nbs=
p; =
nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
       &nbs=
p;    Counter32
      =
}
 
 
This draft contains similar objects in =
olsrv2InterfacePerfTable =
:
 
    =
Olsrv2InterfacePerfEntry ::=3D
       =
SEQUENCE {
       &nbs=
p;  olsrv2IfTcMessageXmits
       &nbs=
p;     Counter32,
       &nbs=
p;  olsrv2IfTcMessageRecvd
       &nbs=
p;     Counter32,
       &nbs=
p;  =
olsrv2IfTcMessageXmitAccumulatedSize
       &nbs=
p;     Counter64,
       &nbs=
p;  =
olsrv2IfTcMessageRecvdAccumulatedSize
       &nbs=
p;     Counter64,
       &nbs=
p;  =
olsrv2IfTcMessageTriggeredXmits
       &nbs=
p;     Counter32,
        =
  olsrv2IfTcMessagePeriodicXm=
its
       &nbs=
p;     Counter32,
       &nbs=
p;  =
olsrv2IfTcMessageForwardedXmits
       &nbs=
p;     Counter32,
       &nbs=
p;  =
olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
<=
pre>       &nbs=
p;     Counter32
       =
}
 
 
Personally, I don't believe that those objects should be =
subject to the RFC
6390 template definition. =
(Performance Metric Definition Template, =
section
5.4.4, RFC =
6390).
First reason: NhdpInterfacePerfEntry, from =
NHDP-MIB [RFC 6779] was not
subject to =
it
Second reason: these objects are not really =
performance metrics, but mainly
basic monitoring =
objects.
 
Since RFC 6779 =
uses the term performance information (in the abstract), =
I
would propose that draft-ietf-manet-olsrv2-mib =
also uses this term, and not
the "performance =
metric". That would avoid some confusion. However, =
keeping
the olsrv2InterfacePerfTable OID name is =
perfectly fine, for consistency
reason with RFC =
6779.
 
Regards, =
Benoit
 

Regards, Benoit
Classification: =
UNCLASSIFIED
Caveats: =
NONE
 
Fred,
 
There are two counters that are =
defined for performance metrics.  =
Please see
below.  As we stated it in Section 9 =
"Applicability Statement," ECDS-MIB is
an =
extension of SMF-MIB.  =
Thus, ECDS-MIB's inherited SMF-MIB's =
performance
metrics.  =

 
As I can see, =
ECDS-MIB does apply 6390's (i), (ii), (iii), and =
somewhat
(iv).  Please let me know if you have =
any suggestion to improve the =
draft.
 
 =

      (i) the =
degree to which its absence would cause significant =
loss
      of =
information on the behavior or performance of the =
application
      or =
system being =
measured
 
      (ii) =
the correlation between the Performance Metric, the QoS, =
and
      the QoE =
delivered to the user (person or other =
application)
 
      (iii) =
the degree to which the Performance Metric is able =
to
      support =
the identification and location of problems =
affecting
      service =
quality
 
      (iv) =
the requirement to develop policies (Service Level =
Agreement,
      and =
potentially Service Level Contract) based on the =
Performance
      Metric
=
 
 
 
--
 -- E-CDS Performance =
Group
 =
--
 
 =
ecdsPerformanceGroup OBJECT IDENTIFIER ::=3D { ecdsMIBObjects 3 =
}
 
 ecdsInEcdsChange =
OBJECT-TYPE
       &nbs=
p; SYNTAX       &nbs=
p;  Counter32
       &nbs=
p; MAX-ACCESS      =
read-only
       &nbs=
p; STATUS       &nbs=
p;  current
       &nbs=
p; DESCRIPTION
       &nbs=
p;         "This =
object indicates how many times the current
       &nbs=
p;          node is =
configured to be in E-CDS."
 ::=3D { =
ecdsPerformanceGroup 1 =
}
 
 =
ecdsCurrentRtrPriValueChange OBJECT-TYPE
       &nbs=
p; SYNTAX       &nbs=
p;  Counter32
       &nbs=
p; MAX-ACCESS      =
read-only
       &nbs=
p; STATUS       &nbs=
p;  current
       &nbs=
p; DESCRIPTION
       &nbs=
p;         "This =
object indicates how many times the Router
       &nbs=
p;          Priority =
of the current node has been changed."
 ::=3D =
{ ecdsPerformanceGroup 2 =
}
 
 
 
James Nguyen
US =
Army CERDEC S&TCD
Email: james.h.nguyen4.civ@mail.mil=

Phone:  =
443-395-5628
 
 
-----Original =
Message-----
From: Fred Baker [mailto:fred@cisco.com] =

Sent: Thursday, May 23, 2013 11:12 =
AM
To: draft-nguyen-m=
anet-ecds-mib@tools.ietf.org
Cc: bclaise@cisco.com
<=
pre>Subject: draft-nguyen-manet-ecds-mib and Performance =
Metrics
 
Hi:
 
I have a question for you. Your =
document mentions performance metrics.
Would you =
kindly take a look at RFC 6390 to see if any of its =
considerations
apply to it?  "No" is an acceptable =
response, of course; the point is to ask
the =
question.
 
6390 =
Guidelines for Considering New Performance Metric Development. =
A.
     Clark, B. =
Claise. October 2011. (Format: TXT=3D49930 bytes) =
(Also
     BCP0170) =
(Status: BEST CURRENT =
PRACTICE)
 
 
Classification: UNCLASSIFIED
Caveats: =
NONE
 
 

 

------=_NextPart_000_056F_01CE5869.1CC9F150-- From bclaise@cisco.com Fri May 24 03:04:03 2013 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A057D21F96C2; Fri, 24 May 2013 03:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.129 X-Spam-Level: X-Spam-Status: No, score=-9.129 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, TRACKER_ID=2.003] 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 pwqmrqpVEofW; Fri, 24 May 2013 03:03:58 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id CE60021F969E; Fri, 24 May 2013 03:03:57 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4OA3sI3024465; Fri, 24 May 2013 12:03:54 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4OA2YEg008197; Fri, 24 May 2013 12:02:49 +0200 (CEST) Message-ID: <519F3ABA.6090703@cisco.com> Date: Fri, 24 May 2013 12:02:34 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <201305231512.r4NFCMN4006908@irp-view13.cisco.com> <3DC26342A93F204C804384C87DDBECBF3DADF508@ucolhp9k.easf.csd.disa.mil> <519F25A0.70502@cisco.com> <056b01ce5860$bafed290$30fc77b0$@olddog.co.uk> In-Reply-To: <056b01ce5860$bafed290$30fc77b0$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------030609020605040409000007" Cc: manet@ietf.org, draft-nguyen-manet-ecds-mib@tools.ietf.org, draft-ietf-manet-smf-mib@tools.ietf.org, 'Fred Baker' , pm-dir@ietf.org Subject: Re: [manet] draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 10:04:03 -0000 This is a multi-part message in MIME format. --------------030609020605040409000007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, > Hi Benoit, > > Thanks for cutting me in on this thread. > > I do think this type of discussion should take place on WG mailing > lists so I am copying MANET on this reply. > > It appears that the phrase "performance metric" causes alarm bells to > ring in several fire stations around the world. Although I strongly > resent words or phrases being captured for more specific and focused > meaning than they deserve, it is also clear that the pain caused by > having a hundred firemen show up on your doorstep at 3am is sufficient > (unless you like firemen at 3am ;-) to warrant taking Benoit's advice. > > - Avoid the term "performance metric" unless you mean it in the > > sense of RFC 6390 (or be prepared to have a fight) > This is simply not correct! Based on my two messages below (for the 2 drafts): Since RFC 6779 uses the term performance information (in the abstract), I would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not the "performance metric". That would avoid some confusion. ... Like Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to use "performance information" instead of "performance metrics" in your draft. These are advice, and should be considered as such. Regards, Benoit > - Use the term "performance information" or maybe "performance > > counters" > > > > Adrian > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* 24 May 2013 09:33 > *To:* Nguyen, James H CIV USARMY CERDEC (US) > *Cc:* Fred Baker; draft-nguyen-manet-ecds-mib@tools.ietf.org; me; > draft-ietf-manet-smf-mib@tools.ietf.org; pm-dir@ietf.org; Adrian Farrel > *Subject:* Re: draft-nguyen-manet-ecds-mib and Performance Metrics > (UNCLASSIFIED) > > Hi James, draft-ietf-manet-smf-mib authors, > > Agreed, RFC 6390 doesn't apply here. > See the email exchange regarding draft-ietf-manet-olsrv2-mib below, > which I reviewed part of the performance metric directorate. > Like Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to > use "performance information" instead of "performance metrics" in your > draft. > > Benoit, > > thank you very much for this review. I agree that using the term > "performance information" instead of "performance metrics" is a good > idea. We will make the change. > > Best regards > Ulrich > > On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise wrote: > Dear all, > > I reviewedhttp://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a > performance metric directorate point of view. > > This draft doesn't contain any reference to RFC6390, but contains > "performance metric". Hence this review was triggered. For details about the > directorate, see > http://www.ietf.org/iesg/directorate/performance-metrics.html > > > Definition of Managed Objects for the Optimized Link State Routing > Protocol version 2 > > 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 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. > > > Basically, all performance metrics come from this table: > > o olsrv2InterfacePerfTable - records performance counters for each > active OLSRv2 interface on this device. selected path to each > destination for which any such path is known. This table has > AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via > nhdpIfIndex from the NHDP-MIB. > > NHDP-MIB is RFC 6779: > NhdpInterfacePerfEntry ::= > SEQUENCE { > nhdpIfHelloMessageXmits > Counter32, > nhdpIfHelloMessageRecvd > Counter32, > nhdpIfHelloMessageXmitAccumulatedSize > Counter64, > nhdpIfHelloMessageRecvdAccumulatedSize > Counter64, > nhdpIfHelloMessageTriggeredXmits > Counter32, > nhdpIfHelloMessagePeriodicXmits > Counter32, > nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount > Counter32, > nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount > Counter32, > nhdpIfHelloMessageXmitAccumulatedLostNeighborCount > Counter32 > } > > > This draft contains similar objects in olsrv2InterfacePerfTable : > > Olsrv2InterfacePerfEntry ::= > SEQUENCE { > olsrv2IfTcMessageXmits > Counter32, > olsrv2IfTcMessageRecvd > Counter32, > olsrv2IfTcMessageXmitAccumulatedSize > Counter64, > olsrv2IfTcMessageRecvdAccumulatedSize > Counter64, > olsrv2IfTcMessageTriggeredXmits > Counter32, > olsrv2IfTcMessagePeriodicXmits > Counter32, > olsrv2IfTcMessageForwardedXmits > Counter32, > olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount > Counter32 > } > > > Personally, I don't believe that those objects should be subject to the RFC > 6390 template definition. (Performance Metric Definition Template, section > 5.4.4, RFC 6390). > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not > subject to it > Second reason: these objects are not really performance metrics, but mainly > basic monitoring objects. > > Since RFC 6779 uses the term performance information (in the abstract), I > would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not > the "performance metric". That would avoid some confusion. However, keeping > the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency > reason with RFC 6779. > > Regards, Benoit > > > > Regards, Benoit > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > Fred, > > > > There are two counters that are defined for performance metrics. Please see > > below. As we stated it in Section 9 "Applicability Statement," ECDS-MIB is > > an extension of SMF-MIB. Thus, ECDS-MIB's inherited SMF-MIB's performance > > metrics. > > > > As I can see, ECDS-MIB does apply 6390's (i), (ii), (iii), and somewhat > > (iv). Please let me know if you have any suggestion to improve the draft. > > > > > > (i) the degree to which its absence would cause significant loss > > of information on the behavior or performance of the application > > or system being measured > > > > (ii) the correlation between the Performance Metric, the QoS, and > > the QoE delivered to the user (person or other application) > > > > (iii) the degree to which the Performance Metric is able to > > support the identification and location of problems affecting > > service quality > > > > (iv) the requirement to develop policies (Service Level Agreement, > > and potentially Service Level Contract) based on the Performance > > Metric > > > > > > > > -- > > -- E-CDS Performance Group > > -- > > > > ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 3 } > > > > ecdsInEcdsChange OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object indicates how many times the current > > node is configured to be in E-CDS." > > ::= { ecdsPerformanceGroup 1 } > > > > ecdsCurrentRtrPriValueChange OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object indicates how many times the Router > > Priority of the current node has been changed." > > ::= { ecdsPerformanceGroup 2 } > > > > > > > > James Nguyen > > US Army CERDEC S&TCD > > Email:james.h.nguyen4.civ@mail.mil > > Phone: 443-395-5628 > > > > > > -----Original Message----- > > From: Fred Baker [mailto:fred@cisco.com] > > Sent: Thursday, May 23, 2013 11:12 AM > > To:draft-nguyen-manet-ecds-mib@tools.ietf.org > > Cc:bclaise@cisco.com > > Subject: draft-nguyen-manet-ecds-mib and Performance Metrics > > > > Hi: > > > > I have a question for you. Your document mentions performance metrics. > > Would you kindly take a look at RFC 6390 to see if any of its considerations > > apply to it? "No" is an acceptable response, of course; the point is to ask > > the question. > > > > 6390 Guidelines for Considering New Performance Metric Development. A. > > Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also > > BCP0170) (Status: BEST CURRENT PRACTICE) > > > > > > Classification: UNCLASSIFIED > > Caveats: NONE > > > > > --------------030609020605040409000007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Adrian,

Hi Benoit,

 

Thanks for cutting me in on this thread.

 

I do think this type of discussion should take place on WG mailing lists so I am copying MANET on this reply.

 

It appears that the phrase "performance metric" causes alarm bells to ring in several fire stations around the world. Although I strongly resent words or phrases being captured for more specific and focused meaning than they deserve, it is also clear that the pain caused by having a hundred firemen show up on your doorstep at 3am is sufficient (unless you like firemen at 3am ;-) to warrant taking Benoit's advice.

 

- Avoid the term "performance metric" unless you mean it in the

 sense of RFC 6390 (or be prepared to have a fight)

This is simply not correct!
Based on my two messages below (for the 2 drafts):
Since RFC 6779 uses the term performance information (in the abstract), I
would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not
the "performance metric". That would avoid some confusion.

...

Like 
Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to use 
"performance information" instead of "performance metrics" in your 
draft.
These are advice, and should be considered as such.

Regards, Benoit

    

      

        

        
- Use the term "performance
            information" or maybe "performance

        
  counters"

        
 

        
<VBS>

        
 

        
Adrian

        
 

        

          

            

              
From: Benoit Claise [mailto:bclaise@cisco.com]
                  

                  Sent: 24 May 2013 09:33

                  To: Nguyen, James H CIV USARMY CERDEC (US)

                  Cc: Fred Baker;
                  draft-nguyen-manet-ecds-mib@tools.ietf.org; me;
                  draft-ietf-manet-smf-mib@tools.ietf.org;
                  pm-dir@ietf.org; Adrian Farrel

                  Subject: Re: draft-nguyen-manet-ecds-mib and
                  Performance Metrics (UNCLASSIFIED)

            

          

          
 

          

            
Hi James, draft-ietf-manet-smf-mib authors,

                

                Agreed, RFC 6390 doesn't apply here.

                See the email exchange regarding
                draft-ietf-manet-olsrv2-mib below, which I reviewed part
                of the performance metric directorate.

                Like Ulrich did for draft-ietf-manet-olsrv2-mib, it
                might better to use "performance information" instead of
                "performance metrics" in your draft.

            
Benoit,

            
 

            
thank you very much for this review. I agree that using the term

            
"performance information" instead of "performance metrics" is a good

            
idea. We will make the change.

            
 

            
Best regards

            
Ulrich

            
 

            
On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <bclaise@cisco.com> wrote:

            
Dear all,

            
 

            
I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a

            
performance metric directorate point of view.

            
 

            
This draft doesn't contain any reference to RFC6390, but contains

            
"performance metric". Hence this review was triggered. For details about the

            
directorate, see

            
http://www.ietf.org/iesg/directorate/performance-metrics.html

            
 

            
 

            
Definition of Managed Objects for the  Optimized Link State Routing

            
Protocol version 2

            
 

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

            
 

            
 

            
Basically, all performance metrics come from this table:

            
 

            
   o  olsrv2InterfacePerfTable - records performance counters for each

            
      active OLSRv2 interface on this device. selected path to each

            
      destination for which any such path is known.  This table has

            
      AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via

            
      nhdpIfIndex from the NHDP-MIB.

            
 

            
NHDP-MIB is RFC 6779:

            
   NhdpInterfacePerfEntry ::=

            
      SEQUENCE {

            
         nhdpIfHelloMessageXmits

            
            Counter32,

            
         nhdpIfHelloMessageRecvd

            
            Counter32,

            
         nhdpIfHelloMessageXmitAccumulatedSize

            
            Counter64,

            
         nhdpIfHelloMessageRecvdAccumulatedSize

            
            Counter64,

            
         nhdpIfHelloMessageTriggeredXmits

            
            Counter32,

            
         nhdpIfHelloMessagePeriodicXmits

            
            Counter32,

            
         nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount

            
            Counter32,

            
         nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount

            
            Counter32,

            
         nhdpIfHelloMessageXmitAccumulatedLostNeighborCount

            
            Counter32

            
      }

            
 

            
 

            
This draft contains similar objects in olsrv2InterfacePerfTable :

            
 

            
    Olsrv2InterfacePerfEntry ::=

            
       SEQUENCE {

            
          olsrv2IfTcMessageXmits

            
             Counter32,

            
          olsrv2IfTcMessageRecvd

            
             Counter32,

            
          olsrv2IfTcMessageXmitAccumulatedSize

            
             Counter64,

            
          olsrv2IfTcMessageRecvdAccumulatedSize

            
             Counter64,

            
          olsrv2IfTcMessageTriggeredXmits

            
             Counter32,

            
          olsrv2IfTcMessagePeriodicXmits

            
             Counter32,

            
          olsrv2IfTcMessageForwardedXmits

            
             Counter32,

            
          olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount

            
             Counter32

            
       }

            
 

            
 

            
Personally, I don't believe that those objects should be subject to the RFC

            
6390 template definition. (Performance Metric Definition Template, section

            
5.4.4, RFC 6390).

            
First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not

            
subject to it

            
Second reason: these objects are not really performance metrics, but mainly

            
basic monitoring objects.

            
 

            
Since RFC 6779 uses the term performance information (in the abstract), I

            
would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not

            
the "performance metric". That would avoid some confusion. However, keeping

            
the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency

            
reason with RFC 6779.

            
 

            
Regards, Benoit

            
 

            


                Regards, Benoit

          

          

            
Classification: UNCLASSIFIED

            
Caveats: NONE

            
 

            
Fred,

            
 

            
There are two counters that are defined for performance metrics.  Please see

            
below.  As we stated it in Section 9 "Applicability Statement," ECDS-MIB is

            
an extension of SMF-MIB.  Thus, ECDS-MIB's inherited SMF-MIB's performance

            
metrics.  

            
 

            
As I can see, ECDS-MIB does apply 6390's (i), (ii), (iii), and somewhat

            
(iv).  Please let me know if you have any suggestion to improve the draft.

            
 

            
 

            
      (i) the degree to which its absence would cause significant loss

            
      of information on the behavior or performance of the application

            
      or system being measured

            
 

            
      (ii) the correlation between the Performance Metric, the QoS, and

            
      the QoE delivered to the user (person or other application)

            
 

            
      (iii) the degree to which the Performance Metric is able to

            
      support the identification and location of problems affecting

            
      service quality

            
 

            
      (iv) the requirement to develop policies (Service Level Agreement,

            
      and potentially Service Level Contract) based on the Performance

            
      Metric

            
 

            
 

            
 

            
--

            
 -- E-CDS Performance Group

            
 --

            
 

            
 ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 3 }

            
 

            
 ecdsInEcdsChange OBJECT-TYPE

            
         SYNTAX          Counter32

            
         MAX-ACCESS      read-only

            
         STATUS          current

            
         DESCRIPTION

            
                 "This object indicates how many times the current

            
                  node is configured to be in E-CDS."

            
 ::= { ecdsPerformanceGroup 1 }

            
 

            
 ecdsCurrentRtrPriValueChange OBJECT-TYPE

            
         SYNTAX          Counter32

            
         MAX-ACCESS      read-only

            
         STATUS          current

            
         DESCRIPTION

            
                 "This object indicates how many times the Router

            
                  Priority of the current node has been changed."

            
 ::= { ecdsPerformanceGroup 2 }

            
 

            
 

            
 

            
James Nguyen

            
US Army CERDEC S&TCD

            
Email: james.h.nguyen4.civ@mail.mil

            
Phone:  443-395-5628

            
 

            
 

            
-----Original Message-----

            
From: Fred Baker [mailto:fred@cisco.com] 

            
Sent: Thursday, May 23, 2013 11:12 AM

            
To: draft-nguyen-manet-ecds-mib@tools.ietf.org

            
Cc: bclaise@cisco.com

            
Subject: draft-nguyen-manet-ecds-mib and Performance Metrics

            
 

            
Hi:

            
 

            
I have a question for you. Your document mentions performance metrics.

            
Would you kindly take a look at RFC 6390 to see if any of its considerations

            
apply to it?  "No" is an acceptable response, of course; the point is to ask

            
the question.

            
 

            
6390 Guidelines for Considering New Performance Metric Development. A.

            
     Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also

            
     BCP0170) (Status: BEST CURRENT PRACTICE)

            
 

            
 

            
Classification: UNCLASSIFIED

            
Caveats: NONE

            
 

            
 

          

          
 

        

      

    

    

  


--------------030609020605040409000007--

From robert.g.cole.civ@mail.mil  Fri May 24 05:55:15 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F3A21F8FDC; Fri, 24 May 2013 05:55:15 -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, J_CHICKENPOX_13=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 0ZFqiDtTiGcK; Fri, 24 May 2013 05:55:10 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6461121F85EE; Fri, 24 May 2013 05:55:10 -0700 (PDT)
Received: from UCOLHP3P.easf.csd.disa.mil (131.64.100.155) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 24 May 2013 12:55:04 +0000
Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.190]) by UCOLHP3P.easf.csd.disa.mil ([131.64.100.155]) with mapi id 14.03.0123.003; Fri, 24 May 2013 12:54:56 +0000
From: "Cole, Robert G CIV USARMY CERDEC (US)" 
To: Benoit Claise , "adrian@olddog.co.uk" 
Thread-Topic: draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED)
Thread-Index: AQHOV8sGWVHgdInXtkehgls0oum9CZkUAuEAgAAO/ACAAAosAIAALgeQ
Date: Fri, 24 May 2013 12:54:51 +0000
Message-ID: 
References: <201305231512.r4NFCMN4006908@irp-view13.cisco.com> <3DC26342A93F204C804384C87DDBECBF3DADF508@ucolhp9k.easf.csd.disa.mil> <519F25A0.70502@cisco.com> <056b01ce5860$bafed290$30fc77b0$@olddog.co.uk> <519F3ABA.6090703@cisco.com>
In-Reply-To: <519F3ABA.6090703@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [131.64.62.4]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0012_01CE585C.5BFCC210"
MIME-Version: 1.0
Cc: "manet@ietf.org" , "draft-nguyen-manet-ecds-mib@tools.ietf.org" , "draft-ietf-manet-smf-mib@tools.ietf.org" , 'Fred Baker' , "pm-dir@ietf.org" 
Subject: Re: [manet] draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 May 2013 12:55:15 -0000

------=_NextPart_000_0012_01CE585C.5BFCC210
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Classification: UNCLASSIFIED
Caveats: NONE

I agree that we should be more precise in our naming and descriptions.  This
question is showing up often in our MIB discussions.  I have made it a habit
of placing these counters within a PerformanceGroup instead of a
StatisticsGroup because I felt that Statistics implied we were collecting
statistical data (e.g., averages) instead of performance data (counts).  But
I agree that using the term Performance Metric goes too far and is not a
correct description of the data.  Going forward I'll try to be more
consistent and use the term 'Performance Information' as you all suggest and
as we did in RFC 6779.

Thanks,
Bob

Robert G. Cole
Comm:  443.395.8744
Email: robert.g.cole@us.army.mil


-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Friday, May 24, 2013 6:03 AM
To: adrian@olddog.co.uk
Cc: Nguyen, James H CIV USARMY CERDEC (US); 'Fred Baker';
draft-nguyen-manet-ecds-mib@tools.ietf.org;
draft-ietf-manet-smf-mib@tools.ietf.org; pm-dir@ietf.org; manet@ietf.org
Subject: Re: draft-nguyen-manet-ecds-mib and Performance Metrics
(UNCLASSIFIED)

Hi Adrian,



	Hi Benoit,

	 

	Thanks for cutting me in on this thread.

	 

	I do think this type of discussion should take place on WG mailing
lists so I am copying MANET on this reply.

	 

	It appears that the phrase "performance metric" causes alarm bells
to ring in several fire stations around the world. Although I strongly
resent words or phrases being captured for more specific and focused meaning
than they deserve, it is also clear that the pain caused by having a hundred
firemen show up on your doorstep at 3am is sufficient (unless you like
firemen at 3am ;-) to warrant taking Benoit's advice.

	 

	- Avoid the term "performance metric" unless you mean it in the

	 sense of RFC 6390 (or be prepared to have a fight)

This is simply not correct!
Based on my two messages below (for the 2 drafts):


	Since RFC 6779 uses the term performance information (in the
abstract), I
	would propose that draft-ietf-manet-olsrv2-mib also uses this term,
and not
	the "performance metric". That would avoid some confusion.
	
	...
	
	Like 
	Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to use 
	"performance information" instead of "performance metrics" in your 
	draft.

These are advice, and should be considered as such.

Regards, Benoit



	

	- Use the term "performance information" or maybe "performance

	  counters"

	 

	

	 

	Adrian

	 

	From: Benoit Claise [mailto:bclaise@cisco.com
 ] 
	Sent: 24 May 2013 09:33
	To: Nguyen, James H CIV USARMY CERDEC (US)
	Cc: Fred Baker; draft-nguyen-manet-ecds-mib@tools.ietf.org; me;
draft-ietf-manet-smf-mib@tools.ietf.org; pm-dir@ietf.org; Adrian Farrel
	Subject: Re: draft-nguyen-manet-ecds-mib and Performance Metrics
(UNCLASSIFIED)

	 

	Hi James, draft-ietf-manet-smf-mib authors,
	
	Agreed, RFC 6390 doesn't apply here.
	See the email exchange regarding draft-ietf-manet-olsrv2-mib below,
which I reviewed part of the performance metric directorate.
	Like Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to
use "performance information" instead of "performance metrics" in your
draft.

	Benoit,
	 
	thank you very much for this review. I agree that using the term
	"performance information" instead of "performance metrics" is a good
	idea. We will make the change.
	 
	Best regards
	Ulrich
	 
	On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise 
  wrote:
	Dear all,
	 
	I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06
 , from a
	performance metric directorate point of view.
	 
	This draft doesn't contain any reference to RFC6390, but contains
	"performance metric". Hence this review was triggered. For details
about the
	directorate, see
	http://www.ietf.org/iesg/directorate/performance-metrics.html
 
	 
	 
	Definition of Managed Objects for the  Optimized Link State Routing
	Protocol version 2
	 
	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 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.
	 
	 
	Basically, all performance metrics come from this table:
	 
	   o  olsrv2InterfacePerfTable - records performance counters for
each
	      active OLSRv2 interface on this device. selected path to each
	      destination for which any such path is known.  This table has
	      AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed
via
	      nhdpIfIndex from the NHDP-MIB.
	 
	NHDP-MIB is RFC 6779:
	   NhdpInterfacePerfEntry ::=
	      SEQUENCE {
	         nhdpIfHelloMessageXmits
	            Counter32,
	         nhdpIfHelloMessageRecvd
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedSize
	            Counter64,
	         nhdpIfHelloMessageRecvdAccumulatedSize
	            Counter64,
	         nhdpIfHelloMessageTriggeredXmits
	            Counter32,
	         nhdpIfHelloMessagePeriodicXmits
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
	            Counter32
	      }
	 
	 
	This draft contains similar objects in olsrv2InterfacePerfTable :
	 
	    Olsrv2InterfacePerfEntry ::=
	       SEQUENCE {
	          olsrv2IfTcMessageXmits
	             Counter32,
	          olsrv2IfTcMessageRecvd
	             Counter32,
	          olsrv2IfTcMessageXmitAccumulatedSize
	             Counter64,
	          olsrv2IfTcMessageRecvdAccumulatedSize
	             Counter64,
	          olsrv2IfTcMessageTriggeredXmits
	             Counter32,
	          olsrv2IfTcMessagePeriodicXmits
	             Counter32,
	          olsrv2IfTcMessageForwardedXmits
	             Counter32,
	          olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
	             Counter32
	       }
	 
	 
	Personally, I don't believe that those objects should be subject to
the RFC
	6390 template definition. (Performance Metric Definition Template,
section
	5.4.4, RFC 6390).
	First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was
not
	subject to it
	Second reason: these objects are not really performance metrics, but
mainly
	basic monitoring objects.
	 
	Since RFC 6779 uses the term performance information (in the
abstract), I
	would propose that draft-ietf-manet-olsrv2-mib also uses this term,
and not
	the "performance metric". That would avoid some confusion. However,
keeping
	the olsrv2InterfacePerfTable OID name is perfectly fine, for
consistency
	reason with RFC 6779.
	 
	Regards, Benoit
	 

	
	Regards, Benoit

		Classification: UNCLASSIFIED
		Caveats: NONE
		 
		Fred,
		 
		There are two counters that are defined for performance
metrics.  Please see
		below.  As we stated it in Section 9 "Applicability
Statement," ECDS-MIB is
		an extension of SMF-MIB.  Thus, ECDS-MIB's inherited
SMF-MIB's performance
		metrics.  
		 
		As I can see, ECDS-MIB does apply 6390's (i), (ii), (iii),
and somewhat
		(iv).  Please let me know if you have any suggestion to
improve the draft.
		 
		 
		      (i) the degree to which its absence would cause
significant loss
		      of information on the behavior or performance of the
application
		      or system being measured
		 
		      (ii) the correlation between the Performance Metric,
the QoS, and
		      the QoE delivered to the user (person or other
application)
		 
		      (iii) the degree to which the Performance Metric is
able to
		      support the identification and location of problems
affecting
		      service quality
		 
		      (iv) the requirement to develop policies (Service
Level Agreement,
		      and potentially Service Level Contract) based on the
Performance
		      Metric
		 
		 
		 
		--
		 -- E-CDS Performance Group
		 --
		 
		 ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects
3 }
		 
		 ecdsInEcdsChange OBJECT-TYPE
		         SYNTAX          Counter32
		         MAX-ACCESS      read-only
		         STATUS          current
		         DESCRIPTION
		                 "This object indicates how many times the
current
		                  node is configured to be in E-CDS."
		 ::= { ecdsPerformanceGroup 1 }
		 
		 ecdsCurrentRtrPriValueChange OBJECT-TYPE
		         SYNTAX          Counter32
		         MAX-ACCESS      read-only
		         STATUS          current
		         DESCRIPTION
		                 "This object indicates how many times the
Router
		                  Priority of the current node has been
changed."
		 ::= { ecdsPerformanceGroup 2 }
		 
		 
		 
		James Nguyen
		US Army CERDEC S&TCD
		Email: james.h.nguyen4.civ@mail.mil
		Phone:  443-395-5628
		 
		 
		-----Original Message-----
		From: Fred Baker [mailto:fred@cisco.com
 ] 
		Sent: Thursday, May 23, 2013 11:12 AM
		To: draft-nguyen-manet-ecds-mib@tools.ietf.org
		Cc: bclaise@cisco.com
		Subject: draft-nguyen-manet-ecds-mib and Performance Metrics
		 
		Hi:
		 
		I have a question for you. Your document mentions
performance metrics.
		Would you kindly take a look at RFC 6390 to see if any of
its considerations
		apply to it?  "No" is an acceptable response, of course; the
point is to ask
		the question.
		 
		6390 Guidelines for Considering New Performance Metric
Development. A.
		     Clark, B. Claise. October 2011. (Format: TXT=49930
bytes) (Also
		     BCP0170) (Status: BEST CURRENT PRACTICE)
		 
		 
		Classification: UNCLASSIFIED
		Caveats: NONE
		 
		 

	 



Classification: UNCLASSIFIED
Caveats: NONE



------=_NextPart_000_0012_01CE585C.5BFCC210
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw
ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g
R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290
IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG
A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE
AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/
PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X
3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt
upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7
f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK
AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ
gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/
ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1
K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx
Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO
8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K
ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDMEEgMA0GCSqGSIb3DQEBBQUA
MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM
MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTMwMjI2MDAwMDAwWhcN
MTYwMjI1MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww
CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP
QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOqO
/17DG7aYs9uSnP/+p6Gsq8VEWYasP2AFK4fLX6EddXT0Xbpl+6D65ocPNoVOejCt3xTUZTUpcujL
ca/fkpqdpIgyqLY/TwXncfjejcKneIkXb9xAUfAfjIU1S+GVQCZx5qWrRwqhvGq5LHadRDZh5FN/
71vZyqrqCAg/NqYEvn8O0WlQefyhCOnbBDS06o0Xs2MhNVmaoMq0+9owe0sc3Tom3TxE6FqsJ0lf
5D7BK5x7qyAE3OdbMCxHIIbFYfayGr43zucoJgx73fFYPlMhC1FL5tzWdoaudbJcS3CxgQo3xF+v
7LwtAscs1MnrTs0xR5WlUrGIYNYU7cIPZD8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh
eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js
L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL
CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFPWwve21KZ20gQuIqDaDVMnON8uNMGgGCCsGAQUFBwEB
BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku
Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyb2JlcnQu
Zy5jb2xlQHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN
AQEFBQADggEBABxQGaSlVFdP9mklREX71YtmZGbQcR8xvgT/VAWAS5wBtmAsQ6A9DWj3OoAqCBUk
lqaxMyqsfIkVMRMOw+U5RSj5A8fDnnzMuvtooPbpb4gQxH9fQ8ELFluuMpD1cx/pZT+zARV3ClZX
6g2aZolBtk17r/2/dsRcvhO8uIOpI6IFYToCn6ZfnrXXSMKf74LAfigeXpsay23M8Vv9HTVPMUyg
AVQl9uEyOApG9V10gNqUihZcJIOz6lpUG2xJ50npdKPBhAwcZLZXKqIHchthupFDFbKFbf3VGPV5
KVer+zC/5D0IUZzdUWtPSERWi+OFOfipi75Y5oIYHoY/U36HV1cwggUCMIID6qADAgECAgMwQR0w
DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM
MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x
MzAyMjYwMDAwMDBaFw0xNjAyMjUyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu
IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk
BgNVBAMTHUNPTEUuUk9CRVJULkdSQU5PVC4xMzY2NTYwMzkwMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAq4oVK/5DQ8R/9nLb97oeOJPzP7qjER2TA2ue96H+4ZHs8GGFtiN1jciBqfKr
ce0iINLWxbeeCUR62zPQCLxfp2EG0/C1zz6W7E7O7z5CnPPeDF+IpaeM4yB1kztkGx6ONNAJMJ+k
oxbJxgEGE+RY51EQUYKwOSi8hq+IandF5hP6krnLHg16DARSr29h3NHmFrfCkkPIcrSMNXZLFI5X
JIInqpfgQPeR9MxKPTh970N375hcZHY/uPZJQpydKVdolrmX0BbT5soL5dEZ3RAXlK4fzTCgyEK7
0c4IGbpqq/spzPztl7w64hN1sbbmM+mBKGmI7a/PfqFCotYKMlSpgQIDAQABo4IBrTCCAakwHwYD
VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny
bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc
MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUUEcYiStZfaVzV72TgQ+2OA00
1jQwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v
RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud
EQQ9MDuBGXJvYmVydC5nLmNvbGVAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMzY2NTYw
MzkwQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU
AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAUIuG9wQM+L5Nn5s06siK
fLFn1zTwubJzuQmWIKj0PeRhcXyEZtYdiR2p5YQWS7Z/g+WlsSCJGVjk4sK3UCYPQKV8xbEVh9Us
SGOUuIDKP7GAswgy8h9XAFDJfSPa9Vtzl8AgNLZiTUJfsn7N6uIOFiwWsHLr5MlvH+kbeNhY6wQ/
SuXyoR6IXAjAbm657Rb4lgdITn85Uuetk4kvsP08Vct/LfFPoJEHVHliov5zuvtAFzYPfu9bsmr0
CZ2LT8oljcncGG3/Nxt1XfYZJCCkxbav5Dq+t5eFcT69lYbcbliG3Us3ztCp7edfgBs9mzSbkPjC
tLPki80GqY4Uacrb5TCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ
MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow
XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww
CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ
s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4
zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY
zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf
VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G
A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU
uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG
A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC
AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs
oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB
AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U
Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC
hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul
M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl
cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3
i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW
LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y
U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz
SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5
eYelN5IWqYQgkmMxggL+MIIC+gIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv
dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg
Q0EtMjkCAzBBHTAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xMzA1MjQxMjU0NTRaMCMGCSqGSIb3DQEJBDEWBBRNyr2z2scgCDISB1OXFWXn
vaRDLzAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMHMAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFm
MGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E
MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDMEEgMHUGCyqGSIb3DQEJ
EAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL
EwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTI5AgMwQSAwDQYJKoZI
hvcNAQEBBQAEggEAkjJEodces7QtS+jCHh0qVKPrugioWVf0ogQW8EZmXoK3LPCyMAuhHNsWuvc2
ZzK7r/n3myffBrNKT67oQFUoCP6yAhXODqsyu3N46y3WQgoVzbg54KAsjb3kuhDY32r9ojntEetH
DtcCO+4TqMU+3UapU5aIfxegrYwmjCr8fG23U0NOxBBcrmf6sfo8qyZB+Ky7Q/XFZFHxcuHlTRj9
OfQgEtvUYVxstZO3VniL8F64VvW5oEVCo0k28/OLvsfdTmsvNxDQlbIFdiA9lRAVkKVjh0CJuthd
51dOcE0/JzhnBwWuTsmtNdDcRt9IYGOm8I65s2MeunDisYOuCFPKJQAAAAAAAA==

------=_NextPart_000_0012_01CE585C.5BFCC210--

From abdussalambaryun@gmail.com  Sat May 25 08:35:12 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F86721F8689 for ; Sat, 25 May 2013 08:35:12 -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 ykE8jPksFG0E for ; Sat, 25 May 2013 08:35:11 -0700 (PDT)
Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id D1D9321F8648 for ; Sat, 25 May 2013 08:35:11 -0700 (PDT)
Received: by mail-pb0-f50.google.com with SMTP id wy17so5289334pbc.9 for ; Sat, 25 May 2013 08:35:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=e1+KF30chsppNfRSo4PVd3V3BPyQsIv3Z/kgh3adk5g=; b=PR8Iwhp2PRrtRc7bKCHKDnb2I7bKXfI5D641/EdpACggWdOJH79crME7D4jr62QS/3 S0+RGfAO7mMyk+UZXSMq9OgtI7wdUF5z+SPk9GXUqZfQjSgWSyhaHHVaUNxBoGxYFGaR njvxD8mFT+sl3/okrWZoyLqYnfMAE84g3kS3G73fKGhEU2vEf6+6hruYSH9GYjoZbJUt uRnnODPA3oU3dmmjSjNqG+UyJBc941eCn8iw4QriM7isNV4Pj6Mq7JnPiZKhThELllNd vFXOHWxunXN/+W2aRef1cXt0dg0VBocdgvzp6YTbgpXwvbjgQ7Ls2dphloPTvhlqqTlT rvSA==
MIME-Version: 1.0
X-Received: by 10.66.158.234 with SMTP id wx10mr22800404pab.43.1369496111607;  Sat, 25 May 2013 08:35:11 -0700 (PDT)
Received: by 10.68.78.164 with HTTP; Sat, 25 May 2013 08:35:11 -0700 (PDT)
In-Reply-To: <04d601ce57f8$76ad0700$64071500$@olddog.co.uk>
References: <04d601ce57f8$76ad0700$64071500$@olddog.co.uk>
Date: Sat, 25 May 2013 17:35:11 +0200
Message-ID: 
From: Abdussalam Baryun 
To: manet 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [manet] AD review of draft-ietf-manet-nhdp-sec-threats
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 May 2013 15:35:12 -0000

On 5/23/13, Adrian Farrel  wrote:
>
> The assumption stated in the Introduction...
>    This document is based on the assumption that no additional security
>    mechanism (such as IPsec) is used in the IP layer.
> ...is perfectly fine. You might add a note to explain why this is a
> reasonable assumption (i.e., it is particularly hard to configure
> security associations in this type of network)

I mentioned similar concerns in my review at WGLC,

> and you might also add a
> note about whether none, some, or all of the threats would go away if
> this problem could be resolved.

This is why I was confused of using the word *common*, but IMO if
clarified as your above request and as in my comments before, then it
will make the I-D reasonable.

AB

From adrian@olddog.co.uk  Sat May 25 14:51:35 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CBE21F869F for ; Sat, 25 May 2013 14:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.354
X-Spam-Level: 
X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245,  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 K4QsYrkUNu76 for ; Sat, 25 May 2013 14:51:25 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id CBF0021F8D94 for ; Sat, 25 May 2013 14:51:24 -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 r4PLpLt3009708;  Sat, 25 May 2013 22:51:21 +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 r4PLpKGB009694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 25 May 2013 22:51:21 +0100
From: "Adrian Farrel" 
To: "'Abdussalam Baryun'" , "'manet'" 
References: <04d601ce57f8$76ad0700$64071500$@olddog.co.uk> 
In-Reply-To: 
Date: Sat, 25 May 2013 22:51:19 +0100
Message-ID: <083401ce5991$fdd72b30$f9858190$@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: AQJS+AHdkxDPInwkWXf3ZFPVoFEckQEmLAWFmAQByMA=
Content-Language: en-gb
Subject: Re: [manet] AD review of draft-ietf-manet-nhdp-sec-threats
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  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 May 2013 21:51:35 -0000

Abdussalam,

I am glad that I have captured your concern.
I am sure I didn't notice you raise these issues, but if fixing them helps
resolve your confusion it can only be a good thing.

Adrian

> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of
> Abdussalam Baryun
> Sent: 25 May 2013 16:35
> To: manet
> Subject: Re: [manet] AD review of draft-ietf-manet-nhdp-sec-threats
> 
> On 5/23/13, Adrian Farrel  wrote:
> >
> > The assumption stated in the Introduction...
> >    This document is based on the assumption that no additional security
> >    mechanism (such as IPsec) is used in the IP layer.
> > ...is perfectly fine. You might add a note to explain why this is a
> > reasonable assumption (i.e., it is particularly hard to configure
> > security associations in this type of network)
> 
> I mentioned similar concerns in my review at WGLC,
> 
> > and you might also add a
> > note about whether none, some, or all of the threats would go away if
> > this problem could be resolved.
> 
> This is why I was confused of using the word *common*, but IMO if
> clarified as your above request and as in my comments before, then it
> will make the I-D reasonable.
> 
> AB
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet


From internet-drafts@ietf.org  Sat May 25 14:54:03 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7673F21F8DFC; Sat, 25 May 2013 14:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.547
X-Spam-Level: 
X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, 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 9UllCgFNZcOv; Sat, 25 May 2013 14:54:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1A521F8E3C; Sat, 25 May 2013 14:54:02 -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: <20130525215402.10706.52634.idtracker@ietfa.amsl.com>
Date: Sat, 25 May 2013 14:54:02 -0700
Cc: manet@ietf.org
Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-09.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 May 2013 21:54:03 -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-09.txt
	Pages           : 83
	Date            : 2013-05-25

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-09

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


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


From abdussalambaryun@gmail.com  Sat May 25 22:11:09 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A4421F8FAF for ; Sat, 25 May 2013 22:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.203
X-Spam-Level: 
X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[AWL=0.396,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 5IsNoDvXLeRx for ; Sat, 25 May 2013 22:11:04 -0700 (PDT)
Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 256AD21F8FA5 for ; Sat, 25 May 2013 22:11:04 -0700 (PDT)
Received: by mail-pa0-f42.google.com with SMTP id bj1so473533pad.15 for ; Sat, 25 May 2013 22:11:03 -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=HZH3bbWWuN6mmkO6GVOZSeEzELHZ6EQ/AV7U8YofyIw=; b=yklFIINepDGOtlX6ii7IIP00SRGjPidjZPAVQiEIfLHaCwUbWxfJaQ9qsxUO1UCNrw u3Y2dtjsBjWTi/TyLunsjos8ts5rro3BldP/i4a70eUAu5Q30/rjGyR5fs1UuXv0gOYG tt7BRVzypZMlxDTdf1JHoZLgzuCW9ENkTMhs63fFNvH5XbfkE1Gg4fnMZ1OHQJUE6ZlK FMqoXo/OBk9hq7aXYsx71hpJaCZD0rkIIiZT9AkkGP/lDstU+BdQAfJXdpkFFKgA59bb xVIzsd/mdTdhE77ED0TVvy3+OS0ggJCGa+9k9ADTvrcMdnbLv+ZZuu+VQZmboppVXgZf gOhg==
MIME-Version: 1.0
X-Received: by 10.66.158.234 with SMTP id wx10mr24554320pab.43.1369545063749;  Sat, 25 May 2013 22:11:03 -0700 (PDT)
Received: by 10.68.78.164 with HTTP; Sat, 25 May 2013 22:11:03 -0700 (PDT)
In-Reply-To: <20130525215402.10706.52634.idtracker@ietfa.amsl.com>
References: <20130525215402.10706.52634.idtracker@ietfa.amsl.com>
Date: Sun, 26 May 2013 07:11:03 +0200
Message-ID: 
From: Abdussalam Baryun 
To: draft-ietf-manet-olsrv2-mib 
Content-Type: text/plain; charset=ISO-8859-1
Cc: manet@ietf.org
Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-09.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 May 2013 05:11:09 -0000

Please note that your changes or updates were not discussed in the WG
meetings or listings. I request a discuss or summary of discusses
results. I understand that this I-D is in IESG evaluation, but IMO
still WG can decide to comment on changes. I will make my comment on
the new changes within 2 weeks. If I should not comment please advise,

AB

On 5/25/13, internet-drafts@ietf.org  wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Mobile Ad-hoc Networks Working Group of
> the IETF.
>
> 	Title           : Definition of Managed Objects for the	 Optimized Link
> State Routing Protocol version 2
> 	Author(s)       : Ulrich Herberg
>                           Robert G. Cole
>                           Thomas Heide Clausen
> 	Filename        : draft-ietf-manet-olsrv2-mib-09.txt
> 	Pages           : 83
> 	Date            : 2013-05-25
>
> 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-09
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-mib-09
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

From ulrich@herberg.name  Sun May 26 00:05:27 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2B721F8F62 for ; Sun, 26 May 2013 00:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.557
X-Spam-Level: 
X-Spam-Status: No, score=-0.557 tagged_above=-999 required=5 tests=[AWL=-1.345, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, 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 1RnW6VNmSXbi for ; Sun, 26 May 2013 00:05:24 -0700 (PDT)
Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFD521F8F4D for ; Sun, 26 May 2013 00:05:23 -0700 (PDT)
Received: by mail-vb0-f48.google.com with SMTP id w8so3105097vbf.35 for ; Sun, 26 May 2013 00:05:23 -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=+ZZIR/rWprYwqCc6PaAnCLvvlhPmpdiN4LeCxVJvxt4=; b=sfR91k3qps6R7A4tlhatyJRwprQm21x+h4g12J8JqzzaMUqZwVOS6cu9l9J6UPt2sQ P/JDL/hZeSJuCOFPULQrBhx8LUDJI0ahR/CjXUtt/lR4nfW2NOE9uOJxen13hpYCFh7U BVZ0iUjf/dWWm4fI/tbcffVsvadUTCQA675lQ=
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=+ZZIR/rWprYwqCc6PaAnCLvvlhPmpdiN4LeCxVJvxt4=; b=kclRgRTrbjG/gowHqiPbv0VPzu9cpXgdv/MiMf9STaPjVyri60R88I1VaJbtGVPN2t gpZjtEP6dKwiEk3a8j7CIhXwH2YSUa7WucriyjrEg2WBt5FyX1jiRQbfuoCBnIPGk0zr 8TMlylkpxQyTVuZs6jl97GtuEJrp8GeC+VyqOUMTXBD8hA1U2oT1vW8fkut2peg1Nmv8 g4gmbiyw2gTihQPnj9wEMJicuLw+izVG/cWXYelj4RfbPhrcWcKoO+waxMGTYPAi/0vD SVBgzKiPUJvFNnkF6TV40wzU1PS+hu1mExMA/ZPLxcGspq3Im7gHmdxJlLI0jDtrI80w Bw7w==
MIME-Version: 1.0
X-Received: by 10.52.68.49 with SMTP id s17mr10607663vdt.92.1369551923392; Sun, 26 May 2013 00:05:23 -0700 (PDT)
Received: by 10.220.82.68 with HTTP; Sun, 26 May 2013 00:05:23 -0700 (PDT)
In-Reply-To: <51A13FF4.6080404@comcast.net>
References:  <51A13FF4.6080404@comcast.net>
Date: Sun, 26 May 2013 00:05:23 -0700
Message-ID: 
From: Ulrich Herberg 
To: manet@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmJ63a4cKMLDn6nH2sZcQMy5YNK2r4YjBCMRLYApC9JNhJkl9j1N3B3TnZCSTX83MpzKlIZ
Cc: Randy Presuhn 
Subject: [manet] Fwd: initial responses to: MIB doctor review of draft-ietf-manet-olsrv2-mib-08.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 May 2013 07:05:27 -0000

FYI: We submitted a new revision of the OLSRv2-MIB document,
addressing most comments from the Mib doctor review. We would like to
thank Randy Presuhn, who provided an extremely valuable and detailed
review.

Ulrich


---------- Forwarded message ----------
From: Cole 
Date: Sat, May 25, 2013 at 3:49 PM
Subject: initial responses to: MIB doctor review of
draft-ietf-manet-olsrv2-mib-08.txt
To: Randy Presuhn , adrian@olddog.co.uk,
Benoit Claise 
Cc: Ulrich Herberg , Thomas Clausen



Randy, Adrian, Benoit,

We have taken an initial pass at Randy's extensive review of the
draft-ietf-manet-olsrv2-mib-08 and have posted for your review a new
version draft-ietf-manet-olsrv2-mib-09.  That said we have a few todos
and questions for Randy.  Specifically,

We have addressed 52 of the 56 comments/questions.  We detail our
responses below.  But we have a few questions regarding the remaining:

+ RMP-012 -- we are in discussion on whether the 'olsrv2THoldTime'
object is indeed required to fit the constraints of the
exponent-mantissa notation in RFC 5497.  We will resolve this question
early this coming week.

+ RMP-033 -- regarding labels from the OLSRv2 specification referenced
in the MIB.  This list is extensive.  I'll take care of this by early
next week.  But I did not want this to hold us up in getting back to
you on the other issues.

+ RMP-036 -- regarding a TC for the OLSRv2 metric definitions.  I am
not sure exactly how to craft such a TC?  Any guidance would be
greatly appreciated.

+ RMP-056 -- regarding intelligent indexing.  Short answer is that the
WG did not go thru use cases.  We, the authors, did go back and forth
on several of the tables on the way to best index them, i.e., we had
several of the tables indexed via the (ipAddrType, ipAddr) index,
which I suspect gets to your question.  What specific Tables come to
mind that you would want us to reconsider the indexing?

Thanks,
Bob, Ulrich and Thomas.

--------------------------------------------------------
On Fri, May 17, 2013 at 10:58 PM, Randy Presuhn
 wrote:
>
> Hi -
>
> I was asked to review draft-ietf-manet-olsrv2-mib-08.txt
> as a MIB doctor.  There are several issues that clearly
> need to be addressed before this document is ready for
> publication.  There are numerous places where I think
> the clarity could be improved, particularly with potential
> implementors in mind.  I also have several questions about
> the intent of the design the document left unanswered.
> The answers to these might simply put my mind at rest or
> raise other issues regarding how this design would function.
>
> To simplify discussion of my comments, I'm organizing them
> by issue type rather than location in the document, since
> most issues show up in several places.
>
> I draw the Mib Doctors' attention to the following issues,
> where my opinion might be potentially controversial:
>     RMP-002, RMP-006, RMP-012, RMP-035
>
> Major Issues:
>
> Issue RMP-001
> Location: multiple objects referring to
> UNKNOWN_METRIC in their DESCRIPTION clauses
> Issue: UNKNOWN_METRIC isn't defined in this document, and
> draft-ietf-manet-olsrv2-19 section 6.1 explcitly
> avoids defining a specific external representation.
> That obviously won't do here, and a unique value
> that can be accommodated by the objects' syntax
> needs to be selected and documented.


See RMP-002


> Issue RMP-002
> Location: All "Metric" Objects, all Float32 usages
> Issue: All possible values that can be encoded using
> the metric representation defined in section 6.2
> of the OLSRv2 I-D, section 6.2 can be represented
> as exactly using Unsigned32 in SMI.  (The
> possible values are all integers in range 1..65280)
> Using Float32 is simply not necessary here.
> Suggestion: Define a textual convention for metrics, with
> and underlying syntax of Unsigned32, carving
> out a reserved value for "UNKNOWN_METRIC" (see
> issue RMP-001) and use that rather than Float32.
> Remove the IMPORTS and references rendered superfluous.


We have changed these to Unsigned32 and have assigned value=0 to UNKNOWN_METRIC.


>
> Issue RMP-003
> Location: 5.5.  Tables and Indexing
> Issue: The structure described in the text here does not
> match the actual structure defined in the MIB module.
> Suggestion: replace the discussion of "olsrv2LibOrigSetIpAddrType
> and olsrv2LibOrigSetIpAddr", which are *not* indexes,
> with discussion of olsrv2LibOrigSetIndex.
> Suggestion: replace the discussion of "olsrv2LibLocAttNetSetIpAddrType,
> olsrv2LibLocAttNetSetIpAddr and
> olsrv2LibLocAttNetSetIpAddrPrefixLen", which are *not*
> indexes, with discussion of olsrv2LibLocAttNetSetIndex.
> Suggestion:  replace the discussion of
> "olsrv2TibRouterTopologySetFromOrigIpAddrType and
>       olsrv2TibRouterTopologySetFromOrigIpAddr", which are
> *not* indexes, with discussion of
> olsrv2TibRouterTopologySetIndex.
> Suggestion: replace discussion of "olsrv2TibAttNetworksSetNetIpAddrType,
> olsrv2TibAttNetworksSetNetIpAddr and
>       olsrv2TibAttNetworksSetNetIpAddrPrefixLen", which are *not*
> indexes, with one about olsrv2TibAttNetworksSetIndex.



Fixed the indexing


>
>
> Minor Issues:
>
> Issue RMP-004
> Location: Section 5
> Issue: The text refers to several labels that don't exist
> in the MIB module.
> Suggestion: replace "olsrv2Objects" with  "olsrv2MIBObjects"
> Suggestion: replace "olsrv2Notifications" with "olsrv2MIBNotifications"
> Suggestion: replace "olsrv2Conformance" with "olsrv2MIBConformance"


Fixed


> Issue RMP-005
> Location: 5.5.  Tables and Indexing
> Issue: A label in the text doesn't match the (apparently) intended
> OBJECT-TYPE in the MIB module.  However, the label in the
> text follows the pattern of other labels in the module,
> while the label in the module deviates from the pattern
> of other labels.
> Suggestion: change the label "olsrv2TibRoutingSetDestIpAddrPrefLen"
> in the MIB module to match the
> "olsrv2TibRoutingSetDestIpAddrPrefixLen" label used
> in the text.


Good catch. Fixed.


>
> Issue RMP-006
> Location: all object types with SYNTAX InetAddressType
> Issue: All of these have DESCRIPTION text constraining the
> set of possible values.  If these constraints are
> indeed architectural constraints, and it is impossible
> for OLSRv2 to work with any other address types, this
> should be reflected in the syntax.  If it is envisioned
> that some future version of this module might support
> other types, then the place for the constraint is
> neither in the SYNTAX nor the DESCRIPTION, but in the
> conformance material.
> Suggestion: replace "SYNTAX InetAddressType" with
> "SYNTAX  InetAddressType { ipv4(1) , ipv6(2) }" in
> all cases.


Fixed.


>
> Issue RMP-007
> Location: all object types with SYNTAX TimeStamp
> Issue: All of these have UNITS clauses specifying "milliseconds".
> This cannot be, since TimeStamp is defined in terms
> of *centi*seconds.


Changed this for not only for TimeStamps
but - for consistency reasons - for the message intervals as well.


> Issue RMP-008
> Location: olsrv2RoutingSetRecalculationCountChange and
> olsrv2MPRSetRecalculationCountChange NOTIFICATION-TYPEs
> Issue: neither of these describes any mechanism for limiting
> the rate at which these notifications are generated
> Suggestion: add text to each to the effect that that notification
> can be generated at most once per window.


Yes, good point. We added text to these DESCRIPTIONS.



>
> Issue RMP-009
> Location: 8.  Security Considerations
> Issue: This MIB module AUGMENTS tables from another MIB module.
> Care must be taken in configuring access control to make
> sure that the permissions granted for the AUGMENT-ing tables
> are no more generous than those for the tabled being AUGMENT-ed.
> Otherwise, for example, not-accessible index information leaks.
> Suggestion: Identify these tables and recommend that access control
> policies be provisioned accordingly.


yes. We added a discussion of Table AUGMENTs.


>
> Issue RMP-010
> Location: 8.  Security Considerations
> Text: "olsrv2TibRouterTopologySetFromOrigIpAddr is the index into the"
> Issue: No, that's *not* the index into that table.
> Suggestion: refer to olsrv2TibRouterTopologySetIndex instead, or,
> better still, delete the last two sentences of the paragraph
> since they don't really add anything.


We deleted the two sentences.

>
> Issue RMP-011
> Location: olsrv2PreviousOrigIpAddrType  OBJECT-TYPE
> Issue: The address type needs to effectively be just
> as persistent as olsrv2PreviousOrigIpAddr.
> Suggest: add words to the effect:
> "This object MUST have the same persistance
> characteristics as olsrv2PreviousOrigIpAddr."


We added the suggested sentence.

>
> Issue RMP-012
> Location olsrv2THoldTime  OBJECT-TYPE
> olsrv2AHoldTime  OBJECT-TYPE
> Issue: Since this is required to be fit the constraints of the
> exponent-mantissa notation in RFC 5497, the syntax should
> at least constrain the range.  With "C" nailed down as
> 1/1024 second, rather than the 1/1000 second interval
> the object type is defined in terms of, the permitted
> values for this object are: 125, 250, 375, 500, 625, 750, 875,
> 1000, 1125, 1250, 1375, 1500, 1625, 1750, 1875, 2000, 2250,
> 2500, 2750, 3000, 3250, 3500, 3750, 4000, 4500, 5000, 5500,
> 6000, 6500, 7000, 7500, 8000, 9000, 10000, 11000, 12000, 13000,
> 14000, 15000, 16000, 18000, 20000, 22000, 24000, 26000, 28000,
> 30000, 32000, 36000, 40000, 44000, 48000, 52000, 56000, 60000,
>         and so on up to 3,932,160 (I think).  My concern is whether
> the operator of a management system will be able to guess/calculate
> these values on the fly, and whether they might be astonished
> to discover that this object can be set to 28, 30, 32, and 36
> seconds, but not 34.
> Suggestion: this seems to be a candidate for a textual convention,
> possibly punting on the upper reaches, but being explicit at least
> up to 60 seconds or so.


 TODO - pending further investigation.

>
> Editorial Issues:
>
> Issue RMP-013
> Location: all object types with SYNTAX InetAddressPrefixLength
> Suggestion: add 'UNITS "bits"' to each of these.


We agree. Fixed

>
> Issue RMP-014
> Issue: many object type definitions would benefit from UNITS clauses
> Location: olsrv2IfTcMessageXmits  OBJECT-TYPE
>   olsrv2IfTcMessageRecvd  OBJECT-TYPE
> Suggest: UNITS "messages"
> Location: olsrv2IfTcMessageXmitAccumulatedSize  OBJECT-TYPE
>   olsrv2IfTcMessageRecvdAccumulatedSize  OBJECT-TYPE
> Suggest: UNITS "octets"
> Location: olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount OBJECT-TYPE
> Suggest: UNITS "advertised selectors"
> Location: olsrv2RoutingSetRecalculationCount  OBJECT-TYPE
>           olsrv2MPRSetRecalculationCount  OBJECT-TYPE
>           olsrv2RoutingSetRecalculationCountThreshold OBJECT-TYPE
>           olsrv2MPRSetRecalculationCountThreshold OBJECT-TYPE
> Suggestion: UNITS "recalculations"
> Location: olsrv2IfTcMessageForwardedXmits  OBJECT-TYPE,
>       olsrv2IfTcMessagePeriodicXmits  OBJECT-TYPE, and
>       olsrv2IfTcMessageTriggeredXmits  OBJECT-TYPE
> Suggestion: UNITS "messages" (if that's what these count...)


Okay, changed.


> Issue RMP-015
> Location: 8.  Security Considerations
> Text: "This information can be use to expedite attacks"
> Issue: grammar
> Suggestion: replace "can be use to" with "can be used to"


Thanks, fixed!

>
> Issue RMP-016
> Location: 9.  Applicability Statement
> Text: "Some level of configuration, i.e., read-write
> objects, are desirable"
> Issue: verb/subject agreement
> Suggestion: replace "are" with "is"


Thanks, fixed.

>
> Issue RMP-017
> Location: 9.  Applicability Statement
> Text: "this MIB allows for"
> Issue: terminology
> Suggest: replace "MIB" with "MIB Module"


Fixed.

>
> Issue: RMP-018
> Location: multiple
> Issue: in most cases, it appears that "RECOMMENDED" is
> intended where "recommended" is used, and "SHOULD"
> where "should" appears in the text.
> Suggestion: Use "RECOMMENDED" and "SHOULD" where that is
> indeed intended.


For some of the cases, it is lower case (for the imported constraints
from OLSRv2, which itself sets to constraints, not the MIB document).
But there were several cases where indeed it should have been RFC2119.
We changed that.

>
> Issue: RMP-019
> Location: Abstract & Introduction - similar wording
> Text: "The OLSRv2-MIB module is structured into state information,
>    performance information, and notifications."
> Issue: Neglects configuration information and is not consistent
>    with section 5 and the MIB module itself.
> Suggestion: include "confiuration information" in the list.


Correct. Fixed.

>
> Issue: RMP-020
> Location: Abstract & Introduction - similar wording
> Text: "Different levels of compliance allow implementers to use
>    smaller subsets of all defined objects..."
> Issue: Only two levels are defined.
> Suggestion: Replace the sentence beginning with "Different" with:
>    "Two levels of compliance allow this MIB module to be
>    deployed on constrained routers." or something to that effect.


Agreed, fixed.

>
> Issue: RMP-021
> Location: 5.4.  The Notifications Group
> Text: "The Notifications Group contains Control, Objects and States, where
>    the Control contains definitions of objects to control the frequency
>    of notifications being sent.  The Objects define the supported
>    notifications and the State is used to define additional information
>    to be carried within the notifications."
> Issue: (a) This paragraph really belongs at the beginning, rather than
>    at the end, of 5.4.
>    (b) within the MIB modules these divisions are referred to as
>        olsrv2NotificationsObjects, olsrv2NotificationsControl,
>        and olsrv2NotificationsStates
> Suggestion:
>    (a) move this paragraph to the beginnin of 5.4
>    (b) Revise the first sentence to read something like:
>        "The Nofications Group contains Control (olsrv2NotificationsControl),
>        Objects (olsrv2NotificationsObjects), and States
>        (olsrv2NotificationsStates), where ...."


We made these changes to the DESCRIPTIONs.


>
> Issue RMP-022
> Location: 5.4.  The Notifications Group
> Text: "The Notifications sub-tree..."
> Issue: That's not quite where the information is in the MIB module.
> Suggestion: Replace with "The olsrv2NotificationsObjects sub-tree..."


Fixed.

>
>
> Issue: RMP-023
> Location: 5.5.  Tables and Indexing, similar wording appears
> several times within the MIB module's DESCRIPTION clauses
> Text: "a recently used originator address by this router"
> Issue: awkward English syntax
> Suggestion: replace with "an originator address this
> router has recently employed"
> Issue: it's not clear what is meant by "recently"...


We worked on the rewording, but not sure we caught all of your concerns?

>
> Issue RMP-024
> Location: 5.5.  Tables and Indexing
> Text: "is indexed via the set" (several times)
> Issue: the word "set" is unnecessary and is arguably incorrect,
> since the order of indices does matter
> Suggestion: delete "the set"


Fixed.

>
> Issue RMP-025
> Location: 5.5.  Tables and Indexing
> Text: INDEX { }, AUGMENTS { } (several times)
> Issue: no value added by quoting MIB Module syntax
> Suggestion: replace with "in indexed by ..." or "augments ..." or
>    similar English text, rather than using MIB Module syntax.


Fixed.

>
> Issue RMP-026
> Location: 5.5.  Tables and Indexing
> Text: "olsrv2InterfacePerfTable - records performance counters for each
>       active OLSRv2 interface on this device. selected path to each
>       destination for which any such path is known."
> Issue:  It looks like there's something missing here - in any case
>       the text beginning with "selected" is currently grammatically
>       a fragment rather than a complete sentence.
> Suggestion: fix it to make logical and grammatical sense - I don't
> know what was intended here.


That was a copy&paste error. Fixed now.


>
> Issue RMP-027
> Location: 5.5.  Tables and Indexing
> Text: "each Remote Router's IfAddr"
> Issue: "IfAddr" isn't defined.
> Suggestion: Unsure - it's not clear to me what's really intended
>   here.


Fixed.

>
> Issue RMP-028
> Location: 6.2.  Relationship to the NHDP-MIB
> Text: "In order access"
> Issue: missing word
> Suggestion: replace with "In order to access"


Fixed.


>
> Issue RMP-029
> Location: all NOTIFICATION-TYPE descriptions
> Issue: It's not quite correct to say "sent" - other MIBs control
> whether a notification ever shows up on the wire
> (e.g., SNMP-NOTIFICATION-MIB (RFC 3413)), and
> in some environments notifications may be locally logged
> Suggestion: say "generated" rather than "sent"
>

Fixed.

>
> Issue RMP-030
> Location: conformance material
> Issue: The language in these descriptions will potentially break
> if this module is ever updated to include additional
> objects or notifications.  The suggestions here are just
> examples of ways to say it while remaining future-proof.
> Location: olsrv2ConfigObjectsGroup OBJECT-GROUP
> Suggestion: "Objects to permit configuration of OLSRv2.
>           All of these SHOULD be backed by non-volatile storage."
> Location: olsrv2StateObjectsGroup OBJECT-GROUP
> Suggest: "Objects to permit monitoring of OLSRv2 state."
> Location: olsrv2PerfObjectsGroup  OBJECT-GROUP
> Suggest: "Objects to support monitoring of OLSRv2 performance ."
> Location: olsrv2NotificationsObjectsGroup OBJECT-GROUP
> Suggest: "Objects to support the notification types in the
> olsrv2NotificationsGroup.  Some of these appear in
>         notification payloads, others serve to control
> notification generation." or something more helpful.
> Location: olsrv2NotificationsGroup NOTIFICATION-GROUP
> Suggestion: "Notification types to support management of OLSRv2."
> or something more helpful.


Fixed.

>
> RMP-031
> Location: olsrv2RouterStatusChange NOTIFICATION-TYPE
>   olsrv2OrigIpAddrChange NOTIFICATION-TYPE
>   olsrv2RoutingSetRecalculationCountChange NOTIFICATION-TYPE
>   olsrv2MPRSetRecalculationCountChange NOTIFICATION-TYPE
> Issue: the term "originator" is used in the document in a special
> sense.  That's fine.  Where I get a little heartburn is
> where it is used in the phrase "originator of the
> notification".  That's uncomfortably close the the SNMP
> term "notification originator", which means something
> quite different.
> Suggestion: reword the passages that say things like "originator
> of the notification" to improve clarity and avoid confusion.


We made these changes.

>
> Issue RMP-032
> Location: multiple
> Issue: choice of base data types - this is a stylistic preference,
> especially for indexes.
> Suggestion: change Integer32 to Unsigned32


Changed for indexes

>
>
> Issue RMP-033
> Location: throughout the MIB module
> Issue: labels from the OLSRv2 specification are widely used
> in DESCRIPTIONS, without a key identifying the
> OBJECT-TYPEs to which they correspond.  Not sure
> what they refer to, I haven't investigated whether
> they are correct.
> Specific examples:
> Location: olsrv2IibLinkSetEntry  OBJECT-TYPE
> Text: (L_in_metric, L_out_metric, L_mpr_selector)"
> Location: olsrv2IibLinkSetInMetric  OBJECT-TYPE
> Text: L_neighbor_iface_addr_list
> Location: olsrv2IibLinkSetOutMetric  OBJECT-TYPE
> Text: L_neighbor_iface_addr_list
> Location: olsrv2Iib2HopSetEntry  OBJECT-TYPE
> Text: (N2_in_metric, N2_out_metric)"
> Location: olsrv2Iib2HopSetInMetric  OBJECT-TYPE
> Text: N2_2hop_iface_addr, N2_neighbor_iface_addr_list.
> Location: olsrv2Iib2HopSetOutMetric  OBJECT-TYPE
> Text: N2_2hop_iface_addr, N2_neighbor_iface_addr_list.
> Location: olsrv2LibOrigSetEntry  OBJECT-TYPE
> Text: (O_orig_addr, O_time)"
> Location: olsrv2LibLocAttNetSetEntry  OBJECT-TYPE
> Text: (AL_net_addr, AL_dist, AL_metric)
> Location: olsrv2LibLocAttNetSetMetric  OBJECT-TYPE
> Text: AL_net_addr
> Location: olsrv2NibNeighborSetEntry  OBJECT-TYPE
> Text: N_orig_addr N_in_metric N_out_metric N_will_flooding N_will_routing
> N_flooding_mpr N_routing_mpr N_mpr_selector N_advertised
> Location: olsrv2NibNeighborSetNAdvertised  OBJECT-TYPE
> Text: N_mpr_selector
> Location: olsrv2TibAdRemoteRouterSetEntry  OBJECT-TYPE
> Text: (AR_orig_addr, AR_seq_number, AR_time)
> Location: olsrv2TibRouterTopologySetEntry  OBJECT-TYPE
> Text: " (TR_from_orig_addr, TR_to_orig_addr,
>     TR_seq_number, TR_metric, TR_time)"
> Location: olsrv2TibRouterTopologySetFromOrigIpAddr  OBJECT-TYPE
> Text: TR_to_orig_addr
> Location: olsrv2TibRouterTopologySetToOrigIpAddr  OBJECT-TYPE
> Text: TR_to_orig_addr
> Location: olsrv2TibRouterTopologySetSeqNo  OBJECT-TYPE
> Text: TR_from_orig_addr
> Location: olsrv2TibRouterTopologySetMetric  OBJECT-TYPE
> Text: TR_from_orig_addr TR_to_orig_addr."
> Location: olsrv2TibRoutableAddressTopologySetEntry  OBJECT-TYPE
> Text: (TA_from_orig_addr, TA_dest_addr,
>     TA_seq_number, TA_metric, TA_time)"
> Location: olsrv2TibRoutableAddressTopologySetFromOrigIpAddr  OBJECT-TYPE
> Text: TA_dest_addr
> Location: olsrv2TibRoutableAddressTopologySetDestIpAddr  OBJECT-TYPE
> Text: TA_from_orig_addr
> Location: olsrv2TibRoutableAddressTopologySetSeqNo  OBJECT-TYPE
> Text: TA_from_orig_addr
> Location: olsrv2TibRoutableAddressTopologySetMetric  OBJECT-TYPE
> Text: TA_from_orig_addr
> Location: olsrv2TibAttNetworksSetEntry  OBJECT-TYPE
> Text: (AN_orig_addr, AN_net_addr, AN_seq_number,
>     AN_dist, AN_metric, AN_time)"
> Location: olsrv2TibAttNetworksSetOrigIpAddr  OBJECT-TYPE
> Text: AN_net_addr."
> Location: olsrv2TibAttNetworksSetNetIpAddr  OBJECT-TYPE
> Text: AN_orig_addr."
> Location: olsrv2TibAttNetworksSetSeqNo  OBJECT-TYPE
> Text: AN_orig_addr"
> Location: olsrv2TibAttNetworksSetDist  OBJECT-TYPE
> Text: AN_net_addr AN_orig_addr."
> Location: olsrv2TibAttNetworksSetMetric  OBJECT-TYPE
> Text: AN_orig_addr AN_net_addr."
> Suggestion: assuming these are useful links into the OLSRv2
> specification, I suggest accompanying each one with
> the label of the corresponding object-type from
> the mib module.


TODO - working this one.

>
> Issue RMP-034
> Issue: obvious typographical errors in DESCRIPTIONs
> Location: olsrv2MPRSetRecalculationCountThreshold OBJECT-TYPE
> Suggestion: replace "olsrv2MPRSetReculculationCountWindow"
>     with    "olsrv2MPRSetRecalculationCountWindow"
> Location: olsrv2Iib2HopSetOutMetric  OBJECT-TYPE
> Suggestion replace "olsrv2Iib2HopSetN2Time" with
>    "olsrv2Iib2HopSetOutMetric"
> Location: olsrv2IibLinkSetOutMetric  OBJECT-TYPE
> Suggestion: replace "olsrv2IibLinkSetInMetric"
>     with    "olsrv2IibLinkSetOutMetric"
> Location: olsrv2TibRoutingSetNextIfIpAddrType  OBJECT-TYPE
> Text:     "The type of the olsrv2TibRoutingSetNextIfIpAddr
>                   and olsrv2TibRoutingSetNextIfIpAddr,"
> Suggestion: delete "and olsrv2TibRoutingSetNextIfIpAddr,"


Fixed.

>
>
> Issue RMP-035
> Location: olsrv2NibNeighborSetNWillFlooding  OBJECT-TYPE
> Location: olsrv2NibNeighborSetNWillRouting  OBJECT-TYPE
> Location: olsrv2WillFlooding     OBJECT-TYPE
> Location: olsrv2WillRouting  OBJECT-TYPE
> Issue: these all have the same syntax, and seem a good
> candidate for a textual convention, particularly
> if there's a desire to have willNever, willAlways,
> or willDefault available to tools.
> Suggestion: create a textual convention with the appropriate
> values and semantics


Agreed. Added a WillingnessTC.  Please check this out?

>
>
> Issue RMP-036
> Location: olsrv2LinkMetricType  OBJECT-TYPE
> Issue: With the allocation of metric types under IANA control,
> it may make sense to define a textual convention (spun
> off into an IANA-maintained MIB module) to support
> metric type selection.


Agreed.  Looking for some help/suggested wording for such a TC?

>
> Issue RMP-037
> Location: 7.  Definitions
> Text:
>     -- This MIB module defines objects for the management of
>     -- RFC XXXX - The Optimized Link State Routing Protocol
>     -- version 2, Clausen, T., Dearlove, C., Jacquet, P.
>     -- and U. Herberg, March 2013.
> Issue: this information is redundant with what is already in
>    the MODULE-IDENTITY's DESCRIPTION clause
> Suggestion: delete these comments


Okay, done.

> Location: page 65
> Text: -- olsrv2NotificationStates
> Issue: this comment isn't helpful at all.
> Suggestion: delete it


deleted

>
> Issue RMP-038
> Location: Olsrv2Status ::= TEXTUAL-CONVENTION
> Issue: the description of this textual convention says
>    it's an "indication of the operability", but the
>    actual use is to configure / control.
> Suggestion: reword the description to make the administrative
> control aspect explicit, e.g.:
>        "Controls the operation of the OLSRv2
>         protocol on the device or a specific interface.
>         For example, for an interface: 'enabled' indicates
>         that OLSRv2 is permitted to operate,
>         and 'disabled' indicates that it is not."


Fixed.

>
> Issue RMP-039
> Location: olsrv2InterfaceTable  OBJECT-TYPE
> Text: "are explicitly defined by network manager servers"
> Issue: terminology
> Suggestion: replace "manager servers" with "managers" or
> "management"


Fixed.

>
> Issue RMP-040
> Location: olsrv2InterfaceTable  OBJECT-TYPE
> Text: "contains a single boolean object, the"
> Issue: the object is not a boolean.  If it were, the correct type
> would be TruthValue (RFC 4181 clause 4.6.1.9)
> Suggestion: delete "boolean"


Fixed.


>
> Issue RMP-041
> Location: olsrv2InterfaceAdminStatus OBJECT-TYPE
> Text: "is running the OLSRv2 routing process.
>        The value 'disabled' denotes that the interface is
>        external to the OLSRv2 routing process."
> Issue: "running" "external" and "process" strongly
>    suggest a particular implementation strategy
> Suggest: "is permitted to participate in the OLSRv2 protocol.
>        The value 'disabled' denotes that the interface is
>        not permitted to participate in the OLSRv2 protocol."


Agreed.  We updated (hopefully improved) the DESCRIPTIONs on both the
olsrv2InterfaceAdminStatus and the olsrv2Admin Status to address these issues.

>
> Issue RMP-042
> Location: olsrv2NibNeighborSetNOrigIpAddr  OBJECT-TYPE
> Text: "This is the originator IP address of that neighbor."
> Issue: What neighbor?
> Sugestion: clarify


Changed to "This is the originator IP address of the neighbor
          represented by this table entry."

>
> Issue RMP-043
> Location: olsrv2IibLinkSetMprSelector  OBJECT-TYPE
> Location: olsrv2NibNeighborSetNFloodingMpr  OBJECT-TYPE
> Location: olsrv2NibNeighborSetNRoutingMpr  OBJECT-TYPE
> Location: olsrv2NibNeighborSetNMprSelector  OBJECT-TYPE
> Text: "describing if this neighbor"
> Issue: stylistic preference
> Suggestion: replace "describing if" with "recording whether"


Fixed.

>
> Issue RMP-044
> Location: olsrv2TibAdRemoteRouterSetMaxSeqNo  OBJECT-TYPE
> Location: olsrv2TibRouterTopologySetSeqNo  OBJECT-TYPE
> Location: olsrv2TibRoutableAddressTopologySetSeqNo  OBJECT-TYPE
> Text: "the greatest ANSN in any TC message"
> Suggest: explain what "greatest" means under wrap conditions,
> or otherwise re-word for correctness


Added text to clarify.  Pulled description from olsrv2 draft.

>
>
> Issue RMP-045
> Location: olsrv2TibAdRemoteRouterSetRouterId  OBJECT-TYPE
> text: "This object is an additional index for each
>    Remote Router's IfAddr associated with the
>    olsrv2TibAdRemoteRouterSetIpAddr."
> Issue: "additional" makes no sense, as this is the sole index
> Suggestion: delete "additional"


Fixed

>
> Issue RMP-046
> Location: olsrv2TibAttNetworksSetOrigIpAddr  OBJECT-TYPE
> Text: network with address AN_net_addr."
> Location: olsrv2TibAttNetworksSetNetIpAddr  OBJECT-TYPE
> Text: the router with originator address AN_orig_addr."
> Issue: addresses need a type, too.


Fixed (we think).  Added text to the effect of 'router with
AN_orig_addr of type ....'.


>
> Issue RMP-047
> Location: olsrv2TibRoutingSetDestIpAddrType  OBJECT-TYPE
> Text: "The type of the olsrv2TibRoutingSetDestIpAddr
>    and olsrv2TibRoutingSetNextIfIpAddr,"
> Issue: Another object defines the type for the latter.
> Suggestion: delete "and olsrv2TibRoutingSetNextIfIpAddr"


Fixed.

>
> Issue RMP-048
> Location: olsrv2RoutingSetRecalculationCountChange NOTIFICATION-TYPE
> Suggest: Delete "The new count of the routing set recalculations"
> since the explanation is just confusing.
> Issue: the description could be more precise
> Suggest: Replace with something like:
>           "The olsrv2RoutingSetRecalculationCountChange
>            notification is generated when a significant number of
>            routing set recalculations have occurred in a short time.
>            The network administrator should select
>            appropriate values for 'significant number of
>            routing set recalculations' and 'short time' through the settings
>            of the olsrv2RoutingSetRecalculationCountThreshold
>            and olsrv2RoutingSetRecalculationCountWindow
>            objects."


Fixed.


>
> Location: olsrv2MPRSetRecalculationCountChange NOTIFICATION-TYPE
> Suggest: Delete "The new MPR set recalculation count", since
> the explanation is just confusing.
> Issue: the description could be more precise
> Suggest: Replace with:
>           "The olsrv2MPRSetRecalculationCountChange
>            notification is generated when a significant
>    number of MPR set recalculations occur in
>    a short period of time.
>            The network administrator should select
>            appropriate values for 'significant number of
>            MPR set recalculations' and 'short period of
>    time' through the settings
>            of the olsrv2MPRSetRecalculationCountThreshold
>            and olsrv2MPRSetRecalculationCountWindow
>            objects."


Fixed.

>
> Location:    olsrv2RoutingSetRecalculationCountWindow OBJECT-TYPE
> Issue: clarity
> Suggestion: I *think* this is what is intended in the first
> part of the DESCRIPTION:
> "This object is used to determine whether to generate
> an olsrv2RoutingSetRecalculationCountChange notification.
>
> This object represents an interval from the present moment,
> extending into the past, expressed in hundredths of
> a second.  If the change in the value of the
>         olsrv2RoutingSetRecalculationCount object during
> this interval has exceeded the value of
>         olsrv2RoutingSetRecalculationCountThreshold, then the
> an olsrv2RoutingSetRecalculationCountChange notification
> is generated."


Fixed.

>
> Location: olsrv2MPRSetRecalculationCountWindow OBJECT-TYPE
> Text: "A time window for the
>            olsrv2MPRSetRecalculationCount object.
>            If the number of occurrences exceeds the
>            olsrv2MPRSetRecalculationCountThreshold
>            within the previous
>            olsrv2MPRSetRecalculationCountWindow,
>            then the
>            olsrv2MPRSetRecalculationCountChange
>            notification is to be sent.
>            This object represents the timei interval in hundredths
>            of a second."
> Issue: clarity
> Suggestion: I *think* this is what is intended in that part of the
> DESCRIPTION:
> "This object is used to determine whether to generate
> an olsrv2MPRSetRecalculationCountChange notification.
>
> This object represents an interval from the present moment,
> extending into the past, expressed in hundredths of
> a second.  If the change in the value of the
>         olsrv2MPRSetRecalculationCount object during
> that interval has exceeded the value of
>         olsrv2MPRSetRecalculationCountThreshold, then the
> an olsrv2MPRSetRecalculationCountChange notification
> is generated."


Fixed.


>
>
> Questions / Clarifications:
>
> Issue RMP-049
> Location: 4.  Overview
> Text: This document provides management and control capabilities of an
>    OLSRv2 instance..."
> Issue: The design of this module permits only a *single* OLSRv2 instance
>    to be managed in a given SNMP context. (But doesn't preclude using
>    SNMP contexts to provide access to different instances running
>    on a given system.  This would be needed, for example, if a single
>    box provided services to two or more non-connected (by adminstrative
>    policy, for example) ad hoc networks.)
> Suggestion:  I'm not advocating any particular direction here,
>    just alerting you to the fact that this design effectively
>    makes a decision here, and hope this was a *conscious* decision.


After some discussion between the authors of the MIB and the protocol,
we are content with leaving this description as is.


>
> Issue RMP-050
> Location: 6.2.  Relationship to the NHDP-MIB
> Text: "locally significant but should be locally common"
> Issue: Is normative "should" intended here, or is this merely
>    implementation advice?  I think the normative requirement is
>    merely that the set of values and the semantics of each
>    individual value be identical for the two MIB modules
>    within a given SNMP context.  Anything beyond that is
>    implementation detail, and would properly be out of scope.
> Suggestion: remove the ambiguity.


Fixed.

>
> Issue RMP-051
> Location: olsrv2InterfaceTable  OBJECT-TYPE
> Text:      A conceptual row in this table exists if and only
>            if either a manager has explicitly created the row
>            in the nhdpInterfaceTable
>            or there is an interface on the managed device
>            that supports and runs NHDP.
> Issue: Is the intent here to preclude provisioning by NETCONF,
>    CLI, or other means?  If not, the language needs softening.


Fixed.  We modified the text here (and elsewhere in the MIB).  The
intent is not to preclude other management interfaces such as CLI
(now) or NETCONF (down the road).

>
> Issue RMP-052
> Location: DESCRIPTION and SYNTAX of integer index objects, e.g.:
>   olsrv2LibOrigSetIndex  OBJECT-TYPE
>   olsrv2LibLocAttNetSetIndex  OBJECT-TYPE
>   olsrv2TibAdRemoteRouterSetRouterId  OBJECT-TYPE
>   olsrv2TibRouterTopologySetIndex  OBJECT-TYPE
>   olsrv2TibRoutableAddressTopologySetIndex  OBJECT-TYPE
>   olsrv2TibAttNetworksSetIndex  OBJECT-TYPE
> Issue: these index definitions raise more questions than they answer
> Suggestion: (a) Provide motivation for constraints on index ranges
>        (b) describe how index values for new entrys are allocated
>        (c) describe conditions for re-use of previously-used values


Fixed this by added text to the DESCRIPTION addressing your concerns.
However, these may change depending upon the resolution to RMP-056.

>
> Issue RMP-053
> Location: DESCRIPTION of various entry object types, e.g.:
> olsrv2LibLocAttNetSetEntry  OBJECT-TYPE
> olsrv2NibNeighborSetEntry  OBJECT-TYPE
> olsrv2TibAdRemoteRouterSetEntry  OBJECT-TYPE
> olsrv2TibRouterTopologySetEntry  OBJECT-TYPE
> olsrv2TibRoutableAddressTopologySetEntry  OBJECT-TYPE
> Issue: it is helpful to the implementor of both instrumentation
> and management applications to know the expected lifecycle
> of table entries - when they are created, when they can
> disappear, and the conditions for index re-use.  It would
> also be helpful to have a little more explanation of
> what does and doesn't happen as a consequence of
> interface enable/disable.
> Suggestion: outline the lifecycle of table entries for each
> non-AUGMENTS table in the MIB module


We added to the DESCRIPTION regarding this.  But primarily we point
the developers to
specific Sections within the olsrv2 draft which holds extensive
discussions of the management of these tables.

>
> Issue RMP-054
> Location: olsrv2AdminStatus  OBJECT-TYPE
> Text: "Hence, this
>        object cannot have a status of 'enabled'
>        unless at least one interface an the device
>        is a MANET interface with NHDP enabled on that
>        interface.  If all device interfaces running
>        NHDP become disabled or removed, then the
>        olsrv2AdminStatus MUST be set to 'disabled'.
>
>        If the network manager sets this object to
>        'disabled', then the associated interface specific
>        objects, i.e., the olsrv2InterfaceAdminStatus
>        objects must all be set to 'disabled'."
> Issues: (1) Is the intent that a request to set this to 'enabled'
> would (in the absence of NHDP) fail with
> inconsistentValue? (if not...?)
> (2) what entity does the set referred to in the
>         "MUST be set to 'disabled'? (if it's not the managed device...)
> (3) is the intent that olsrv2InterfaceAdminStatus objects
>         take on a value of 'disabled' as an automatic side-effect
> of olsrv2AdminStatus becoming 'disabled', or does this
> side-effect only happen olsrv2AdminStatus has been set to
> 'disabled' by an SNMP setRequest, or does the "must" mean
> that the manager is required to explicitly issue setRequests
> for all those olsrv2InterfaceAdminStatus Objects?
> (4) The DESCRIPTION of olsrv2InterfaceAdminStatus gives
> additional meaning to 'disabled'.  When, after having been
> disabled, olsrv2AdminStatus is subsequently set to 'enabled',
> is explicit management action required to re-enable the
> various instances of olsrv2InterfaceAdminStatus?


Clarified the appropriate behavior in the descriptions of the
AdminStatus object and the InterfaceAdminStatusTable.


>
>
> Issue RMP-055
> Location: olsrv2IfTcMessageRecvd  OBJECT-TYPE
> Issue: does this include messages that are ignored
>    due to OSLRv2 protocol procedures?
> Location: olsrv2IfTcMessageRecvdAccumulatedSize  OBJECT-TYPE
> Issue: Should specify whether this includes payloads excluded
> due to syntax errors or ignored due the protocols
> other procedures.


Clarified the descriptions.  Excluding messages discarded due to
errors or protocol procedures for both of these.


>
> Issue RMP-056
> Issue: In some cases the indexing structure does not appear to provide
> any support for intelligent retrieval of table contents.
> Did the working group go through the use cases they
> intended these tables to support to determine whether
> the indexing structure made sense?


Pending your response?

From abdussalambaryun@gmail.com  Mon May 27 07:05:08 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A8A21F91B1 for ; Mon, 27 May 2013 07:05:08 -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 K7dH-vrSLHcM for ; Mon, 27 May 2013 07:05:08 -0700 (PDT)
Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 38A4521F911B for ; Mon, 27 May 2013 07:05:08 -0700 (PDT)
Received: by mail-pb0-f52.google.com with SMTP id um15so6825182pbc.11 for ; Mon, 27 May 2013 07:05:08 -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=aB7GSGA+5DxwnlZLheHc9Kf7fzn1ikUFeLBb1Ce5QgM=; b=d+deY0FFHG2MVi2b5OwrLXOlnSVLDeCdkdeCmeH3E8ImHcf8W+S4XoHS/YISvM8rHs 7vax7amL+zR2DbSVcGJ8Y6by6z1zInT0p/fe9PHf+mMRI9SQ99r6KqRMCSPzK8omcgG7 tl67pId9GvWF4xsm5sM+kVXbVuUMT+mj9Bl/5Ng2uYgC/9UUqBWsLwyfUaFginyOOW7F MzI7IAB4LYCb5RMKr1J68Wfmk/hwr9A7RytiX/921cqWw1jvzfsK8+VwhkiaedYC8l2F k7HluGAYdUsN3mdKGP17LC5vczgP3giLYJyiYB+DmECGWnhJIyrDciAr+5GffPJBwkGo 5iUg==
MIME-Version: 1.0
X-Received: by 10.68.12.98 with SMTP id x2mr29863984pbb.92.1369663507948; Mon, 27 May 2013 07:05:07 -0700 (PDT)
Received: by 10.68.78.164 with HTTP; Mon, 27 May 2013 07:05:07 -0700 (PDT)
In-Reply-To: <82825615-FED9-46C9-B5B4-AC2D9A8CD76D@jiaziyi.com>
References:  <82825615-FED9-46C9-B5B4-AC2D9A8CD76D@jiaziyi.com>
Date: Mon, 27 May 2013 16:05:07 +0200
Message-ID: 
From: Abdussalam Baryun 
To: Jiazi Yi 
Content-Type: text/plain; charset=ISO-8859-1
Cc: manet List 
Subject: Re: [manet] AB#2 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 May 2013 14:05:09 -0000

On 4/9/13, Jiazi Yi  wrote:
> Hi,
>
> On Apr 9, 2013, at 5:47 AM, Abdussalam Baryun
>> AB> Does attacks on IP layer increase threats to NHDP? Not understood from
>> I-D.
>> AB> Does attacks on MAC, L2 or L2.5 increase threats to L3-NHDP?
>> Does/Can NHDP possible depend on the lower layers, if yes, what are
>> the threats? Please note that these issues mentioned in RFC6130 but
>> not in this I-D.
>> ----------------------
>
> We don't even know what L2 L2.5 will be used with NHDP, so it's impossible
> to have further discussions on it.

Please read the AD review, regarding IP.
http://www.ietf.org/mail-archive/web/manet/current/msg15423.html

>
>>
>> [The use of NHDP]
>>
>> AB> If there is an attack on NHDP does that mostly mean that its users
>> are attacked as well?
>
> The consequence of the attacks has been introduced in the ID.
>
>> AB> In AODVv2 mentions that NHDP used to monitor and assure
>> bi-directional links, does that use have threats, why not mentioned,
>> please do.
>
> No. AODVv2 has no normative reference to NHDP.

Please read the AD review, regarding new work,
http://www.ietf.org/mail-archive/web/manet/current/msg15423.html

AB

From adrian@olddog.co.uk  Mon May 27 07:27:37 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC4121F91C4 for ; Mon, 27 May 2013 07:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.991
X-Spam-Level: 
X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=0.990,  BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619]
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 1C5A28XJBRKI for ; Mon, 27 May 2013 07:27:32 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 56E0921F920B for ; Mon, 27 May 2013 07:27:32 -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 r4RERT7h031521;  Mon, 27 May 2013 15:27:29 +0100
Received: from 950129200 ([220.109.211.58]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4REROAt031434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 May 2013 15:27:26 +0100
From: "Adrian Farrel" 
To: "'Abdussalam Baryun'" , "'Jiazi Yi'" 
Date: Mon, 27 May 2013 15:27:19 +0100
Message-ID: <005b01ce5ae6$50677b20$f1367160$@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: Ac5a5dTEcil5QNTaQ9ONacVIUvFAbA==
Content-Language: en-gb
Cc: 'manet List' 
Subject: Re: [manet] AB#2 Comments for WGLC draft-ietf-manet-nhdp-sec-threats-02
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  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 May 2013 14:27:37 -0000

In line.
Adrian

> > On Apr 9, 2013, at 5:47 AM, Abdussalam Baryun
> >> AB> Does attacks on IP layer increase threats to NHDP? Not understood from
> >> I-D.
> >> AB> Does attacks on MAC, L2 or L2.5 increase threats to L3-NHDP?
> >> Does/Can NHDP possible depend on the lower layers, if yes, what are
> >> the threats? Please note that these issues mentioned in RFC6130 but
> >> not in this I-D.
> >> ----------------------
> >
> > We don't even know what L2 L2.5 will be used with NHDP, so it's impossible
> > to have further discussions on it.
> 
> Please read the AD review, regarding IP.
> http://www.ietf.org/mail-archive/web/manet/current/msg15423.html

I don't see anything in my review that relates to this issue.
I said...

| The assumption stated in the Introduction...
|    This document is based on the assumption that no additional security
|    mechanism (such as IPsec) is used in the IP layer.
| ...is perfectly fine. You might add a note to explain why this is a 
| reasonable assumption (i.e., it is particularly hard to configure
| security associations in this type of network) and you might also add a
| note about whether none, some, or all of the threats would go away if
| this problem could be resolved.

...and I can't even begin to associate the two comments.


> >> [The use of NHDP]
> >>
> >> AB> If there is an attack on NHDP does that mostly mean that its users
> >> are attacked as well?
> >
> > The consequence of the attacks has been introduced in the ID.
> >
> >> AB> In AODVv2 mentions that NHDP used to monitor and assure
> >> bi-directional links, does that use have threats, why not mentioned,
> >> please do.
> >
> > No. AODVv2 has no normative reference to NHDP.
> 
> Please read the AD review, regarding new work,
> http://www.ietf.org/mail-archive/web/manet/current/msg15423.html

My review does not say and should not be interpreted as saying that the authors
need to look at the implications of NHDP security on AODVv2 or, indeed, on any
other protocol that does have a normative dependency on NHDP.

I wrote:

| 2. Please consider adding a short section that may drive new work by
|   suggesting which threats need to be addressed in new protocol work,
|   which in deployment, and which by applications.

This paragraph applies solely and entirely to NHDP.

For the avoidance of doubt, it may be read as:

2. Please consider adding a short section that may drive new NHDP
   work by suggesting which threats identified in this document need
   to be addressed in extensions or modifications to NHDP, which in
   deployment of NHDP, and which by applications that use NHDP.

For the further avoidance of confusion, I would not expect this document to
attempt to address the security concerns of other protocols (i.e. applications
that use NHDP). I would expect protocol specifications to identify and describe
their own security concerns so that, for example, the AODVv2 spec might
highlight the risks of false adjacencies that might arise from attacks on NHDP:
it would then refer to this document for a description of how that might happen;
to the NHDP spec and any protocol extension documents for a description of how
NHDP might be secured; and might go on to define its own security mechanisms (in
the application protocol) to protect the application protocol.

Adrian


From valerio.arnaboldi@iit.cnr.it  Wed May 29 03:16:24 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6289921F86D8 for ; Wed, 29 May 2013 03:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[AWL=-0.391,  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 akdYHQGM-KwL for ; Wed, 29 May 2013 03:16:02 -0700 (PDT)
Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) by ietfa.amsl.com (Postfix) with ESMTP id 96C8421F8CA0 for ; Wed, 29 May 2013 03:16:01 -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 1ED2DC0738 for ; Wed, 29 May 2013 12:16:00 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Valerio Arnaboldi
To: manet@ietf.org
Message-Id: <20130529101601.96C8421F8CA0@ietfa.amsl.com>
Date: Wed, 29 May 2013 03:16:01 -0700 (PDT)
Subject: [manet] Call for work-in-progress (WIP) papers - SustainIT 2013 (deadline June 20)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 May 2013 10:16:25 -0000

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

                  CALL FOR WORK-IN-PROGRESS (WIP) 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

------------------------------------------------------------------------
           **** WIP Paper Submission Deadline --- JUNE 20, 2013 ****    
------------------------------------------------------------------------

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

SustainIT 2012 invites Work in Progress (WIP) papers showing innovative and original research in the areas of Sustainable Internet and ICT for Sustainability. Submissions from both industry and academia are strongly encouraged. WIP papers are expected to report on early and emerging results and bring about novel research questions, approaches, and directions. The specific aim of the WiP session is to provide a forum for timely presentation, discussion and feedback for novel, controversial, and thought provoking ideas. All selected papers will be presented as posters in a special conference session. In addition, all selected papers will be included in the conference proceedings.

For this special session we solicit original papers addressing both theoretical and practical aspects of energy-awareness for Internet-based systems, and the design of ICT solutions for eco-sustainability. Topics of interest include but are not limited to:

- Green Internet
- Power-aware Internet applications
- Energy-efficient network architecture and protocols 
- Green wireless networking
- Energy-efficient network technologies
- Cross-layer optimization for green networking
- Standards and metrics for green communications
- Energy-efficient management of network resources 
- Energy efficiency in data centres 
- Energy efficiency, Quality of Service, and reliability
- Algorithms for reduced power, energy and heat
- Data processing in smart energy systems
- ICT for energy efficiency in smart homes and buildings
- ICT for sustainable smart cities 
- ICT for sustainable transports and logistics
- ICT for green mobility
- ICT for energy efficiency in industrial environments
- ICT for smart grids
- Security and privacy in ICT for energy systems
- Sustainability achievements due to ICT-based optimization 
- Energy consumption measurements, models, and monitoring tools
- Measurement and evaluation of the Internet sustainability
- Test-bed and prototype implementations


PAPER SUBMISSION
------------------------------------------------------------------------

All submissions must describe original research, not published or currently under review for another workshop, conference, or journal. WIP papers are expected to present early or ongoing research activities. Novel approaches and preliminary results are especially appreciated.

Papers must be submitted electronically in PDF format through EDAS. Manuscripts must be formatted in accordance with the IEEE Computer Society author guidelines (http://edas.info/newPaper.php?c=14317). Manuscripts must be limited to 5 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). 

Submission implies the willingness of, at least, one author to register and attend the conference to present the paper. The organizers reserve the right to exclude a paper from distribution after the conference if the paper is not presented at the conference.


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

- Paper submission deadline:            June 20, 2013
- Acceptance notification:         	  July 15, 2013
- Camera-ready version due:             July 30, 2013


FOR MORE INFORMATION
------------------------------------------------------------------------

For questions about the demonstration submission and review  process, please contact 

Raffaele Bruno, IIT-CNR, Italy - raffaele (dot) bruno (at) iit (dot) cnr (dot) it




From jpmacker@gmail.com  Wed May 29 11:19:37 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8DD21F9691; Wed, 29 May 2013 11:19:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.837
X-Spam-Level: 
X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, 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 hNlEv4p3H6yb; Wed, 29 May 2013 11:19:36 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0692221F9695; Wed, 29 May 2013 11:19:35 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id ec20so9033534lab.18 for ; Wed, 29 May 2013 11:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ToFi2RNcLUaZnUS4YaCcLm9YfzvVvp+39KVj28trJrc=; b=jusLWi0iMuoF6Nc1vKY03dOH8hHqULnbTfhA/pnrr4VnNpyvVgTElNZlyafhxgmoys c8wIZbR2Vo13MhC0jsNRnn4uCcsUlMFjlXjyDOukDd6WVWSllCmx/hewfG1vmyplzFZJ s3qKMIlJeI/c54X4Y6F46bpznl+CFyIg0drZtneiWLWw88bsEyrnd9+kU68IaF/+Bz04 Z0Ksi99QCF0vz2O9kfELxRSjovBw02Xu8AGrjSPo8GwFWCdhxwrMtwMGXCk2mwaFw2nP GVCy1rr8NfazlnLbXQRwhG79wctmyCwYGKLqFtPntKGCwCRNbHBr/VL70VcjKjRhwgIe b0aQ==
MIME-Version: 1.0
X-Received: by 10.152.19.39 with SMTP id b7mr1951216lae.38.1369851573966; Wed, 29 May 2013 11:19:33 -0700 (PDT)
Received: by 10.112.157.4 with HTTP; Wed, 29 May 2013 11:19:33 -0700 (PDT)
Date: Wed, 29 May 2013 14:19:33 -0400
Message-ID: 
From: Joseph Macker 
To: iesg-secretary@ietf.org, Adrian Farrel ,  "manet@ietf.org" 
Content-Type: multipart/mixed; boundary=089e01493df4761bca04dddf6c79
Subject: [manet] (no subject)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 May 2013 18:19:37 -0000

--089e01493df4761bca04dddf6c79
Content-Type: multipart/alternative; boundary=089e01493df4761bc604dddf6c77

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

Please publish draft-ietf-manet-rfc6622-bis as a Proposed Standard. The
Shepherds Writeup has been uploaded and is replicated below.

--089e01493df4761bc604dddf6c77
Content-Type: text/html; charset=ISO-8859-1


Please publish draft-ietf-manet-rfc6622-bis as a Proposed Standard. The Shepherds Writeup has been uploaded and is replicated below.




--089e01493df4761bc604dddf6c77--
--089e01493df4761bca04dddf6c79
Content-Type: text/plain; charset=US-ASCII; name="rfc6622-bis_write-up.txt"
Content-Disposition: attachment; filename="rfc6622-bis_write-up.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hhau9cc50

KDEpIFRoZSByZXF1ZXN0IGlzIHRvIHB1Ymxpc2ggdGhpcyBkb2N1bWVudCBhcyBhIFN0YW5kYXJk
cyBUcmFjayBSRkMsCmFuZCB0aGlzIGlzIGluZGljYXRlZCBpbiB0aGUgZG9jdW1lbnQgaGVhZGVy
LgoKKDIpIERvY3VtZW50IEFubm91bmNlbWVudCBXcml0ZS1VcC4KClRlY2huaWNhbCBTdW1tYXJ5
CgpUaGUgYWJzdHJhY3Qgb2YgdGhpcyBkb2N1bWVudCBpcyBpbmNsdWRlZCBiZWxvdy4KClRoaXMg
ZG9jdW1lbnQgcmV2aXNlcywgZXh0ZW5kcyBhbmQgcmVwbGFjZXMgUkZDIDY2MjIuICBJdCBkZXNj
cmliZXMgZ2VuZXJhbCBhbmQgZmxleGlibGUgVExWcyBmb3IgcmVwcmVzZW50aW5nIGNyeXB0b2dy
YXBoaWMgSW50ZWdyaXR5IENoZWNrIFZhbHVlcyAoSUNWcykgYW5kIHRpbWVzdGFtcHMsIHVzaW5n
IHRoZSBnZW5lcmFsaXplZCBNb2JpbGUgQWQgSG9jIE5ldHdvcmsgKE1BTkVUKSBwYWNrZXQvbWVz
c2FnZSBmb3JtYXQgZGVmaW5lZCBpbiBSRkMgNTQ0NC4gIEl0IGRlZmluZXMgdHdvIFBhY2tldCBU
TFZzLCB0d28gTWVzc2FnZSBUTFZzLCBhbmQgdHdvIEFkZHJlc3MgQmxvY2sgVExWcyBmb3IgYWZm
aXhpbmcgSUNWcyBhbmQgdGltZXN0YW1wcyB0byBhIHBhY2tldCwgYSBtZXNzYWdlLCBhbmQgb25l
IG9yIG1vcmUgYWRkcmVzc2VzLCByZXNwZWN0aXZlbHkuCgoKV29ya2luZyBHcm91cCBTdW1tYXJ5
CgpXb3JraW5nIGdyb3VwIGNvbnNlbnN1cyBiZWhpbmQgdGhlIGRvY3VtZW50IGlzIHNvbGlkLiBU
aGVyZSBpcyBzdHJvbmcgY29uc2Vuc3VzIGJlaGluZCBhIHNldCBvZiBtZW1iZXJzIGluIHRoZSB3
b3JraW5nIGdyb3VwIHRoYXQgdGhpcyByZXZpc2lvbiBpcyBuZWVkZWQuIAoKCkRvY3VtZW50IFF1
YWxpdHkKClRoZSBkb2N1bWVudCBoYXMgcmVjZWl2ZWQgY2FyZWZ1bCByZXZpZXcuIFRoZXJlIGFy
ZSBzZXZlcmFsIGltcGxlbWVudGF0aW9ucyBvZiB0aGUgZG9jdW1lbnQuCgpQZXJzb25uZWwKClRo
ZSBEb2N1bWVudCBTaGVwaGVyZCBpcyBKb3NlcGggTWFja2VyIChqcG1hY2tlckBnbWFpbC5jb20p
OyB0aGUKcmVzcG9uc2libGUgQXJlYSBEaXJlY3RvcnMgYXJlIEFkcmlhbiBGYXJyZWwgYW5kIFN0
ZXdhcnQgQnJ5YW50LgoKKDMpIFRoZSBkb2N1bWVudCBTaGVwaGVyZCBoYXMgcGFydGljaXBhdGVk
IGluIHJldmlldyBib3RoIGluIHRoZSBXb3JraW5nCkdyb3VwLCBhbmQgaGFzIHJ1biB0aGUgImlk
bml0cyIgdG9vbCBhZ2FpbnN0IHRoZSBkcmFmdC4KCig0KSBUaGUgRG9jdW1lbnQgU2hlcGhlcmQg
aGFzIG5vIGNvbmNlcm5zIGFib3V0IHRoZSByZXZpZXdzIG9mIHRoZQpkb2N1bWVudDsgdGhleSBo
YXZlIGJlZW4gdGhvcm91Z2ggYW5kIHRoZXJlIGhhcyBiZWVuIGdvb2QgdGVjaG5pY2FsIGludGVy
Y2hhbmdlIGFtb25nc3QgYXV0aG9ycyBhbmQgb3RoZXIgcGFydGllcyByZWdhcmRpbmcgY29udGVu
dCBpc3N1ZXMuCgooNSkgVGhlIGF1dGhvcnMgZG8gbm90IGJlbGlldmUgdGhhdCBhZGRpdGlvbmFs
IHJldmlld3MgYXJlIHJlcXVpcmVkLAphc2lkZSBmcm9tIHRoZSB1c3VhbCBkaXJlY3RvcmF0ZSBy
ZXZpZXdzIGR1cmluZyBJRVRGIGxhc3QgY2FsbC4KCig2KSBUaGUgRG9jdW1lbnQgU2hlcGhlcmQg
aGFzIG5vIGNvbmNlcm5zIHdpdGggdGhlIGRvY3VtZW50LgoKKDcpIEFsbCBhdXRob3JzIGhhdmUg
Y29uZmlybWVkIHRoYXQgdGhleSBhcmUgdW5hd2FyZSBvZiBhbnkgSVBSIG5lZWRpbmcKZGlzY2xv
c3VyZTsgdGhlcmUgYXJlIG5vIGtub3duIElQUiBjbGFpbXMgcmVsYXRlZCB0byB0aGlzIGRvY3Vt
ZW50LgoKKDgpIE5vIElQUiBkaXNjbG9zdXJlcyBoYXZlIGJlZW4gZmlsZWQsIGFzIG5vbmUgYXJl
IHJlcXVpcmVkLgoKKDkpIFdHIGNvbnNlbnN1cyBhcHBlYXJzIHRvIGJlIHN0cm9uZy4KCigxMCkg
V0dMQyBoYXMgY2xvc2UgYW5kIG5vYm9keSBoYXMgdGhyZWF0ZW5lZCBhbiBhcHBlYWwgb3Igb3Ro
ZXJ3aXNlIGluZGljYXRlZCBleHRyZW1lIGRpc2NvbnRlbnQuCgooMTEpIFRoZXJlIGFyZSB0d28g
ZXJyb3JzIGFjY29yZGluZyB0byBpZG5pdHM6IHR3byBkb3dud2FyZCBub3JtYXRpdmUgcmVmZXJl
bmNlcyAoYW5kIHNvbWUgcG9zc2libGUgZG93bnJlZnMgdG8gbm9uLVJGQ3MpLiBSZWZlciB0byBw
b2ludCAxNS4KCigxMikgTUlCIERvY3RvciwgbWVkaWEgdHlwZSwgYW5kIFVSSSByZXZpZXdzIGFy
ZSBub3QgcmVxdWlyZWQuCgooMTMpIEFsbCByZWZlcmVuY2VzIGhhdmUgYmVlbiBkZWZpbmVkIGFz
IGVpdGhlciBub3JtYXRpdmUgb3IKaW5mb3JtYXRpdmUuCgooMTQpIE5vIG5vcm1hdGl2ZSByZWZl
cmVuY2VzIGV4aXN0IHRvIGRvY3VtZW50cyBub3QgcmVhZHkgZm9yCmFkdmFuY2VtZW50LiBPZiB0
aGUgbm9ybWF0aXZlIHJlZmVyZW5jZXMsIGFsbCBhcmUgdG8gYWxyZWFkeSBwdWJsaXNoZWQKUkZD
J3MgKG9yIHRvIG5vbi1JRVRGIGRvY3VtZW50cywgc2VlIHBvaW50IDExKS4KCigxNSkgVGhlcmUg
YXJlIHNldmVyYWwgZG93bndhcmQgbm9ybWF0aXZlIHJlZmVyZW5jZXMgaW4gdGhlIGRvY3VtZW50
LCBhcyB3ZWxsIGFzIApub24tSUVURiBkb2N1bWVudHM6CiAgKiogRG93bnJlZjogTm9ybWF0aXZl
IHJlZmVyZW5jZSB0byBhbiBJbmZvcm1hdGlvbmFsIFJGQzogUkZDIDM0NDcKICAqKiBEb3ducmVm
OiBOb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFuIEluZm9ybWF0aW9uYWwgUkZDOiBSRkMgMjEwNAog
IC0tIFBvc3NpYmxlIGRvd25yZWY6IE5vbi1SRkMgKD8pIG5vcm1hdGl2ZSByZWZlcmVuY2U6IHJl
Zi4gJ05JU1QtRklQUy0xOTcnCiAgLS0gUG9zc2libGUgZG93bnJlZjogTm9uLVJGQyAoPykgbm9y
bWF0aXZlIHJlZmVyZW5jZTogcmVmLiAnTklTVC1GSVBTLTE4Ni0zJwogIC0tIFBvc3NpYmxlIGRv
d25yZWY6IE5vbi1SRkMgKD8pIG5vcm1hdGl2ZSByZWZlcmVuY2U6IHJlZi4gJ0FOU0ktWDktNjIt
MjAwNScKICAtLSBQb3NzaWJsZSBkb3ducmVmOiBOb24tUkZDICg/KSBub3JtYXRpdmUgcmVmZXJl
bmNlOiByZWYuICdOSVNULVNQLTgwMC02NycKICAtLSBQb3NzaWJsZSBkb3ducmVmOiBOb24tUkZD
ICg/KSBub3JtYXRpdmUgcmVmZXJlbmNlOiByZWYuICdOSVNULUZJUFMtMTgwLTQnCgpUaGUgdHdv
IGRvd25yZWZzIGFyZSBsaXN0ZWQgaW4gaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAv
aWVzZy90cmFjL3dpa2kvRG93bnJlZlJlZ2lzdHJ5IGFzIGFjY2VwdGFibGUgZG93bnJlZnMuIFRo
ZSBvdGhlciBwb3NzaWJsZSBkb3ducmVmcyBhcmUgZXh0ZXJuYWwgc3RhbmRhcmRzLgoKKDE2KSBU
aGUgZG9jdW1lbnQgd2lsbCBvYnNvbGV0ZSBSRkM2NjIyLiBUaGlzIG9ic29sZXRlZCBSRkMgaXMg
bGlzdGVkIG9uIHRoZSB0aXRsZSBwYWdlIGhlYWRlciwgbGlzdGVkIGluIHRoZSBhYnN0cmFjdCwg
YW5kIGRpc2N1c3NlZCBpbiB0aGUgaW50cm9kdWN0aW9uLgoKKDE3KSBUaGUgRG9jdW1lbnQgU2hl
cGhlcmQgaGFzIHJldmlld2VkIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24Kb2YgdGhl
IGRvY3VtZW50LCBhbmQgaXQgYXBwZWFycyB3aG9sbHkgY29uc2lzdGVudCB3aXRoIHRoZSBib2R5
IG9mIHNhaWQKZG9jdW1lbnQuIEV4dGVuc2lvbnMgYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBw
cm9wcmlhdGUgcmVzZXJ2YXRpb25zIGluCklBTkEgcmVnaXN0cmllcy4gQWxsIElBTkEgcmVnaXN0
cmllcyBoYXZlIGJlZW4gY2xlYXJseSBkZWZpbmVkLgoKKDE4KSBJbXBhY3Qgb24gSUFOQSByZWdp
c3RyaWVzIDoKCkEgbmV3IHR5cGUgZXh0ZW5zaW9uIGhhcyBiZWVuIGFkZGVkIHRvIHRoZSBmb2xs
b3dpbmcgcmVnaXN0cmllcyBzZXQgdXAgYnkgUkZDNjYyMjogdGhlIElDViBQYWNrZXQgVExWIFR5
cGUgRXh0ZW5zaW9ucyByZWdpc3RyeSwgdGhlIElDViBNZXNzYWdlIFRMViBUeXBlIEV4dGVuc2lv
bnMgYW5kIHRoZSBJQ1YgQWRkcmVzcyBUTFYgVHlwZSBFeHRlbnNpb25zIHJlZ2lzdHJpZXMuCgoo
MTkpIFRoZXJlIGFyZSBubyBzZWN0aW9ucyB3cml0dGVuIGluIGEgZm9ybWFsIGxhbmd1YWdlLCBz
dWNoIGFzIFhNTCBjb2RlLCBCTkYgcnVsZXMsIE1JQiBkZWZpbml0aW9ucywgZXRjLiA=
--089e01493df4761bca04dddf6c79--

From jpmacker@gmail.com  Wed May 29 11:21:41 2013
Return-Path: 
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9250821F9007; Wed, 29 May 2013 11:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.718
X-Spam-Level: 
X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=0.881,  BAYES_00=-2.599, 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 a2Cn434-k-Tx; Wed, 29 May 2013 11:21:40 -0700 (PDT)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 69B4821F91B7; Wed, 29 May 2013 11:21:39 -0700 (PDT)
Received: by mail-la0-f50.google.com with SMTP id ed20so8997485lab.37 for ; Wed, 29 May 2013 11:21:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Mq+o7XpRN2OSQgR055wk/6q5eF8fSCmW9Gj5jldKwXA=; b=jbJdCcNkq3AGyu+sFjZUXk7u3tIxeA5Kdk0/8Rc+Zx3igMCPP6n2gCAs0l4rqlEzhG DfLKwBhsfMRfJZM61kDPbnmZ4Anh71RWOZ9/NMq2vycm8rOiNOd5ebRolgpYxzJ+/kQP zGqxdrQWhLWIYvw/I4u/WufQItPrNovS6JNQDu61bt1+rfLnnlaFrpEQUk6NPmLxXYUd 730s8MA/JjvYKzj/CgO2BpGXFu/x1FFLXvBWQIN7oq+Kk6cOIAm70AZTwcvBMXz2HYba WC9EC1M4it0BcDD/zpV2wwzrB+R9n2VNvcB9iqvc9feu/8BrgrrchWDzF4exW3EL6DWE EdEA==
MIME-Version: 1.0
X-Received: by 10.152.5.8 with SMTP id o8mr1980726lao.11.1369851698250; Wed, 29 May 2013 11:21:38 -0700 (PDT)
Received: by 10.112.157.4 with HTTP; Wed, 29 May 2013 11:21:38 -0700 (PDT)
Date: Wed, 29 May 2013 14:21:38 -0400
Message-ID: 
From: Joseph Macker 
To: iesg-secretary@ietf.org, Adrian Farrel ,  "manet@ietf.org" 
Content-Type: multipart/mixed; boundary=089e01419b06de8baa04dddf73b3
Subject: [manet] Publication request for 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  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 May 2013 18:21:41 -0000

--089e01419b06de8baa04dddf73b3
Content-Type: multipart/alternative; boundary=089e01419b06de8ba504dddf73b1

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

Please publish draft-ietf-manet-nhdp-olsrv2-sec as a Proposed Standard. The
Shepherds Writeup has been uploaded and is replicated below.

--089e01419b06de8ba504dddf73b1
Content-Type: text/html; charset=ISO-8859-1


Please publish draft-ietf-manet-nhdp-olsrv2-sec as a Proposed Standard. The Shepherds Writeup has been uploaded and is replicated below.




--089e01419b06de8ba504dddf73b1--
--089e01419b06de8baa04dddf73b3
Content-Type: text/plain; charset=US-ASCII; name="nhdp-olsrv2-sec.txt"
Content-Disposition: attachment; filename="nhdp-olsrv2-sec.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hhauc1le0

KDEpIFRoZSByZXF1ZXN0IGlzIHRvIHB1Ymxpc2ggdGhpcyBkb2N1bWVudCBhcyBhIFN0YW5kYXJk
cyBUcmFjayBSRkMsCmFuZCB0aGlzIGlzIGluZGljYXRlZCBpbiB0aGUgZG9jdW1lbnQgaGVhZGVy
LgoKKDIpIERvY3VtZW50IEFubm91bmNlbWVudCBXcml0ZS1VcC4KClRlY2huaWNhbCBTdW1tYXJ5
CgpUaGUgYWJzdHJhY3Qgb2YgdGhpcyBkb2N1bWVudCBpcyBpbmNsdWRlZCBiZWxvdy4KClRoaXMg
ZG9jdW1lbnQgc3BlY2lmaWVzIGludGVncml0eSBhbmQgcmVwbGF5IHByb3RlY3Rpb24gZm9yIHJl
cXVpcmVkIGltcGxlbWVudGF0aW9uIGluIHRoZSBNQU5FVCBOZWlnaGJvcmhvb2QgRGlzY292ZXJ5
IFByb3RvY29sIChOSERQKSBhbmQgdGhlIE9wdGltaXplZCBMaW5rIFN0YXRlIFJvdXRpbmcgUHJv
dG9jb2wgdmVyc2lvbiAyIChPTFNSdjIpLiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgYW4g
aW5jbHVkZWQgaW50ZWdyaXR5IGNoZWNrIHZhbHVlIChJQ1YpIGFuZCBhIHRpbWVzdGFtcCBUTFYs
IGRlZmluZWQgaW4gUkZDNjYyMmJpcywgYXJlIHVzZWQgYnkgTkhEUCBhbmQgT0xTUnYyIGZvciBj
b3VudGVyaW5nIGEgbnVtYmVyIG9mIHNlY3VyaXR5IHRocmVhdHMuICBUaGUgSUNWIFRMViB1c2Vz
IGEgU0hBLTI1NiBiYXNlZCBITUFDIGFuZCBvbmUgb3IgbW9yZSBzaGFyZWQgc2VjcmV0IGtleXMu
ICBUaGUgdGltZXN0YW1wIFRMViBpcyBiYXNlZCBvbiBQT1NJWCB0aW1lLCBhbmQgYXNzdW1lcyB0
aGF0IHRoZSBjbG9ja3MgaW4gYWxsIHJvdXRlcnMgaW4gdGhlIG5ldHdvcmsgY2FuIGJlIHN5bmNo
cm9uaXplZCB3aXRoIHN1ZmZpY2llbnQgcHJlY2lzaW9uLiAgVGhlIG1lY2hhbmlzbSBpbiB0aGlz
IHNwZWNpZmljYXRpb24gY2FuIGFsc28gYmUgdXNlZCBmb3Igb3RoZXIgTUFORVQgcHJvdG9jb2xz
IHVzaW5nIFJGQzU0NDQuCgoKV29ya2luZyBHcm91cCBTdW1tYXJ5CgpXb3JraW5nIGdyb3VwIGNv
bnNlbnN1cyBiZWhpbmQgdGhlIGRvY3VtZW50IGlzIG9ic2VydmVkIGFzIHN0cm9uZy4gVGhlcmUg
YXJlIG51bWVyb3VzIGF1dGhvcnMgYW5kIGNvbnRyaWJ1dG9ycyB0aGF0IGZlZWwgdGhpcyBkb2N1
bWVudCBpcyByZWFkeSB0byBwcm9jZWVkLiAKCgpEb2N1bWVudCBRdWFsaXR5CgpUaGUgZG9jdW1l
bnQgaGFzIHJlY2VpdmVkIGNhcmVmdWwgcmV2aWV3LiBUaGVyZSBhcmUgc2V2ZXJhbCBpbXBsZW1l
bnRhdGlvbnMgb2YgdGhlIGRvY3VtZW50LgoKUGVyc29ubmVsCgpUaGUgRG9jdW1lbnQgU2hlcGhl
cmQgaXMgSm9zZXBoIE1hY2tlciAoanBtYWNrZXJAZ21haWwuY29tKTsgdGhlCnJlc3BvbnNpYmxl
IEFyZWEgRGlyZWN0b3JzIGFyZSBBZHJpYW4gRmFycmVsIGFuZCBTdGV3YXJ0IEJyeWFudC4KCigz
KSBUaGUgZG9jdW1lbnQgU2hlcGhlcmQgaGFzIHBhcnRpY2lwYXRlZCBpbiByZXZpZXcgYm90aCBp
biB0aGUgV29ya2luZwpHcm91cCwgYW5kIGhhcyBydW4gdGhlICJpZG5pdHMiIHRvb2wgYWdhaW5z
dCB0aGUgZHJhZnQuCgooNCkgVGhlIERvY3VtZW50IFNoZXBoZXJkIGhhcyBubyBjb25jZXJucyBh
Ym91dCB0aGUgcmV2aWV3cyBvZiB0aGUKZG9jdW1lbnQ7IHRoZXkgaGF2ZSBiZWVuIHRob3JvdWdo
LgoKKDUpIFRoZSBhdXRob3JzIGRvIG5vdCBiZWxpZXZlIHRoYXQgYWRkaXRpb25hbCByZXZpZXdz
IGFyZSByZXF1aXJlZCwKYXNpZGUgZnJvbSB0aGUgdXN1YWwgZGlyZWN0b3JhdGUgcmV2aWV3cyBk
dXJpbmcgSUVURiBsYXN0IGNhbGwuCgooNikgVGhlIERvY3VtZW50IFNoZXBoZXJkIGhhcyBubyBj
b25jZXJucyB3aXRoIHRoZSBkb2N1bWVudC4KCig3KSBBbGwgYXV0aG9ycyBoYXZlIGNvbmZpcm1l
ZCB0aGF0IHRoZXkgYXJlIHVuYXdhcmUgb2YgYW55IElQUiBuZWVkaW5nCmRpc2Nsb3N1cmU7IHRo
ZXJlIGFyZSBubyBrbm93biBJUFIgY2xhaW1zIHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudC4KCig4
KSBObyBJUFIgZGlzY2xvc3VyZXMgaGF2ZSBiZWVuIGZpbGVkLCBhcyBub25lIGFyZSByZXF1aXJl
ZC4KCig5KSBXRyBjb25zZW5zdXMgYXBwZWFycyB0byBiZSBzdHJvbmcuCgooMTApIE5vYm9keSBo
YXMgdGhyZWF0ZW5lZCBhbiBhcHBlYWwgb3Igb3RoZXJ3aXNlIGluZGljYXRlZCBleHRyZW1lIGRp
c2NvbnRlbnQuCgooMTEpIFRoZXJlIGlzIG9uZSBtaW5vciBuaXQ6CgogID09IFRoZSAnVXBkYXRl
czogJyBsaW5lIGluIHRoZSBkcmFmdCBoZWFkZXIgc2hvdWxkIGxpc3Qgb25seSB0aGUgX251bWJl
cnNfCiAgICAgb2YgdGhlIFJGQ3Mgd2hpY2ggd2lsbCBiZSB1cGRhdGVkIGJ5IHRoaXMgZG9jdW1l
bnQgKGlmIGFwcHJvdmVkKTsgaXQKICAgICBzaG91bGQgbm90IGluY2x1ZGUgdGhlIHdvcmQgJ1JG
QycgaW4gdGhlIGxpc3QuCiAgICAgCiAgICAgVGhpcyB3aWxsIGJlIGNvcnJlY3RlZCBpbiB0aGUg
bmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQgKHRvZ2V0aGVyIHdpdGggY2hhbmdlcyBhcyBjb25z
ZXF1ZW5jZSBvZiBBRCByZXZpZXcsIGRpcmVjdG9yYXRlIHJldmlld3MsIElFVEYgTEMgZXRjLiku
CgooMTIpIE1JQiBEb2N0b3IsIG1lZGlhIHR5cGUsIGFuZCBVUkkgcmV2aWV3cyBhcmUgbm90IHJl
cXVpcmVkLgoKKDEzKSBUaGVyZSBhcmUgb25seSBub3JtYXRpdmUgcmVmZXJlbmNlcy4KCigxNCkg
T2YgdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2VzLCB0d28gZHJhZnRzIGFyZSBub3QgeWV0IFJGQ3M6
IAogICAgICBpKSBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2MiBpcyB3YWl0aW5nIGluIHRoZSBSRkMg
ZWRpdG9yIHF1ZXVlIGZvciB0aGlzIGRvY3VtZW50IGFuZCBmb3IgZHJhZnQtaWV0Zi1tYW5ldC1y
ZmM2NjIyLWJpcwogICAgICBpaSkgZHJhZnQtaWV0Zi1tYW5ldC1yZmM2NjIyLWJpcywgd2hpY2gg
aGFzIGFscmVhZHkgcGFzc2VkIFdHIExDIHdpdGhvdXQgb2JqZWN0aW9ucyBmcm9tIHRoZSBXRywg
YW5kIHdoaWNoIGlzIGN1cnJlbnRseSBwcm9jZWVkaW5nIHRvIEFEIHJldmlldy4KICAgICAgCigx
NSkgVGhlcmUgYXJlIG5vIGRvd253YXJkIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGluIHRoZSBkb2N1
bWVudC4KCigxNikgUHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCB3aWxsIG5vdCBjaGFuZ2Ug
dGhlIHN0YXR1cyBvZiBhbnkgZXhpc3RpbmcgUkZDcy4KCigxNykgVGhpcyBkb2N1bWVudCBoYXMg
bm8gYWN0aW9ucyBmb3IgSUFOQS4KCigxOCkgVGhlcmUgaXMgbm8gaW1wYWN0IG9uIElBTkEgcmVn
aXN0cmllcy4KCigxOSkgVGhlcmUgYXJlIG5vIHNlY3Rpb25zIHdyaXR0ZW4gaW4gYSBmb3JtYWwg
bGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MIGNvZGUsIEJORiBydWxlcywgTUlCIGRlZmluaXRpb25zLCBl
dGMu
--089e01419b06de8baa04dddf73b3--