From ulrich@herberg.name Mon Jul 1 09:17:34 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 DC8F221F9FC2 for ; Mon, 1 Jul 2013 09:17:34 -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 9ZCQzP8MKNHt for ; Mon, 1 Jul 2013 09:17:34 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4B621F9FC1 for ; Mon, 1 Jul 2013 09:17:34 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp12so5183223pab.35 for ; Mon, 01 Jul 2013 09:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=ktNVH2AI9zY7jqYeOdv2C0Ud3Hu1VJr1hSdd5yeVLZk=; b=oHFFiG2z6X7aV7o3+g/SXi3CcQO7FPdkV6Q9Q1Xqds/JigbS02rIueiFYOmZQTSW+4 DDsqgmrMC82Wae7d8Uyj3FmdQxs4F4f103Vv8gAFWlGE9lP0IHiL5Au8SXU3a9NyZWgK FcxjdMoueVv8waTeLkRvi0QuxJgk6r8W4ph+s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=ktNVH2AI9zY7jqYeOdv2C0Ud3Hu1VJr1hSdd5yeVLZk=; b=UbLRTVzHkIh63znPR7DmBdylxd9RdtlXRi0Qepuu1F14cWgG7z3oRT7SbgABpLPgao 523Sy+N/QgAkx4xvKLmWv1+UDt39r8Ubncn53IfJDp+X5gVqHh3zMJjUsQmlXbmvwJg9 LBsnMR9o/rAa4AyKS4WAbSiKPzQcutVLawzSG0RiRU73AkltxRl3TPpzTAaOqGpK7sS4 xFAoOjxafBE1rH3xoFjA+rU9RxgasjmYbkqh/eDq4JNLbAR/0RzVItaMO91wqAWWLP24 O1W20Y+4q7BPrMgFvZxr+AnMqa/SuJ+BKRweeeA12ndLb+2kZJEJlnWa5LEvAGAkA0FU JWfQ== MIME-Version: 1.0 X-Received: by 10.68.75.49 with SMTP id z17mr24678572pbv.169.1372695453933; Mon, 01 Jul 2013 09:17:33 -0700 (PDT) Received: by 10.70.17.37 with HTTP; Mon, 1 Jul 2013 09:17:33 -0700 (PDT) Date: Mon, 1 Jul 2013 09:17:33 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkb+8dWYlliKu7XCa+nvAhQ2fphMr3uo8j5BUch9V2v/H0jTEeFiU/Eg41VRGq+75TgFyCW Subject: [manet] Slot requests 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, 01 Jul 2013 16:17:35 -0000 Hi, please send your requests for slots for the MANET meeting in the next 10 days. Thanks Ulrich From trac+manet@trac.tools.ietf.org Mon Jul 1 12:15:58 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 EDD2B11E820D for ; Mon, 1 Jul 2013 12:15:58 -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 e28JXXKTvlEg for ; Mon, 1 Jul 2013 12:15:58 -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 C0E4F11E819C for ; Mon, 1 Jul 2013 12:15:45 -0700 (PDT) Received: from localhost ([127.0.0.1]:44390 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UtjZa-0002Ek-W8; Mon, 01 Jul 2013 21:15:39 +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, charliep@computer.org X-Trac-Project: manet Date: Mon, 01 Jul 2013 19:15:38 -0000 X-URL: http://tools.ietf.org/manet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/manet/trac/ticket/11#comment:2 Message-ID: <076.48ff11613886bf20ced58662d8adbd93@trac.tools.ietf.org> References: <061.56c0faacefe8cd4335a20edf5d6cc53a@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <061.56c0faacefe8cd4335a20edf5d6cc53a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, charliep@computer.org, manet@ietf.org X-SA-Exim-Mail-From: trac+manet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: manet@ietf.org Subject: Re: [manet] #11: Error: failure of delivery to single host can invalidate route to an entire network 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: Mon, 01 Jul 2013 19:15:59 -0000 #11: Error: failure of delivery to single host can invalidate route to an entire network Comment (by charliep@computer.org): I have devised a relatively straightforward proposal to repair this error. In section 8.4, top of page 35, replace: If the route satisfies all of the above conditions, !HandlingRtr sets the Route.Broken flag for that route. By: If the Route satisfies all of the above conditions, !HandlingRtr checks whether Route.!PrefixLength is the same as the prefix length for !UnreachableNode.Address. If so, !HandlingRtr simply sets the Route.Broken flag for that Route. Otherwise, !HandlingRtr creates a new route (call it !BrokenRoute) with the same !PrefixLength as the prefix length for !UnreachableNode.Address, and sets the !BrokenRoute.Broken flag for that new route. If the prefix length for !BrokenRoute is shorter than Route.!PrefixLength, then Route MUST be expunged from the routing table (since it is a subroute of the larger route which is reported to be broken). -- -----------------------------------+------------------------------ Reporter: charliep@computer.org | Owner: Charlie Perkins Type: defect | Status: new Priority: major | Milestone: Component: dymo | Version: Severity: Active WG Document | Resolution: Keywords: RERR, subnet route | -----------------------------------+------------------------------ Ticket URL: manet From internet-drafts@ietf.org Tue Jul 2 08:11: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 D7E2421F9E16; Tue, 2 Jul 2013 08:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, 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 S0b3IpFnxe0m; Tue, 2 Jul 2013 08:11:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 547F321F9DB6; Tue, 2 Jul 2013 08:11:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130702151127.16431.81506.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2013 08:11:27 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 15:11:48 -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 : Integrity Check Value and Timestamp TLV Definitions for = Mobile Ad Hoc Networks (MANETs) Author(s) : Ulrich Herberg Thomas Heide Clausen Christopher Dearlove Filename : draft-ietf-manet-rfc6622-bis-03.txt Pages : 28 Date : 2013-07-02 Abstract: This document revises, extends and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Jul 2 09:08: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 1C82421F9FC1; Tue, 2 Jul 2013 09:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.121, 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 p8sxnAjg0X7e; Tue, 2 Jul 2013 09:08:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B5A21F9FD0; Tue, 2 Jul 2013 09:08:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130702160849.20868.24745.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2013 09:08:49 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-olsrv2-sec-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:08: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 : Integrity Protection for Control Messages in NHDP and OL= SRv2 Author(s) : Ulrich Herberg Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-olsrv2-sec-03.txt Pages : 15 Date : 2013-07-02 Abstract: This document specifies integrity and replay protection for the MANET Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a timestamp TLV based on POSIX time. The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444. This document updates RFC 6130 and RFC xxxx by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-sec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-nhdp-olsrv2-sec-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-nhdp-olsrv2-sec-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ulrich@herberg.name Tue Jul 2 09:10:18 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 CB1F221F9C61 for ; Tue, 2 Jul 2013 09:10:17 -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 6JkrB+MpXwHk for ; Tue, 2 Jul 2013 09:10:16 -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 37EE011E80D1 for ; Tue, 2 Jul 2013 09:10:13 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wz7so6341373pbc.37 for ; Tue, 02 Jul 2013 09:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OC3wWv3RAvXMB+/tK7TiH1vMiaRx/4FghRBb8G+S8hc=; b=NdRAHmE08R8VyieESB7s07Us2EUJcJMM40RurY517wPeP8DTZspjehkeo5VU9R9Xkv 8CZ5SPFef66P0VTsOlcPY8h5lUy8x/K+NkJT59x2GLg1hw+/e/gHPCmdATdPoc/bFmCr PiaGeJmXP26WKR7wSUjlHgGwK4Lkw/AAHntaU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=OC3wWv3RAvXMB+/tK7TiH1vMiaRx/4FghRBb8G+S8hc=; b=hkD6I3EvMIg9znSGoEyu33HOMPYFvJos8/T163m+KzUZBytZT9nW7BveCvUs/poTh6 +QDDtarv1gnpb23h551rdHHV4kUH+4YfcfOqASxnzxaekbGR4rrhEnJ4lmmPgSGm4Tg6 5T5nOx+vOVvGJSPASeqzingSuQ08yQsXgvnIHR6rakYh/EGwrM1iXBTlClVFTuB6bxUJ cVHfVPY0hZlCWGGXtSpBz90D5wEeHPycsuB10qX4jdZ1zddh3mgpuFC6GaBKbhMU6FfJ 1ScUIjVMMnhsHVRi9o7YPt0Lr58GBVehSaoZC9YUWJUtok4xvnwpA1iNNBd68wYo5q8u bV/Q== MIME-Version: 1.0 X-Received: by 10.68.231.200 with SMTP id ti8mr29747401pbc.46.1372781412839; Tue, 02 Jul 2013 09:10:12 -0700 (PDT) Received: by 10.70.34.111 with HTTP; Tue, 2 Jul 2013 09:10:12 -0700 (PDT) In-Reply-To: References: <012301ce6ae2$ab3714f0$01a53ed0$@olddog.co.uk> Date: Tue, 2 Jul 2013 09:10:12 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkwlr7Wgtq3VK+4unIeTsCxgRBLpDJyYCqVrgBq1vGcduYf/hsynePffBiajkmC/MomYFm5 Cc: "manet@ietf.org" , "draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org" Subject: Re: [manet] AD review of draft-ietf-manet-nhdp-olsrv2-sec X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:10:18 -0000 Adrian, thanks for your review. We have submitted a new revision that hopefully addresses your review. Best regards Ulrich On Mon, Jun 17, 2013 at 5:42 AM, Dearlove, Christopher (UK) wrote: > Some personal comments marked by >>> below. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre= , Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: 16 June 2013 23:42 > To: draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org > Cc: manet@ietf.org > Subject: AD review of draft-ietf-manet-nhdp-olsrv2-sec > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Hi Authors, > > Thanks for this small but important addition to NHDP and OLSRv2. I > found the document pretty clear and have only one technical issue with > it. The bunch of editorial comments below can be taken under > advisement, but I think that fixing them will make the document more > readable and will ease its passage through the next stages. > > If you can turn around a new revision (or tell me that none of my > suggestions needs to be adopted) then I can kick of the IETF last call. > > Thanks for the work, > Adrian > > --- > > Technical issue... > > I understand that this document specifies mandatory rules for NHDP (and > OLSRv2) and your use of "updates" is correct. However, there are > obviously existing implementations of NHDP that are deployed. > > I am searching for the backward compatibility description. An existing > implementation of NHDP may now receive messages containing the ICV or > timestamp TLVs. But these will not be used by the legacy implementation > because they are unknown TLVs. > > How will they be processed by the legacy implementation? I think this > needs just a single statement and a pointer to the correct rule in 6130. > >>>> The legacy implementation should be straightforward, nothing in NHDP d= iscusses other TLVs. In fact that's the whole point of the TLV design, if y= ou don't understand it, ignore it. I think this may already be said (there = is a discussion of extensibility) but haven't checked. > >>>> There is one nit, that there is permission to refuse messages "for any= other reason". That can always be abused if you want to create an implemen= tation that is technically compliant, but useless. Failing because you have= received a TLV you don't understand would be such a case. (Failing because= you receive an expected TLV with an unexpected value is a subtlety that th= e authors are actually discussing, but is not relevant here.) > > How will the way that a legacy implementation behaves change the > perception of security that the sender has? This obviously depends on > the answer to the previous question, and can hopefully be stated very > briefly. > >>>> This is actually a bit of a red herring, in that such implementations = are irrelevant, they can do what they like, communicate with each other, be= friendly or unfriendly, whatever. They are just all ignored. (As far as ro= uting is concerned. There are issues above and below the network layer, but= we aren't solving them in a network layer protocol.) > >>>> (That these aren't real issues in practice is not to say that a senten= ce or two about them wouldn't go amiss. It should make the sentence or two = easy. Usually the hard thing is to work out where best to put them.) > > --- > > I think that this document will also update [OLSRv2] when it is > published as an RFC (even if that is simultaneous). Therefore, I > recommend to top the document with... > > [RFC Editor note: Please replace "xxxx" throughout this document with > the RFC number assigned to [OLSRv2], and remove this note.] > > Noting that the citation will be fixed by the RFC Editor in any case. > > --- > > The line in the document header should read > "Updates: 6130, xxxx (if approved)" > > --- > > The Abstract should mention > "This document updates RFC 6130 and RFC xxxx." > >>>> All the above good points. We've always discussed it in those terms, j= ust failed to follow through. > > Additionally, I found the Abstract quite dense. Can I suggest some > re-wording. > > OLD > This document specifies integrity and replay protection for required > implementation in the MANET Neighborhood Discovery Protocol (NHDP) > and the Optimized Link State Routing Protocol version 2 (OLSRv2). > This document specifies how an included integrity check value (ICV) > and a timestamp TLV, defined in RFC6622bis, are used by NHDP and > OLSRv2 for countering a number of security threats. The ICV TLV uses > a SHA-256 based HMAC and one or more shared secret keys. The > timestamp TLV is based on POSIX time, and assumes that the clocks in > all routers in the network can be synchronized with sufficient > precision. The mechanism in this specification can also be used for > other MANET protocols using RFC5444. > NEW > This document specifies integrity and replay protection for the MANET > Neighborhood Discovery Protocol (NHDP) and the Optimized Link State > Routing Protocol version 2 (OLSRv2). This protection is achieved by > using the Integrity Check value (ICV) and the Timestamp TLV. > >>>> I don't like the last line's use of the definite article and TLV in on= e case but not the other. So some massaging needed. > > The mechanism in this specification can also be used for protocols > that use the generalized packet/message format described in RFC 5444. > >>>> Protocols wants an "other" before it. > > This document updates RFC 6130 and RFC xxxx by mandating the > implementation of integrity and replay protection in NHDP and OLSRv2. > END > > I think this has thrown away what may be to some the key information of H= MAC-SHA256 and POSIX timestamp, those being options for those TLVs. So whil= e I agree with the separation of the statements about status, I think we ma= y want to put something back. > > --- > > The Introduction should also say something like: > > This document updates [RFC6130] and [OLSRv2] by mandating the > implementation of integrity and replay protection in NHDP and OLSRv2. > >>>> Goes with earlier. > > --- > > In the Introduction, I had to read the following paragraph several times > and look at the figure in order to work out what you meant. At that point > it was obvious, but can I suggest re-wording: > > OLD > The mechanism specified in this document exists between NHDP's and > OLSRv2's message processing/generation and the [RFC5444] packet > parsing/generation, as illustrated in Figure 1. > NEW > The mechanism specified in this document is placed in the packet- > processing flow as indicated in Figure 1. > >>>> Not quite. It's the packet/message processing flow, in particular at t= he point where inserted, it's the message processing flow (but is packet el= sewhere). > > It exists between the > packet parsing/generation function of [RFC5444], and the message > processing/generation function of NHDP and OSLRv2. > END > > --- > > Section 3 > > I found the following hard: > o Specifies an association of ICVs with messages, and for using > missing or invalid ICVs as such an additional reason for rejecting > a message as "badly formed and therefore invalid for processing". > > How about: > o Specifies an association of ICVs with protocol messages, and > specifies how to use a missing or invalid ICV as an reason to > reject a message as "badly formed and therefore invalid for > processing". > >>>> I can live with that. > > --- > > Section 3 > > o Specifies the implementation of an ICV Message TLV, defined in > [RFC6622bis], using a SHA-256 based HMAC applied to the > appropriate message contents (and for HELLO messages also > including the IP datagram source address). Deployments of > [RFC6130] and [OLSRv2] using this framework should use an HMAC/ > SHA-256 ICV TLV, but may use different algorithms if more > appropriate in a deployment. An implementation may also use more > than one ICV TLV in a message, as long as they each use a > different algorithm to calculate the ICV. > > There is a "should" and two "may"s in this text. Given the use of 2119 > language higher up the section and in the next bullet, I wondered > whether you wanted this in 2119-speak as well. > >>>> I'm not going to work out a definite answer here, except to agree that= within this section we should be consistent. We usually use SHOULD etc. in= normative parts (and non-normative appendices on the understanding that if= you adopt them, then they kick in) but should etc. in early descriptive pa= rts (like sections 1 and 4). Section 3 hovers on borderline, I'm not sure w= huich way we usually go with it, but should be consistent. > > --- > > I think the RFC Editor would ask you for help determining the > consistency of case in "timestamp TLV" and "TIMESTAMP TLV". Can you > check you are happy with what you have. > >>>> We can do that. We've usually tried, but sometimes edits may be made a= fter last time you (we) remembered to check, so I can't at this moment guar= antee all is correct, but it can be checked. > > --- > > The last sentence of Section 4 says: > > This framework specifies that a > message MUST be rejected if the ICV Message TLV is absent, or its > value cannot be verified. > > This is equivalent to saying that a sender MUST include an ICV Message > TLV in every message it sends. Initially, it seemed to me that this > contradicted the statements about optional use in deployments: e.g. > (from the introduction), > > A deployment may choose > to use no such security mechanisms, but this is not recommended. > > > So I think that what you are saying is actually: > > This framework specifies that an implementation conforming to this > specification and with security enabled, MUST reject a received > message if the ICV Message TLV is absent, or its value cannot be > verified. > >>>> My view (and whether the text reflects that is a question) is that we = have a framework. The rules say you MUST implement it, but then MAY use it.= IF you use THEN there are various MUST/SHOULD/MAY rules. If you don't use = then none of them apply. > > --- > > Section 5 > > When you say "silently discarded" do you intend to preclude raising an > alert or incrementing a count? It seems likely that over-age messages > are indicative of something (like a replay attack, or an echo, or long > delays, or a misconfigured constant) and some log of the fact might be > useful. The usual way to handle this is "An implementation MAY log or > count such events, but SHOULD be careful to avoid logging storms caused > by a replay attack." > >>>> Silently discarded is a term used already in the other specifications,= so nothing new here. I think it applies within the protocol framework - so= no update of protocol state, messages sent etc. Outside the protocol (e.g.= logging) is outside scope, so you can do what you like. > > --- > > Section 5 > > However it should also be noted that, in > the ideal case, the parameters SHOULD be significantly less than > those bounds. > > Some smart-arse on the IESG is going to ask what "significantly" means. > Is there any way you can quantify this: e.g., 27.5% > >>>> I think the (obviously humorous) 27.5% illustrates exactly the problem= . Yes we've has people ask this before,. but frankly they may be demonstrat= ing a lack of smarts. There is no hard and fast rule, there is only ever a = tradeoff, and it's false precision to actually say even " a quarter". Now b= ecause IESG people will do what they will, and one has to accommodate them,= we have before now fudged a bit to hide this. No be fair, there is one jus= tification for saying e.g. "a quarter", so that people at least are guided = in the direction of something not entirely insane (like say a millionth). H= owever at this time I'm not sure what "a quarter" should actually be. > > --- > > Section 7 > > Should this section also note that routers should be able to be > configured to use (or not use) the mechanisms described in this > document, and that implementations should make use of these mechanisms > the default? > >>>> Not sure about that. I don't thing default is the answer. Given that = things won't work with a mixture, we are in the area of administrative conf= iguration. And as we need a key, and there is no default key (a bit of an o= xymoron) I don't think saying on by default works. Off by default would wor= k, but is dangerous. So I think I'd stick with that default is not relevant= , it must be administratively configured. > > --- > > Section 9.1.2 > > Will the readership know what is meant by Link Spoofing or should you > give a reference? > >>>> Actually I think I raised this one, as it's not a term I use. Ulrich h= ad an answer at the time, so I will defer to him. > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > From ulrich@herberg.name Tue Jul 2 22:34:33 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 5437221F9019 for ; Tue, 2 Jul 2013 22:34:33 -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 lXxY8H-OFUki for ; Tue, 2 Jul 2013 22:34:32 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id BACB021F8FDC for ; Tue, 2 Jul 2013 22:34:32 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hv10so3355606vcb.36 for ; Tue, 02 Jul 2013 22:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=42bdCwWi83LMadomXh+RLfjZoprbYsTb0llgwP+L01U=; b=WjoBxEkCCXRKpFHFjYyxiQ12QSQ76L+bsSKL0fx1YDACoJsIrhanz2aKMBWWM9gvNu sQaPy0TMgE19DNKOMv8HOaxY1QZ9C0QEFX9JKasJ2j3KyWPRWyK4LJidMkJ4xKt5RjHT pZPzWcfdfb8MqJF+dKIiDSRhtMEt+lfrGLVBk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=42bdCwWi83LMadomXh+RLfjZoprbYsTb0llgwP+L01U=; b=dUFamHvcdHlzIfJdRu+M5MMQJaxAQZysccbB2pQllKQ96o8TUcF7nIsvdzMdTU8Xh8 nGAU6PfKBnNgCdKb2lNBFeGtWUTMkuWC+8hLD6qGFmyCa5DvDRMsyRKM2GbaiZ//Gkl3 xleqL2GRfsmKUo5ri6AogAtiVZWMhKhFudR7wRRF8CqSAv0aK5/535Pt7yblj25jXdRt /3ETU5COg2NJoMq30saJsWbkFXvgg6bKmqJhugs9xDduvrGzXJuVYB5I+bPiFrFozqX9 iQoux7g6Bmb2HRm/hkrOGSEZIdCyA7M7zzQtV17H8USjJpqjmh801gG9vHfa00MTRBHC npsg== MIME-Version: 1.0 X-Received: by 10.52.70.66 with SMTP id k2mr10408318vdu.17.1372829671769; Tue, 02 Jul 2013 22:34:31 -0700 (PDT) Received: by 10.221.55.70 with HTTP; Tue, 2 Jul 2013 22:34:31 -0700 (PDT) In-Reply-To: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> References: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> Date: Tue, 2 Jul 2013 22:34:31 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnB4a0V7vNpI2FG52y/hEz6OAiXEsvhptipYQ1hf5MTC+H6q44IYBD8pdoZPUV+9lNfLb4G Subject: [manet] Fwd: Draft submission deadlines change 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, 03 Jul 2013 05:34:33 -0000 FYI ---------- Forwarded message ---------- From: IETF Chair Date: Tue, Jul 2, 2013 at 10:17 PM Subject: Draft submission deadlines change To: IETF Announcement List Please note that for IETF 87, there is only one deadline for draft submission: Monday 15th July. Previously, there had been two different deadlines, one for -00 and another one for other versions. The IESG has decided to experiment with just one deadline for now to simplify the set of deadlines and enable easier submission of new drafts. While we realise that the change comes near the deadline, we hope that you find the extra time useful. But please do note that working group chairs will continue to make smart decisions about what topics are worthwhile for discussing in a session in the upcoming meeting, and will also set their agendas in a timely manner and create deadlines for their working groups that must be adhered to. The earlier new drafts are submitted, the more time there is to talk about them on the mailing lists and consider them for the session agendas. This is particularly important for BoFs. Jari Arkko for the IESG From wwwrun@rfc-editor.org Thu Jul 4 09:29: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 B7B0021F9F37 for ; Thu, 4 Jul 2013 09:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[AWL=0.602, 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 PdDtJxxEXvZh for ; Thu, 4 Jul 2013 09:29:50 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 07CCF21F9E4D for ; Thu, 4 Jul 2013 09:29:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D2014B1E003; Thu, 4 Jul 2013 09:27:58 -0700 (PDT) To: T.Clausen@computer.org, chris.dearlove@baesystems.com, jdean@itd.nrl.navy.mil, stbryant@cisco.com, adrian@olddog.co.uk, sratliff@cisco.com, macker@itd.nrl.navy.mil From: RFC Errata System Message-Id: <20130704162758.D2014B1E003@rfc-editor.org> Date: Thu, 4 Jul 2013 09:27:58 -0700 (PDT) X-Mailman-Approved-At: Thu, 04 Jul 2013 09:36:58 -0700 Cc: chris.dearlove@baesystems.com, manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Technical Errata Reported] RFC6130 (3677) 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, 04 Jul 2013 16:29:50 -0000 The following errata report has been submitted for RFC6130, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6130&eid=3677 -------------------------------------- Type: Technical Reported by: Christopher Dearlove Section: App. B p. 65 Original Text ------------- o L_HEARD_time MUST NOT be greater than L_time. Corrected Text -------------- o L_HEARD_time MUST NOT be greater than L_time, unless L_lost = true. Notes ----- The case currently indicated as a constraint failure, but not by the relaxed constraint, can occur - and correctly - in normal operation of the protocol. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6130 (draft-ietf-manet-nhdp-15) -------------------------------------- Title : Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) Publication Date : April 2011 Author(s) : T. Clausen, C. Dearlove, J. Dean Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From abdussalambaryun@gmail.com Sat Jul 6 19:56:53 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 CAACD21F9DCA for ; Sat, 6 Jul 2013 19:56:53 -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 UtFLgkcpgjRR for ; Sat, 6 Jul 2013 19:56:53 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 20BB121F9DC7 for ; Sat, 6 Jul 2013 19:56:53 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so2998374pdj.36 for ; Sat, 06 Jul 2013 19:56:52 -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=HOHu3EbrCmYL24OOEEoJTPZAjTRK0qJs33KQnVAVITU=; b=lZ1npvuMIQPeywobxws+OiC7X/xGYzb37mkp7N4hKJ1zxswldStGen5VS0jy1eBigg 5yr/LHWd5hHJWkcLdHVI9BwFKbeTNoM35uuhMi4xZfnX3fzAEkden6fmdiFAG0aSw/+E 14Cj2I50NtuTB1q3hL9xcxlOQXoxoxHr36RELHKrgvUP8K+48UhuHG3wHhn8o0A4Xrgt pPRtDrP8oA6pTpg0FBKzH9zWy8e09DkWjePcHBml2BDowu3UAVg7nIgjM2cCnd415rWD PlyEYCpF3/SNCnyUQHtk7MAyxkkk+5rKzNMdtLg5NXAgo5lta8huf+7sdKrpUywGjw1S /wnQ== MIME-Version: 1.0 X-Received: by 10.66.148.41 with SMTP id tp9mr17515412pab.40.1373165812633; Sat, 06 Jul 2013 19:56:52 -0700 (PDT) Received: by 10.68.250.133 with HTTP; Sat, 6 Jul 2013 19:56:52 -0700 (PDT) In-Reply-To: <20130704162758.D2014B1E003@rfc-editor.org> References: <20130704162758.D2014B1E003@rfc-editor.org> Date: Sun, 7 Jul 2013 04:56:52 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] [Technical Errata Reported] RFC6130 (3677) 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, 07 Jul 2013 02:56:53 -0000 IMHO for principles of knowledge, the L_HEARD_time cannot be greater than L_time when link is lost, only if the protocol is doing something different with its information. If we lose link then we lost to hear. The errata change can mean; o L_HEARD_time MAY be greater than L_time while L_lost equals true. Not true hearing while lost the link, but you mention below that can happen from the protocol. How many times that can occur per router or per network? if it does happen then there is something wrong, then the information in L-HEARD_time cannot be trusted because the link may be lost. However, I prefer to suggest:- AB> amend errata> RFC6130> section 14.3> If L_status != PENDING, and L_quality < HYST_REJECT, then the corresponding Link Tuple is modified by: 1. If L_lost = false, then: o L_lost := true; o L_time := min(L_time, current time + L_HOLD_TIME). o L_HEARD := L_time. AB On 7/4/13, RFC Errata System wrote: > The following errata report has been submitted for RFC6130, > "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6130&eid=3677 > > -------------------------------------- > Type: Technical > Reported by: Christopher Dearlove > > Section: App. B p. 65 > > Original Text > ------------- > o L_HEARD_time MUST NOT be greater than L_time. > > > Corrected Text > -------------- > o L_HEARD_time MUST NOT be greater than L_time, unless L_lost = true. > > > Notes > ----- > The case currently indicated as a constraint failure, but not by the relaxed > constraint, can occur - and correctly - in normal operation of the > protocol. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6130 (draft-ietf-manet-nhdp-15) > -------------------------------------- > Title : Mobile Ad Hoc Network (MANET) Neighborhood Discovery > Protocol (NHDP) > Publication Date : April 2011 > Author(s) : T. Clausen, C. Dearlove, J. Dean > Category : PROPOSED STANDARD > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From christopher.dearlove@googlemail.com Sat Jul 6 23:32: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 A0D9221F9E3D for ; Sat, 6 Jul 2013 23:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 uIvGrIg6bUpO for ; Sat, 6 Jul 2013 23:32:02 -0700 (PDT) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id BE16721F9E3A for ; Sat, 6 Jul 2013 23:32:00 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id d49so2168440eek.9 for ; Sat, 06 Jul 2013 23:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DAvzbaNa3yBXpn5RIk1mrbjTQwGrSC0O1DNi1MMbRzc=; b=HKuAwWHj3vfT9Re5joplEua/6LD0WDzS3nqXlyUhOZ80oDTeaGVHF0O3EH4vn34ZfP RgenXNv8slgrg0omfBUcTFrKq/ZcVy1hghlHkUFQyKTCFKUTJHHy8awej4uHgzOKPjJ1 +F6H9UoXDqO9FuoHtdppryQFQO58ArPe9JD2h96ffWoGk+9oEqO6mbc7Tw9XF3A1EjvB oX9uisKDfS8rs6Jo+8c35+zhcW7UgvacNsyJ3dMzqQzFMZALkpkYJ4NcvsAoeFgxV88F 2RRILjHrY1IViU0Ci/b+oXEcp85kNSy1A0gBN2b9pGvV5zZmBksir3pHc5DLPd8/wajt qX5Q== X-Received: by 10.15.43.11 with SMTP id w11mr10242960eev.27.1373178719885; Sat, 06 Jul 2013 23:31:59 -0700 (PDT) Received: from [192.168.254.1] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id e44sm30023704eeh.11.2013.07.06.23.31.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 23:31:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Christopher Dearlove In-Reply-To: Date: Sun, 7 Jul 2013 07:31:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4F6CE312-BA88-4269-9C3B-BB7C6A28B53E@gmail.com> References: <20130704162758.D2014B1E003@rfc-editor.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1283) Cc: manet Subject: Re: [manet] [Technical Errata Reported] RFC6130 (3677) 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, 07 Jul 2013 06:32:03 -0000 I'm afraid you have demonstrated that you don't understand what's going = on. The point about the state in question is that L_lost is true because the = link quality is poor. But it might get better again, and if it does we = need to have retained the information about what state is then is. So = L_HEARD_time is retained for possible restoration, but actually isn't = being used. Because of that, it can be greater than L_time, because we = keep updating L_HEAD_time in case of restoration, but we don't keep = updating L_time, because we only want to advertise the link as lost for = a finite time. It's there and it works. It is just overlooked in the constraints. Your = suggestion would break this. Furthermore, modifying the constraints is painless. They only come into = play when the internal state is modified by an external process. Mostly = they can be ignored. But modifying the actual protocol is not painless. = It is also not just unnecessary, but wrong. I have implemented RFC 6130, as well as being an author. Have you? This counter-proposal must be rejected. On 7 Jul 2013, at 03:56, Abdussalam Baryun wrote: > IMHO for principles of knowledge, the L_HEARD_time cannot be greater > than L_time when link is lost, only if the protocol is doing something > different with its information. If we lose link then we lost to hear. >=20 > The errata change can mean; > o L_HEARD_time MAY be greater than L_time while L_lost equals true. >=20 > Not true hearing while lost the link, but you mention below that can > happen from the protocol. How many times that can occur per router or > per network? if it does happen then there is something wrong, then the > information in L-HEARD_time cannot be trusted because the link may be > lost. However, I prefer to suggest:- >=20 > AB> amend errata> RFC6130> section 14.3> > If L_status !=3D PENDING, and L_quality < HYST_REJECT, then the > corresponding Link Tuple is modified by: > 1. If L_lost =3D false, then: > o L_lost :=3D true; > o L_time :=3D min(L_time, current time + L_HOLD_TIME). > o L_HEARD :=3D L_time. >=20 >=20 > AB >=20 > On 7/4/13, RFC Errata System wrote: >> The following errata report has been submitted for RFC6130, >> "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol = (NHDP)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6130&eid=3D3677 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Christopher Dearlove >>=20 >> Section: App. B p. 65 >>=20 >> Original Text >> ------------- >> o L_HEARD_time MUST NOT be greater than L_time. >>=20 >>=20 >> Corrected Text >> -------------- >> o L_HEARD_time MUST NOT be greater than L_time, unless L_lost =3D = true. >>=20 >>=20 >> Notes >> ----- >> The case currently indicated as a constraint failure, but not by the = relaxed >> constraint, can occur - and correctly - in normal operation of the >> protocol. >>=20 >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >>=20 >> -------------------------------------- >> RFC6130 (draft-ietf-manet-nhdp-15) >> -------------------------------------- >> Title : Mobile Ad Hoc Network (MANET) Neighborhood = Discovery >> Protocol (NHDP) >> Publication Date : April 2011 >> Author(s) : T. Clausen, C. Dearlove, J. Dean >> Category : PROPOSED STANDARD >> Source : Mobile Ad-hoc Networks >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> 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 l.lenzini@iet.unipi.it Sun Jul 7 00:34:06 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 B48CE21F9CBC for ; Sun, 7 Jul 2013 00:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 k-R-GyuFkGdg for ; Sun, 7 Jul 2013 00:34:01 -0700 (PDT) Received: from smtp.ing.unipi.it (smtp.ing.unipi.it [131.114.28.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB9721F9E6E for ; Sun, 7 Jul 2013 00:33:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ing.unipi.it (Postfix) with ESMTP id 4E4697D47F; Sun, 7 Jul 2013 09:33:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at smtp.ing.unipi.it Received: from smtp.ing.unipi.it ([127.0.0.1]) by localhost (smtp.ing.unipi.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ukf-2eimtWa0; Sun, 7 Jul 2013 09:33:57 +0200 (CEST) Received: from VAIO (host212-62-dynamic.52-82-r.retail.telecomitalia.it [82.52.62.212]) (Authenticated sender: a008436) by smtp.ing.unipi.it (Postfix) with ESMTPSA id C66497D469; Sun, 7 Jul 2013 09:33:56 +0200 (CEST) From: "Luciano Lenzini" To: Date: Sun, 7 Jul 2013 09:33:53 +0200 Message-ID: <000801ce7ae4$56c33950$0449abf0$@iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01CE7AF5.1A4E5340" X-Mailer: Microsoft Outlook 14.0 X-Virus-Scanned: Debian amavisd-new at mx1.ing.unipi.it Thread-Index: AQFg/YZMRC3gdeOoOi044Ci09+F4Lg== Content-Language: it Subject: [manet] PORTOLAN: A Mobile Crowdsourcing Measurement System 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, 07 Jul 2013 07:34:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0009_01CE7AF5.1A4E5340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, The University of Pisa and IIT, an Institute of the Italian National Research Council, have developed a mobile crowdsourcing-based system, named PORTOLAN which uses smartphones as mobile monitors probing the Internet and reporting results to a central server located in Pisa. The aim of PORTOLAN is to enhance the current topology of the Internet at the Autonomous System level of abstraction - all with the contribution of volunteers. The PORTOLAN component that runs on smartphones is now available as an app for the Android platform. It can be downloaded by users from Google play ( https://play.google.com/store/apps/details?id=it.unipi.iet.portolan.tracerou te). PORTOLAN works in the background, it is designed not to interfere in any way with users' activities and does not affect the smartphone's overall performance. In order to motivate users to contribute to the PORTOLAN project, we have added several services, which include diagnostic network tools (such as Ping, Paris Traceroute with Multipath Detection Algorithm, Maximum Throughput achievable along a path, etc.) and coverage measurement tools. All the tools are totally under the user's control. Data collected by these tools are stored in our servers, in a completely anonymous way. For details see http://portolan.iet.unipi.it/. The success of our experiment depends upon the number of users who join the experiment. But to get people to download the app, we really need to raise as much awareness as possible regarding the PORTOLAN itself. So I would like to ask you if it would be possible for you to forward this message to your colleagues, students and anyone else who you think might be interested. Many thanks in advance for your cooperation. All the best, Luciano TECHNICAL NOTE: In PORTOLAN, each smartphone issues at max 200 traceroutes per day, which means a peak traffic rate never higher than 1 KB/s and an average traffic rate never higher than 2 MB/day. The impact of these activities on the battery consumption is negligible. Signal coverage measurements are completely costless in terms of energy or bandwidth, as the PORTOLAN app passively collects signal strength samples using GPS positions generated by other apps. You have to activate the GPS yourself if you want a coverage map along your route. Given that your route could be up to 50 km or more, then you will obviously use up quite a bit of your battery power. So if you are travelling, then connect your smartphone to a powersource in your car or in the train. In any case, if the battery level goes under 40%, PORTOLAN is automatically suspended. -------------------------------------------------------------- Prof. Luciano Lenzini Department of Information Engineering University of Pisa, Italy e-mail: l.lenzini@iet.unipi.it http://www.iet.unipi.it/~lenzini ------=_NextPart_000_0009_01CE7AF5.1A4E5340 Content-Type: text/html; boundary="----=_NextPart_000_0001_01CE7A7A.0929DBA0"; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,
The University of Pisa and IIT, an Institute = of the Italian National Research Council, have developed a mobile = crowdsourcing-based system, named PORTOLAN which uses smartphones as = mobile monitors probing the Internet and reporting results to a central = server located in Pisa. The aim of PORTOLAN is to enhance the current = topology of the Internet at the Autonomous System level of abstraction - = all with the contribution of volunteers.

The PORTOLAN component = that runs on smartphones is now available as an app for the Android = platform. It can be downloaded by users from Google play (https://play.google.com/store/apps/details?id=3Dit.unipi.iet= .portolan.traceroute).
PORTOLAN works = in the background, it is designed not to interfere in any way with = users' activities and does not affect the smartphone’s overall = performance. In order to motivate users to contribute to the PORTOLAN = project, we have added several services, which include diagnostic = network tools (such as Ping, Paris Traceroute with Multipath Detection = Algorithm, Maximum Throughput achievable along a path, etc.) and = coverage measurement tools. All the tools are totally under the user's = control. Data collected by these tools are stored in our servers, in a = completely anonymous way. For details see http://portolan.iet.unipi.it/.

The success of our experiment depends upon the = number of users who join the experiment. But to get people to download = the app, we really need to raise as much awareness as possible regarding = the PORTOLAN itself.
So I would like to ask you if it would be = possible for you to forward this message to your colleagues, students = and anyone else who you think might be interested.

Many thanks in = advance for your cooperation.

All the = best,
Luciano

TECHNICAL NOTE: In PORTOLAN, each smartphone = issues at max 200 traceroutes per day, which means a peak traffic rate = never higher than 1 KB/s and an average traffic rate never higher than 2 = MB/day. The impact of these activities on the battery consumption is = negligible. Signal coverage measurements are completely costless in = terms of energy or bandwidth, as the PORTOLAN app passively collects = signal strength samples using GPS positions generated by other apps. You = have to activate the GPS yourself if you want a coverage map along your = route. Given that your route could be up to 50 km or more, then you will = obviously use up quite a bit of your battery power. So if you are = travelling, then connect your smartphone to a powersource in your car or = in the train. In any case, if the battery level goes under 40%, PORTOLAN = is automatically suspended.<= span lang=3DEN-US>

 

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

Prof. Luciano = Lenzini

Department of = Information Engineering

University = of Pisa, Italy

e-mail: l.lenzini@iet.unipi.it

http://www.iet.unipi.it/~lenzin= i

 <= /p>

 

------=_NextPart_000_0009_01CE7AF5.1A4E5340-- From chris.dearlove@baesystems.com Mon Jul 8 02:09:07 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 C287821F8319 for ; Mon, 8 Jul 2013 02:09:06 -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 1FQ6ijkVpohY for ; Mon, 8 Jul 2013 02:09:02 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id E692D11E81AB for ; Mon, 8 Jul 2013 02:08:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,1019,1363132800"; d="scan'208";a="298229742" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 08 Jul 2013 10:08:36 +0100 X-IronPort-AV: E=Sophos;i="4.87,1019,1363132800"; d="scan'208";a="21369148" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 08 Jul 2013 10:08:36 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.180]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Mon, 8 Jul 2013 10:08:36 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , manet Thread-Topic: [manet] [Technical Errata Reported] RFC6130 (3677) Thread-Index: AQHOeNO33r4tWCgDo0GWB3Iy4lRiF5lYeNgAgAIHVqA= Date: Mon, 8 Jul 2013 09:08:34 +0000 Message-ID: References: <20130704162758.D2014B1E003@rfc-editor.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] [Technical Errata Reported] RFC6130 (3677) 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, 08 Jul 2013 09:09:09 -0000 My previously posted comment doesn't seem to have arrived here. In short - The erratum is right. The proposal; below is wrong, both in its original = assumption and suggested resolution. It must be firmly rejected. - This arises from behaviour in the L_lost =3D true state, which is doing t= wo things, recording the state as lost for a fixed period, but also retaini= ng what the state is should the link quality recover. - The erratum changes only the constraints, and to relax them. This is a sa= fe change, it will not impact on any implementation. (The constraints are f= ormally about what is allowed to be done by another process. Fundamentally = they are class invariants of the information repository. The erratum essent= ially makes them match those invariants - which are also good for implement= ation testing - correctly.) That would not be true of anything changing sec= tion 14. I would recommend to the poster that if he has a case that doesn't seem rig= ht, the sensible reaction would be something like "Allowing L_HEARD_time to= be greater than L_time appears surprising, could you explain that?" rather= than jumping in with a proposal that demonstrates a lack of understanding. (I did incidentally work through a detailed case and checked with a couple = of other NHDP/OLSrv2 authors I hadn't missed something before submitting th= is. Or in other words I followed a version of my own advice above.) -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 07 July 2013 03:57 To: manet Subject: Re: [manet] [Technical Errata Reported] RFC6130 (3677) ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- IMHO for principles of knowledge, the L_HEARD_time cannot be greater than L_time when link is lost, only if the protocol is doing something different with its information. If we lose link then we lost to hear. The errata change can mean; o L_HEARD_time MAY be greater than L_time while L_lost equals true. Not true hearing while lost the link, but you mention below that can happen from the protocol. How many times that can occur per router or per network? if it does happen then there is something wrong, then the information in L-HEARD_time cannot be trusted because the link may be lost. However, I prefer to suggest:- AB> amend errata> RFC6130> section 14.3> If L_status !=3D PENDING, and L_quality < HYST_REJECT, then the corresponding Link Tuple is modified by: 1. If L_lost =3D false, then: o L_lost :=3D true; o L_time :=3D min(L_time, current time + L_HOLD_TIME). o L_HEARD :=3D L_time. AB On 7/4/13, RFC Errata System wrote: > The following errata report has been submitted for RFC6130, > "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6130&eid=3D3677 > > -------------------------------------- > Type: Technical > Reported by: Christopher Dearlove > > Section: App. B p. 65 > > Original Text > ------------- > o L_HEARD_time MUST NOT be greater than L_time. > > > Corrected Text > -------------- > o L_HEARD_time MUST NOT be greater than L_time, unless L_lost =3D true. > > > Notes > ----- > The case currently indicated as a constraint failure, but not by the rela= xed > constraint, can occur - and correctly - in normal operation of the > protocol. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6130 (draft-ietf-manet-nhdp-15) > -------------------------------------- > Title : Mobile Ad Hoc Network (MANET) Neighborhood Discovery > Protocol (NHDP) > Publication Date : April 2011 > Author(s) : T. Clausen, C. Dearlove, J. Dean > Category : PROPOSED STANDARD > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > 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 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Mon Jul 8 08:05:28 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 F3A3D21F8F4F for ; Mon, 8 Jul 2013 08:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyySFFQVEUip for ; Mon, 8 Jul 2013 08:05:23 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id A4FE521F8B04 for ; Mon, 8 Jul 2013 08:05:22 -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 1UwD0D-0006EJ-EZ for manet@ietf.org; Mon, 08 Jul 2013 17:05:21 +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 1UwD0D-0004cA-By for manet@ietf.org; Mon, 08 Jul 2013 17:05:21 +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; Mon, 8 Jul 2013 17:05:20 +0200 Message-ID: <51DAD52C.3020504@fkie.fraunhofer.de> Date: Mon, 8 Jul 2013 17:05:16 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <51BEEAB8.9080002@fkie.fraunhofer.de> <51C809F5.1030301@fkie.fraunhofer.de> In-Reply-To: <51C809F5.1030301@fkie.fraunhofer.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000006010400010600090404" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17470/Mon Jul 8 12:42:51 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: fb1b735a18614dc364f28f1a7f4db999 Subject: [manet] ETT draft -02 released 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, 08 Jul 2013 15:05:28 -0000 --------------ms000006010400010600090404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I just submitted draft -02 to the IETF. Thank you for all the reviews=20 that helped to improve the draft. http://www.ietf.org/id/draft-rogge-baccelli-olsrv2-ett-metric-02.txt Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms000006010400010600090404 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 Fw0xMzA3MDgxNTA1MjBaMCMGCSqGSIb3DQEJBDEWBBS1olsIyLJE1Fu4CmlcnjDkmyjpcDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAN5KWtm+lzpAkEAcnjjYWArHAwYWFcWt8BBst1W7HIugp DUZnS9ZZZbCKIqAo8UF1E0AbDv6Lx0vMGjoXie8vuYciL/TB7+QtJ6PtQAZXKQ/f8Ofwp152 56us6iWk8LYm6gU6z4wZsBgTbqHsP+6C3GPp/Vj1ZXxTg4+I+H4FqT5Ocrnmt+koe4DGzy0X Gso4UbYGiKMdq8T/ozMsVfb0f9DfDhkCTGzc5WmsBWtoDlkQKZ2c+lwDu76uiESWwtjGA67i I6yjJzIPcUd1Iv0SWkWT3t8Q/tQdD96dYO1msq4Td1JnJL9bQ4roipxHEQ7uPbPPNltAYTn7 F14EL2PV+wAAAAAAAA== --------------ms000006010400010600090404-- From henning.rogge@fkie.fraunhofer.de Mon Jul 8 22:56: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 9C9A721F9F37 for ; Mon, 8 Jul 2013 22:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCwXwxG5H3ZX for ; Mon, 8 Jul 2013 22:56:23 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 311D321F9F1B for ; Mon, 8 Jul 2013 22:56:22 -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 1UwQuS-00037S-Sg for manet@ietf.org; Tue, 09 Jul 2013 07:56:20 +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 1UwQuS-0004Yz-Q6 for manet@ietf.org; Tue, 09 Jul 2013 07:56:20 +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, 9 Jul 2013 07:56:20 +0200 Message-ID: <51DBA603.4080306@fkie.fraunhofer.de> Date: Tue, 9 Jul 2013 07:56:19 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: References: <51BEEAB8.9080002@fkie.fraunhofer.de> <51C809F5.1030301@fkie.fraunhofer.de> <51DAD52C.3020504@fkie.fraunhofer.de> In-Reply-To: <51DAD52C.3020504@fkie.fraunhofer.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050501020508010505040706" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17474/Tue Jul 9 06:41:00 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 306d475cb774b7f15678e7079d6bc338 Subject: Re: [manet] ETT draft -02 released 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, 09 Jul 2013 05:56:30 -0000 --------------ms050501020508010505040706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Am 08.07.2013 17:05, schrieb Henning Rogge: > Hi, > > I just submitted draft -02 to the IETF. Thank you for all the reviews > that helped to improve the draft. > > http://www.ietf.org/id/draft-rogge-baccelli-olsrv2-ett-metric-02.txt My Co-Author just notified me that I forgot to add Stan Ratliff to the=20 Acknowledgement section of our draft. We will fix this in draft -03,=20 sorry for forgetting it. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms050501020508010505040706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Kryptografische Unterschrift MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA3MDkwNTU2MTlaMCMGCSqGSIb3DQEJBDEWBBTme3z+lYaKjGuxfdMOnB/1NV61+TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEArZSB7YS/ubNaiXXEzzzf7L2Nq6TauvOt4GTE3l79vlGs 5ncCE507WtgL7gCL52iMfGcMUzk4HXLJcIOx2TXL+HOqUyDmIwD7emi410xxm3uqGVIwpP+1 7avQOmKUgUA32SpxpmyXwuqxbStMSF/IRkY/KC81+NbnBj4n/9Jdf4InXDjWQFw6I5Y863um lZlZwcBZfrMf3PycBWqDtG3xC+3K5+2mY7jq2Et1hOTtQKUaQBJ5epWsmn+tMUccMpDnL4gA UQEw7z6cD0xxckHXfGP1PfHmi+sh0pqmfKSNF2SQWLqm9T5DyVMuBeSsPs4v6WTvRhyAjSpn Ni3Zx1djegAAAAAAAA== --------------ms050501020508010505040706-- From valerio.arnaboldi@iit.cnr.it Wed Jul 10 04:46:06 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 69D3321F9F17 for ; Wed, 10 Jul 2013 04:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.222 X-Spam-Level: X-Spam-Status: No, score=0.222 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFk9JEriBPXC for ; Wed, 10 Jul 2013 04:45:59 -0700 (PDT) Received: from mxbk.iit.cnr.it (mxbk.iit.cnr.it [146.48.98.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8378921F9B79 for ; Wed, 10 Jul 2013 04:45:58 -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 064C7C0021 for ; Wed, 10 Jul 2013 13:45:46 +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: <20130710114559.8378921F9B79@ietfa.amsl.com> Date: Wed, 10 Jul 2013 04:45:58 -0700 (PDT) Subject: [manet] IFP/IEEE SustainIT 2013: Submission deadline for INDUSTRIAL TRACK papers EXTENDED to July 20, 2013 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 11:46:06 -0000 Please note that the manuscript submission deadline is extended to JULY 20, 2013 3 ------------------------------------------------------------------- *** Our apologies if you receive multiple copies of this e-mail *** ------------------------------------------------------------------- CALL FOR INDUSTRIAL TRACK PAPERS The Third IFIP Conference on Sustainable Internet and ICT for Sustainability (SustainIT 2013) http://www.dicgim.unipa.it/networks/sustainit2013 October 30-31, 2013 Palermo, Sicily, Italy - Technically sponsored by the IFIP TC6 WG 6.3 (Performance of Communication Systems) - Technically co-sponsored by IEEE Computer Society - In cooperation with IEEE TSGCC (Technical Subcommittee on Green Communications and Computing) - Supported by EINS: The Network of Excellence in Internet Science ------------------------------------------------------------------------ **** Paper Submission Deadline (EXTENDED!)--- JULY 20, 2013 **** ------------------------------------------------------------------------ SUSTAINIT 2013 will feature an industrial track providing a forum for researchers and developers from academia, industry, and government to interact and share latest research results achieved by national and international projects on the areas of Sustainable Internet and ICT for Sustainability. Towards this goal, SUSTAINIT seeks participations from all three entities. The industrial track offers the opportunity to present the latest findings by ongoing projects or the overview of recently approved projects. Industrial track paper submissions are welcome in all aspects of Sustainable Internet and ICT for Sustainability, including algorithms, protocols, applications, hardware and tools, new research prototypes, testbeds, etc. Authors are asked to submit a paper of up to 5 pages (including figures, tables, and references) (one additional page is allowed upon a fee payment). The paper should highlight the main contributions and describe the details of the project, with a focus on the interaction with the audience and highlighting the environmental sustainability benefits either achieved or targeted. Please refer to the Submission Instructions below for more details. IMPORTANT DATES ------------------------------------------------------------------------ - Industrial track paper submission deadline: July 20, 2013 - Acceptance/Reject notification: August 5, 2013 - Camera-ready version due: August 15, 2013 INDUSTRIAL TRACK PAPER SUBMISSION ------------------------------------------------------------------------ Papers must be submitted electronically in PDF format through EDAS (http://edas.info/newPaper.php?c=14317). Manuscripts must be formatted in accordance with the IEEE Computer Society author guidelines (http://edas.info/newPaper.php?c=14317). Industrial track papers must be limited to 5 pages (one additional page is allowed upon a fee payment), single spacing, double column, and must strictly adhere to the template format. Detailed instructions for manuscript preparation and submission are available on the conference website (http://www.dicgim.unipa.it/networks/sustainit2013/submission.html). FOR MORE INFORMATION ------------------------------------------------------------------------ For questions about the industrial track paper submission and review process, please contact the SUSTAINIT 2013 Industrial Track Co-Chairs: Maria Cristina Bueti, International Telecommunication Union (ITU) - cristina (dot) bueti (at) itu (dot) int Luca Valcarenghi, Scuola Superiore Sant'Anna, luca (dot) valcarenghi (at) sssup (dot) it From chris.dearlove@baesystems.com Fri Jul 12 10:19: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 7050721E80AB for ; Fri, 12 Jul 2013 10:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.547 X-Spam-Level: X-Spam-Status: No, score=-9.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKpuwRvcOtSV for ; Fri, 12 Jul 2013 10:19:09 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 989A021E80A7 for ; Fri, 12 Jul 2013 10:19:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,654,1367967600"; d="scan'208";a="354929076" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 12 Jul 2013 18:18:59 +0100 X-IronPort-AV: E=Sophos;i="4.89,654,1367967600"; d="scan'208";a="21585733" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 12 Jul 2013 18:18:59 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.180]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 18:18:59 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: New OLSRv2 and NHDP related IDs Thread-Index: Ac5/Io4DKdLmeoNQSSmTAM2hML6qnA== Date: Fri, 12 Jul 2013 17:18:58 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: [manet] New OLSRv2 and NHDP related IDs 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, 12 Jul 2013 17:19:13 -0000 We have submitted three IDs today, one is a -01 revision of one submitted l= ast Monday, two are -00 versions that are a -00 submitted last Monday divid= ed into two documents. One describes a multitopology extension to OLSRv2. That a multitopology ext= ension was possible was clear from before metrics were added to OLSRv2. How= ever we decided to walk before we ran there. We have suggested this as expe= rimental, as we currently have no experience with it, but of course Standar= d Track might be possible in the future. One key decision was to make MT-OLSRv2 interoperable with basic OLSrv2. The= re a couple of nits there, and the TLV extensions draft hammers those out. = As a significant bonus, this allows a simplification and/or efficiency savi= ng in using multivalue TLVs in NHDP and OLSrv2. The rmpr-optimisation draft (spelling out routing made the name too long) l= egitimises an optimisation described in the metric rationale draft. (It is = unnecessary to make it work, and interoperate, it just needed to make it te= chnically "legal"). Ulrich - we would like to request a slot at the Berlin meeting to describe = these. (Exactly who to present is TBD.) -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Fri Jul 12 19:44: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 B693C21E8063 for ; Fri, 12 Jul 2013 19:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.040, 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 PktwXygFnxOE for ; Fri, 12 Jul 2013 19:44:00 -0700 (PDT) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E017011E80DC for ; Fri, 12 Jul 2013 19:43:59 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id e15so2059371vbg.3 for ; Fri, 12 Jul 2013 19:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YqRUW6rAl03zRgsEyappkaDDFkrBa5XGPcOhrTOVNS8=; b=lEvSxzXucip4tGWWxjhnjfU6HV9JUeaq65rbHlu9cUa/fYaaK1tfFcyGcrmAIxwWR3 TvB4jLfAsNTLV8xncwSC4cqvB7y3bBGLZCBM2QRnhQaSkebm6bRRQFSrwyonHJ7vec7T pcG7JqHQoZciM8o5/3ylmcl7lrUCCLQHZPIhA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=YqRUW6rAl03zRgsEyappkaDDFkrBa5XGPcOhrTOVNS8=; b=NfhR/KJu1O3oOIeAfMCvsvfNPsPMxutDzke8X5bf9fqUwNelANWpRofaMRJEviZKqZ UxSHHQ57ndtgpPA4UL2TKFJqCwA2Z12fOR/BU6ae/Er47qpk/MwiulcERr2mbbUN1hwk QdHUOdjr5zdg6ZoY6CwGNGyrAYSoungZE03H75eJhAcgc0xYp/7Wk9KReZ0HoxsI74AU TajdDCNTtCEI35x4XcyCubH3DkeYF1xtmAIvwFtWLW1sxBARqtyVStlpfdj62IQ+K7lK vSeERrxSsTjx1745Y93/5yQjrRMvjVTC+5X1CzkXwKmrZtTgsD11mmBmXAkcDknfFGyB 3zcQ== MIME-Version: 1.0 X-Received: by 10.52.94.6 with SMTP id cy6mr4672747vdb.108.1373683437765; Fri, 12 Jul 2013 19:43:57 -0700 (PDT) Received: by 10.221.55.70 with HTTP; Fri, 12 Jul 2013 19:43:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jul 2013 19:43:57 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn05i62VAPLVLuKn0p0lE00GW5Ls16QVAHwgYNp9G/GG+PQhr5nHuu9FB3mZowXWewGN0wx Cc: "manet@ietf.org" , "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] New OLSRv2 and NHDP related IDs 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, 13 Jul 2013 02:44:00 -0000 Chris, I have updated the agenda: http://www.ietf.org/proceedings/87/agenda/agenda-87-manet Regards Ulrich On Fri, Jul 12, 2013 at 10:18 AM, Dearlove, Christopher (UK) wrote: > We have submitted three IDs today, one is a -01 revision of one submitted= last Monday, two are -00 versions that are a -00 submitted last Monday div= ided into two documents. > > One describes a multitopology extension to OLSRv2. That a multitopology e= xtension was possible was clear from before metrics were added to OLSRv2. H= owever we decided to walk before we ran there. We have suggested this as ex= perimental, as we currently have no experience with it, but of course Stand= ard Track might be possible in the future. > > One key decision was to make MT-OLSRv2 interoperable with basic OLSrv2. T= here a couple of nits there, and the TLV extensions draft hammers those out= . As a significant bonus, this allows a simplification and/or efficiency sa= ving in using multivalue TLVs in NHDP and OLSrv2. > > The rmpr-optimisation draft (spelling out routing made the name too long)= legitimises an optimisation described in the metric rationale draft. (It i= s unnecessary to make it work, and interoperate, it just needed to make it = technically "legal"). > > Ulrich - we would like to request a slot at the Berlin meeting to describ= e these. (Exactly who to present is TBD.) > > -- > 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 > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > From abdussalambaryun@gmail.com Sat Jul 13 12:06:40 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 5139A21F9CCA for ; Sat, 13 Jul 2013 12:06:40 -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 1V8R0N1ms60v for ; Sat, 13 Jul 2013 12:06:39 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DE7BC21F9CC1 for ; Sat, 13 Jul 2013 12:06:39 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so9916803pad.30 for ; Sat, 13 Jul 2013 12:06:39 -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=0sO8GcSW1ha9Eymb8psIAVRLQY6LsL94fbd0imDJAQI=; b=jL2u2VzYU2038Z1GYDOkkMoOa1W+84gDn3mBhjWhe2aLT6/xyICzZnmn1xhrv+F+fc NewiKRi0EDs+PkTMIhUwnew9WyVPjmcLWRo5fz+HKfj+1Ake1q1H8TARxrmuDTBcqhAF wK/LwcIn5TeBInRDBkSMFRoOGL+9f5gDAtsapHekEtVzkueRTWoNZ74QCcBP+DdLhyvt rxdHBydf80NtAZ0SQAHg4YFZYUcPYJ8YCsHSfdJD1OTXMPgS7HZWckiqa7BI/uCR0Uts z76hH6ADbfhIURYBbEEDr4mFb812bSyeGnnKfLM5k3ge5f9K/5/hGon4dhkP06SKz0ua QFog== MIME-Version: 1.0 X-Received: by 10.67.14.100 with SMTP id ff4mr47963751pad.174.1373742399535; Sat, 13 Jul 2013 12:06:39 -0700 (PDT) Received: by 10.68.250.133 with HTTP; Sat, 13 Jul 2013 12:06:39 -0700 (PDT) In-Reply-To: <4F6CE312-BA88-4269-9C3B-BB7C6A28B53E@gmail.com> References: <20130704162758.D2014B1E003@rfc-editor.org> <4F6CE312-BA88-4269-9C3B-BB7C6A28B53E@gmail.com> Date: Sat, 13 Jul 2013 21:06:39 +0200 Message-ID: From: Abdussalam Baryun To: Christopher Dearlove Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] [Technical Errata Reported] RFC6130 (3677) 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, 13 Jul 2013 19:06:40 -0000 On 7/7/13, Christopher Dearlove wrote: > Because of that, it can be greater than L_time, because we keep > updating L_HEAD_time in case of restoration, but we don't keep updating > L_time, because we only want to advertise the link as lost for a finite > time. L_HOLD_Time is the one for advertsing not L_time (i.e. is time period for remove link-tuple). > > It's there and it works. It is just overlooked in the constraints. Your > suggestion would break this. is the *this issue* a requirement or applicability. > > Furthermore, modifying the constraints is painless. They only come into play > when the internal state is modified by an external process. Mostly they can > be ignored. But modifying the actual protocol is not painless. It is also > not just unnecessary, but wrong. the appendix B is mentioned in specification pages: 14, 17, 52, 53, and 55. So I think it can be painfull to change as your errata is doing. Only 52 and 53 are external process concerns not other pages. I will do my rfc6130 implementation and make my comment into the IETF, but busy with others. Was 6130 implementation discussed on the list before, I don't think much, only announcements. AB From christopher.dearlove@googlemail.com Sat Jul 13 14:36: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 4C75921F84E7 for ; Sat, 13 Jul 2013 14:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.581 X-Spam-Level: X-Spam-Status: No, score=-0.581 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_QP_LONG_LINE=1.396] 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 uNlBqHwFkugn for ; Sat, 13 Jul 2013 14:36:03 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF3521F84B1 for ; Sat, 13 Jul 2013 14:36:03 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id p60so8962864wes.41 for ; Sat, 13 Jul 2013 14:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=CkAOcF3SqDRRiRLGp4uNX6V566IQyGwvabBQwHicYRk=; b=tiYH9WEQGlqYwMoowOYsv/v1fTpkMorUxci9K1L3YjLJj4yLQyLo8+YkkpTj651gjz OPji3/lTNQ4Lxr7ovcEF1mifo0F/dlaWkfxI9gMgpeKDfMjJqnCikohKL2IAwjOcuYXT 9fMyjRWjpYZRyWbypjKrmoLcqCzRMmXxw0TLOj3FtED+/dVh/KDU9P7KEJyVAUQ9OmBG dW3m1tcnJp2xCKTleyNxsEDklQ2hFqYEvCKsuO0BlkljYMvFiICBrcn3lgcP1gcFM5h6 cjHco/rMT1YBFrpMuhf9wW6DPtsidywNEFW8rkdlpCf9bJduK596gOTwDr8RrIRKn7js 4dLA== X-Received: by 10.180.73.68 with SMTP id j4mr4990655wiv.10.1373751359740; Sat, 13 Jul 2013 14:35:59 -0700 (PDT) Received: from [192.168.1.104] (host86-132-122-238.range86-132.btcentralplus.com. [86.132.122.238]) by mx.google.com with ESMTPSA id d8sm11180322wiz.0.2013.07.13.14.35.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jul 2013 14:35:59 -0700 (PDT) References: <20130704162758.D2014B1E003@rfc-editor.org> <4F6CE312-BA88-4269-9C3B-BB7C6A28B53E@gmail.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8B117) From: Christopher Dearlove Date: Sat, 13 Jul 2013 22:36:33 +0100 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] [Technical Errata Reported] RFC6130 (3677) 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, 13 Jul 2013 21:36:04 -0000 If you think the change is painful then you do not understand. It is not. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 13 Jul 2013, at 20:06, Abdussalam Baryun wro= te: > On 7/7/13, Christopher Dearlove wrot= e: >=20 >> Because of that, it can be greater than L_time, because we keep >> updating L_HEAD_time in case of restoration, but we don't keep updating >> L_time, because we only want to advertise the link as lost for a finite >> time. >=20 > L_HOLD_Time is the one for advertsing not L_time (i.e. is time period > for remove link-tuple). >=20 >>=20 >> It's there and it works. It is just overlooked in the constraints. Your >> suggestion would break this. >=20 > is the *this issue* a requirement or applicability. >=20 >>=20 >> Furthermore, modifying the constraints is painless. They only come into p= lay >> when the internal state is modified by an external process. Mostly they c= an >> be ignored. But modifying the actual protocol is not painless. It is also= >> not just unnecessary, but wrong. >=20 > the appendix B is mentioned in specification pages: 14, 17, 52, 53, > and 55. So I think it can be painfull to change as your errata is > doing. Only 52 and 53 are external process concerns not other pages. >=20 > I will do my rfc6130 implementation and make my comment into the IETF, > but busy with others. Was 6130 implementation discussed on the list > before, I don't think much, only announcements. >=20 > AB From internet-drafts@ietf.org Sun Jul 14 11:12:07 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 0261921F9C72; Sun, 14 Jul 2013 11:12:07 -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 XHF6M4n-eJEW; Sun, 14 Jul 2013 11:12:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2B321F9C87; Sun, 14 Jul 2013 11:12:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130714181206.30850.62570.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 11:12:06 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-01.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, 14 Jul 2013 18:12:07 -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 : Dynamic MANET On-demand (AODVv2) Routing Author(s) : Charles E. Perkins Stan Ratliff John Dowdell Filename : draft-ietf-manet-aodvv2-01.txt Pages : 57 Date : 2013-07-14 Abstract: The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-aodvv2-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yi.jiazi@gmail.com Sun Jul 14 15:55:49 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 BCF1F21F9BEF for ; Sun, 14 Jul 2013 15:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu0Aeb-pN+Qa for ; Sun, 14 Jul 2013 15:55:49 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 90C0E21F9CA0 for ; Sun, 14 Jul 2013 15:55:48 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id a12so9464609wgh.4 for ; Sun, 14 Jul 2013 15:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=d5Nx7u4DhKuzjnRGo+W50UASDdSZDeQQ/L7GaBDemDk=; b=oCcYii4191WWU1zmOqtGF5SbUHWnperyYy2eb+1HN165ZaUKv2uAxQaOkYOalnh266 pwD82SMuQew+qlpm7MbwL0szyqiggoo4DvQb/Sizd1wMhsCGTUWtZct6qfjo5alSAhCF z/4nfBa7htUYt1JxvZ45sQoxiQG7keb2ukE+Lpdso7mVaNcewaR8EDYyINe8e+8hwsvR gD7IVIeNZKPB6gFv1M/60qfjVtQdDoLweNlEuOw9rYz3QvYStwhM/we+Owa3CiR8+8GG fSrKYmv2QU9KoNeUcXrwc8E7vNixToBDUV7K1goZfszSwZzcMm/hah28oDNuAEd+mBmH loxQ== X-Received: by 10.180.183.40 with SMTP id ej8mr7111185wic.37.1373842547710; Sun, 14 Jul 2013 15:55:47 -0700 (PDT) Received: from new-host-5.home (128-79-35-43.hfc.dyn.abo.bbox.fr. [128.79.35.43]) by mx.google.com with ESMTPSA id s19sm17176850wik.11.2013.07.14.15.55.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 15:55:46 -0700 (PDT) From: Jiazi Yi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jul 2013 00:55:45 +0200 References: <20130714205001.8649.95453.idtracker@ietfa.amsl.com> To: "manet@ietf.org List" Message-Id: <8FBEB4B2-872F-4B64-AE23-B2A29A15E5B2@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [manet] Fwd: New Version Notification for draft-clausen-lln-loadng-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, 14 Jul 2013 22:55:49 -0000 Dear all,=20 A new revision of LOADng has been submitted.=20 Several bugs discussed in the mailing list have been fixed in the new = revision.=20 > A new version of I-D, draft-clausen-lln-loadng-09.txt > has been successfully submitted by Thomas Heide Clausen and posted to = the > IETF repository. >=20 > Filename: draft-clausen-lln-loadng > Revision: 09 > Title: The Lightweight On-demand Ad hoc = Distance-vector Routing Protocol - Next Generation (LOADng) > Creation date: 2013-07-11 > Group: Individual Submission > Number of pages: 70 > URL: = http://www.ietf.org/internet-drafts/draft-clausen-lln-loadng-09.txt > Status: = http://datatracker.ietf.org/doc/draft-clausen-lln-loadng > Htmlized: = http://tools.ietf.org/html/draft-clausen-lln-loadng-09 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-clausen-lln-loadng-09 >=20 > Abstract: > This document describes the Lightweight Ad hoc On-Demand - Next > Generation (LOADng) distance vector routing protocol, a reactive > routing protocol intended for use in Mobile Ad hoc NETworks = (MANETs). >=20 cheers Jiazi= From yi.jiazi@gmail.com Sun Jul 14 16:05:02 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 D4E5B21F9CF5 for ; Sun, 14 Jul 2013 16:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqKpH85jKe3X for ; Sun, 14 Jul 2013 16:05:00 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 83BA221F9C28 for ; Sun, 14 Jul 2013 16:04:56 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so9670258wev.0 for ; Sun, 14 Jul 2013 16:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=WuHjFJUQThOKj6rZ6Qi1/+7+wkytmRcVEvHa9B4t8ok=; b=mhhJv5+i0GuCFVTJ3G9J2O3CtwkIzmpnzxdzxkyaf8x59CP4CwY8cLv2eVvopAcCeO PnR/l4pFt+EnWA87A6nBeHY48m7dKQZ2tCUnYpGEcIjU+xD61oLn8GQqfVkTDQ3hptXR 6W/mv3akbX0UZAKJLbnbo+UeDhbcFG8DNAO1lOBrKBkIgEFtTpqf6AQNcHyolHFCsr4x +8oFcYFGFjTUiCoVEz2VQsz5FEQ9M7JqsXz4QApj0yN+qFrKLsqWVAEG5hhCzLZgJdQS STv9IpTTPLVGN1uYTXzF7VTOM74p04Ljg2YQdiSzZOQuFcCLrna5KUL/Ht4gdB/OF4YO 5qqA== X-Received: by 10.194.110.6 with SMTP id hw6mr30277694wjb.3.1373843095694; Sun, 14 Jul 2013 16:04:55 -0700 (PDT) Received: from new-host-5.home (128-79-35-43.hfc.dyn.abo.bbox.fr. [128.79.35.43]) by mx.google.com with ESMTPSA id nb12sm17232390wic.7.2013.07.14.16.04.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 16:04:54 -0700 (PDT) From: Jiazi Yi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jul 2013 01:04:53 +0200 References: <20130714210020.20583.82187.idtracker@ietfa.amsl.com> To: "manet@ietf.org List" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [manet] Fwd: New Version Notification for draft-yi-loadngsmartrreq-00.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, 14 Jul 2013 23:05:02 -0000 Dear all,=20 A new companion document for LOADng has been submitted.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Abstract: This document describes the Smart Route Request extension for Lightweight Ad hoc On-Demand - Next Generation (LOADng) distance vector routing protocol. It allows making use of discovered routing information to forward Route Request message, and helps reducing routing overhead in LOADng. =3D=3D=3D=3D=3D=3D=3D=3D=3D The main purpose of this document is reducing the control overhead of = LOADng, while maintaining the light-weitht feature of LOADng.=20 One of the issues that the authors are still discussing is that if this = specification should go the the core specification of LOADng, or go to a = separate document like this.=20 It has been implemented and tested in several implementations. The = results show that this simple extension and effectively improve the = performance of the LOADng protocol.=20 cheers Jiazi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-yi-loadngsmartrreq-00.txt > Date: July 14, 2013 23:00:20 PM GMT+02:00 > To: Thomas Clausen , Jiazi Yi = , Thomas H. Clausen >=20 >=20 > A new version of I-D, draft-yi-loadngsmartrreq-00.txt > has been successfully submitted by Jiazi Yi and posted to the > IETF repository. >=20 > Filename: draft-yi-loadngsmartrreq > Revision: 00 > Title: Smart Route Request for Lightweight On-demand = Ad hoc Distance-vector Routing - Next Generation > Creation date: 2013-07-14 > Group: Individual Submission > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-yi-loadngsmartrreq-00.txt > Status: = http://datatracker.ietf.org/doc/draft-yi-loadngsmartrreq > Htmlized: = http://tools.ietf.org/html/draft-yi-loadngsmartrreq-00 >=20 >=20 > Abstract: > This document describes the Smart Route Request extension for > Lightweight Ad hoc On-Demand - Next Generation (LOADng) distance > vector routing protocol. It allows making use of discovered routing > information to forward Route Request message, and helps reducing > routing overhead in LOADng. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From yi.jiazi@gmail.com Sun Jul 14 16: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 CFB2621F9048 for ; Sun, 14 Jul 2013 16:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWI1dFM2OA1k for ; Sun, 14 Jul 2013 16:11:08 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id E418E21F8476 for ; Sun, 14 Jul 2013 16:11:07 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id t56so9426957wes.21 for ; Sun, 14 Jul 2013 16:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=r9xfZks69PQJ5lmrnEn0CSadSRCZqtZsqQfmHMhzz+c=; b=HnkmvCjhjbACIJc/FURBfJux5Lw+8kAVr/wXLAcqRcMkJd3gqcxdJoHS/BB0UNGgjY s1SX7BufujIiPyvz/My1/r8yR9AmglmSYZ6CCeynsPMafETbjy4OgO1sMT75H/0jEf9I ESQ0nz8LsaS2Q6yVImGRfc7szwk5Ncy39Y/I/T+g80XoHCP+Ntu4C5utl80t/EqbsMIr 01APZ6u6BRksVWOq3uoZr5gMJ7BOUmAktgv3MLgCUNzdB3VExJ07jwwaGN6qBisEFuS9 jc18f37dpCVXrzGj4hrujdQ6ixYnZ3LVft4a3As8sZhR13vcLX0SDpPhhH+GrZzPAOf4 e9tQ== X-Received: by 10.180.73.81 with SMTP id j17mr7088580wiv.51.1373843464552; Sun, 14 Jul 2013 16:11:04 -0700 (PDT) Received: from new-host-5.home (128-79-35-43.hfc.dyn.abo.bbox.fr. [128.79.35.43]) by mx.google.com with ESMTPSA id fd3sm17236042wic.10.2013.07.14.16.11.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 16:11:03 -0700 (PDT) From: Jiazi Yi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jul 2013 01:11:02 +0200 References: <20130714205558.5391.60384.idtracker@ietfa.amsl.com> To: "manet@ietf.org List" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [manet] Fwd: New Version Notification for draft-yi-manet-reactive-jitter-00.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, 14 Jul 2013 23:11:08 -0000 Dear all,=20 A new document for jitter consideration in reactive protocol has been = submitted.=20 This document tries to improve the application of jitter mechanism in = MANET reactive protocols.=20 Some experience has been obtained based on LOADng, and it could be = applied to other reactive protocols also (like AODV, DSR).=20 cheers Jiazi Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-yi-manet-reactive-jitter-00.txt > Date: July 14, 2013 22:55:58 PM GMT+02:00 > To: Thomas Clausen , Jiazi Yi = , Juan Antonio Cordero Fuertes = , Thomas H. Clausen >=20 >=20 > A new version of I-D, draft-yi-manet-reactive-jitter-00.txt > has been successfully submitted by Jiazi Yi and posted to the > IETF repository. >=20 > Filename: draft-yi-manet-reactive-jitter > Revision: 00 > Title: Jitter Consideration for Reactive Protocol in = Mobile Ad Hoc Networks (MANETs) > Creation date: 2013-07-13 > Group: Individual Submission > Number of pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-yi-manet-reactive-jitter-00.txt > Status: = http://datatracker.ietf.org/doc/draft-yi-manet-reactive-jitter > Htmlized: = http://tools.ietf.org/html/draft-yi-manet-reactive-jitter-00 >=20 >=20 > Abstract: > This document provides recommendations for jittering (randomly > timing) of routing control message transmission, especially route > request dissemination, in reactive protocol of Mobile Ad Hoc > Networks, to reduce the probability of collisions, decrease routing > overhead, and help finding the optimum routes in the network. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From henning.rogge@fkie.fraunhofer.de Mon Jul 15 01:28: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 8CFAA21F997B for ; Mon, 15 Jul 2013 01:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 1FG2P3geH79W for ; Mon, 15 Jul 2013 01:28:41 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 0262C21F9EE6 for ; Mon, 15 Jul 2013 01:23:31 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Uye48-00056V-3L; Mon, 15 Jul 2013 10:23:28 +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 1Uye48-0004vo-0f; Mon, 15 Jul 2013 10:23:28 +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; Mon, 15 Jul 2013 10:23:28 +0200 Message-ID: <51E3B17A.3000205@fkie.fraunhofer.de> Date: Mon, 15 Jul 2013 10:23:22 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030409090201030504090705" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17510/Mon Jul 15 06:42:24 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 6bd7b0f56198420fae403418d833fd2d Cc: Stan Ratliff Subject: [manet] Status of DLEP 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, 15 Jul 2013 08:28:47 -0000 --------------ms030409090201030504090705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I was wondering what is the status of the next DLEP draft. No new draft=20 for this IETF? No presentation about DLEP? 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 --------------ms030409090201030504090705 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 Fw0xMzA3MTUwODIzMjZaMCMGCSqGSIb3DQEJBDEWBBQoeyp7eo3cSAwZB4SQclPEfRrzBjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAaH4nWxsRJ7WabxTmTH+6g8fUNdo6mTBcXIWJOpX/OwkI y0EBq/PjLms1GAU8F33k+iumhH0dmI7nTrjZ7Uit1VTqmlSBvi89UJRNMHAAKuZ+5tp0UwGi RI91TeZqRB7RwHXHIz15DFwCcHX4gsBmckTJ84CXOW5D302nsvyaTK2kg+7w4paT+bFpgG23 5O2HSD1i3XdhBjMi3bZGxx02yhgWNUpq3e+6fFJatOb/SkP2w4Z/kYJecW8su18tHJccVrPC Ziej8YSewvppnFss/zDMSCRmFSAtRinQ3rDFB4a9KL9CUnaCO1saSDDFA7T2dNfrpaWtltly DdIhC4HTAwAAAAAAAA== --------------ms030409090201030504090705-- From chris.dearlove@baesystems.com Mon Jul 15 03:14:31 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 6A0B021F9B97 for ; Mon, 15 Jul 2013 03:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.389 X-Spam-Level: X-Spam-Status: No, score=-10.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 F5BJiOfsHloH for ; Mon, 15 Jul 2013 03:14:27 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id 41DA121F9E94 for ; Mon, 15 Jul 2013 03:14:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,668,1367967600"; d="scan'208";a="299884008" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 15 Jul 2013 11:14:18 +0100 X-IronPort-AV: E=Sophos;i="4.89,668,1367967600"; d="scan'208";a="22134880" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 15 Jul 2013 11:14:18 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.180]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Mon, 15 Jul 2013 11:14:18 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: ETT metrics draft Thread-Index: Ac6BQ/wpsZ7j34UuTmyrmons4tyaQA== Date: Mon, 15 Jul 2013 10:14:16 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "Emmanuel Baccelli \(Emmanuel.Baccelli@inria.fr\)" Subject: [manet] ETT metrics draft 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, 15 Jul 2013 10:14:31 -0000 I have just managed to find time for a quick look over version -02 of the E= TT metric draft. A few comments (I omit editorial comments, such as consist= ency of use of capitalisation of Link Tuple for a later draft). Section 1 Would be useful context to note that adding metrics to OLSRv1 produced a pr= oprietary extension to RFC 3626. The Introduction should provide a bit more OLSrv2 context. Section 3 Refers to [RFC3626] implementation. This is extended as noted above, which = I think is important to applicability. The use of control message loss rate on Wi-Fi (IEEE 802.11) has the issue t= hat the control messages are sent broadcast, the data will be sent unicast.= There's the well-known "grey zone" problem here that is usually solved wit= h link quality (when using OLSRv1 with hop counts). It may well be that in = practice things work, but there is an issue here that I think needs discuss= ion. Section 5 The use of packet sequence numbers relies on an erratum to RFC 5444. Do we = assume everyone reads errata, or should this be commented on? There's a metric normalisation issue for OLSRv2 (this divided by that - sca= led?). Section 6 ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have used som= ething similar in link quality calculations) then it should be only slightl= y larger than 1.0, which is worth saying. Section 7 Here reading through I made a note thatr INTERVAL_TIME TLVs are optional. T= his is discussed later. But I think a section earlier on this may be approp= riate. That section could also discuss entity relationships I'll get to bel= ow. Section 9 At the WG's requirement, we have been careful to divide up different entiti= es with different responsibilities, and controlled ways in which they may i= nteroperate. This has required some care at times. I don't think this draft= has put the same care in. There are three entities: The RFC 5444 packet multiplexer (and demultiplexe= r), NHDP and OLSRv2. So for example OLSRv2 does not put in a packet sequenc= e number. OLSRv2 requests the 5444 multiplexer to add a packet sequence num= ber. Likewise how OLSRv2 interacts with HELLO messages needs care, see OLSR= v2 draft for how LINK_METRIC and MPR TLVs are handled. = But this is more complicated than that. Because we are considering haps in = packet sequence numbers, that means all packets need to be considered. That= could include packets containing neither HELLO messages nor TC messages, w= hich normally neither NHDP nor OLSRv2 will see. (They get reported their me= ssages, and can access related packet information.) This is therefore in pa= rt a function interacting directly with the 5444 multiplexer, which is new,= and we (WG, if this is adopted) should be clear on how to handle that - or= someone (in the IESG if not sooner) will ask many difficult questions. Rel= ated to that is whether this extends NHDP, but is used by an extension to O= LSRv2, or extends just OLSRv2, and is solely defined in that context. Section 9.2 When it says "packets without packet sequence number MUST NOT be processed,= that's not quite right in terms of the 5444/NHDP/OLSRv2 model, as discuss= ed above. Also not clear from this wording that you just mean for purpose o= f metric calculation. Section 9.2/9.3 (or other for resolution) Need a bit more clarity on what to do if you don't get helpful input (missi= ng PSN or INTERVAL_T IMETLV). You still need a metric if the Link Tuple is = on an OLSRv2 interface, obviously maximum, but that's only said in the proc= essing, not in the can't process part. Section 11 Looking at the L_in_metric calculation, is that calculation going to produc= e a value in the range 1 to MAXIMUM_METRIC? (I don't have time right now to= check that). Even if it does, needs comment about rounding/truncating to a= representable value (note that L_in_metric must be representable, it's in = the OLSRv2 constraints this is bound by). Section 12 These are possibly suitable values for Wi-Fi. That may be fine for Funkfeue= r, but if this is adapted as a WG document we need to be more general that = that., and to separate what's specific to that and what isn't. We need to b= e able to understand that if, for example, I want to use this on a system t= hat varies between say 1 kbit/s and 256 kbit/s, what other parameters chang= e? Section 14 Suggest referencing the NHDP/OLSRv2 integrity draft. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From abdussalambaryun@gmail.com Mon Jul 15 03:28: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 41D3C21F85F4 for ; Mon, 15 Jul 2013 03:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VKNi9vw1+M4t for ; Mon, 15 Jul 2013 03:28:14 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 545EF21F9F43 for ; Mon, 15 Jul 2013 03:28:14 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so11080612pbc.35 for ; Mon, 15 Jul 2013 03:28:09 -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=ew+jC5+dBXjtpLTE2k92yR0Lmm1Nzmzhsbpwqt+royA=; b=NRhKyBP812CX02SuFRXaIkGM1mgD+/b8ClrYMIlofJ1kr0uqrjtj3/iznpgec7M2xd KrKvBw+v4+ksbvYLssFLFHq5k0JNn2mWhOw7YAAVhEjVTs/rZ/B09ZQ087N2w78T05+p aW7tr+5uQ3D+5DkyVXHqBvOYN6Op4acXTc2/0GEgDrajMPM8lixBXeD2UxlB7ZOnzIfw yLeCBk+6Uwr7425xtTm1RclZHbZU7l/3vJyR+VSoZk53xrr3EPidajBADzTxGYrV9bkt Zqxm82BR37LJf9TY598bacM4OcR7EBg9+3OdHxEtvlEgO/RtiMghadcZTDCCf4KUTICQ yvvA== MIME-Version: 1.0 X-Received: by 10.66.26.179 with SMTP id m19mr53922453pag.4.1373884089801; Mon, 15 Jul 2013 03:28:09 -0700 (PDT) Received: by 10.68.250.133 with HTTP; Mon, 15 Jul 2013 03:28:09 -0700 (PDT) In-Reply-To: <51E3B17A.3000205@fkie.fraunhofer.de> References: <51E3B17A.3000205@fkie.fraunhofer.de> Date: Mon, 15 Jul 2013 11:28:09 +0100 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=bcaec5299df522a09804e18a51ba Cc: "manet@ietf.org" , Stan Ratliff Subject: Re: [manet] Status of DLEP 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, 15 Jul 2013 10:28:15 -0000 --bcaec5299df522a09804e18a51ba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I request if no presentation discussion related is important for progress, because in last meeting I think not much time was discussed on DLEP, AB On Mon, Jul 15, 2013 at 9:23 AM, Henning Rogge < henning.rogge@fkie.fraunhofer.de> wrote: > Hi, > > I was wondering what is the status of the next DLEP draft. No new draft > for this IETF? No presentation about DLEP? > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.**fraunhofer.de > http://www.fkie.fraunhofer.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --bcaec5299df522a09804e18a51ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I request if no presentation discussion related is im= portant for progress, because in last meeting I think not much time was dis= cussed on DLEP,
=A0
AB


On Mon, Jul 15, 2013 at 9:23 AM, Henning= Rogge <henning.rogge@fkie.fraunhofer.de> wro= te:
Hi,

I was wondering what is the status of the next DLEP draft. No new draft for= this IETF? No presentation about DLEP?

Henning Rogge
--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961, =A0 Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de


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


--bcaec5299df522a09804e18a51ba-- From ulrich@herberg.name Mon Jul 15 10:19: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 2F77D21E80FB for ; Mon, 15 Jul 2013 10:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.034, 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 SSQ1pcg8JWkg for ; Mon, 15 Jul 2013 10:19:08 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA2111E80AD for ; Mon, 15 Jul 2013 10:19:08 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id m1so10193000ves.28 for ; Mon, 15 Jul 2013 10:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lRiKjRyjESdozSHQ+j1r2YkXz/sBhccC4rrrRLODiPc=; b=Xc4gyNTMFV777lLss0cykmu9fVVUK0J5f8H3LZWlBkeP8tA7gTkd7VAN+4bbNiemjA YfmtkCLQsHAi/8z3u5dOhjBFo1sYQvbEzprzRMJLGILixXSyQLYtGnyhgt4tKcb+WjGz aKLxegzXFLNjiwN0zzP0o7/lrAME/tK0Q/qr8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=lRiKjRyjESdozSHQ+j1r2YkXz/sBhccC4rrrRLODiPc=; b=A03G2GNn9GAa8qmBF2pRUTiyiIahP7akW7XfYNIjORPsYaH3GYi/FKviWuTpVLzdcr a3le/eUw3h9nVAD52ZMKt5faoXzHux8vRYWkpcm6VDAQvShLi1TgoIIqMC7b8+Oe3VKL 2fj1M2FZ3OVtYSjEziuiYS/wNv0+OOpIOIBPpNjX/re8hiNoNb8X/Y1usY2gmBz4wdqS Ivo7BtXSojmAhRZ3oPVCIp/Su03/daw4p8lngfdxm5gpcJ3Se0YIdKUQJEfE7h2m6/ta ZAeI4JE7+F4KYnZ+F+cVm8Mkt9SQ6KzrGPb24q+VmDWOVX7Ean78PAu+6BTAgynRjOkV ho2Q== MIME-Version: 1.0 X-Received: by 10.220.159.208 with SMTP id k16mr29171894vcx.92.1373908748107; Mon, 15 Jul 2013 10:19:08 -0700 (PDT) Received: by 10.221.55.70 with HTTP; Mon, 15 Jul 2013 10:19:08 -0700 (PDT) In-Reply-To: <20130715170923.16712.32343.idtracker@ietfa.amsl.com> References: <20130715170923.16712.32343.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 10:19:08 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnh0YuYGFQyiSLn6Ixy4KT6h8r6qwkF5l8SrFjXfg0o6Z0pKjWRLPQm13xuWC9C8IhVgVv6 Subject: [manet] Fwd: Internet Draft Submission Cut-Off Today 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, 15 Jul 2013 17:19:09 -0000 Reminder: draft submission cut-off today, UTC 24:00. Early-bird registration deadline: This Friday, July 19. ---------- Forwarded message ---------- From: IETF Secretariat Date: Mon, Jul 15, 2013 at 10:09 AM Subject: Internet Draft Submission Cut-Off Today To: IETF Announcement List Cc: ietf@ietf.org This is a reminder that the Internet Draft Submission cut-off is today, Monday, July 15, 2013. All submissions are due by UTC 24:00. All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/submit/ The Internet-Draft cutoff dates as well as other significant dates for IETF 87 can be found at: https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF87 Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. From internet-drafts@ietf.org Mon Jul 15 14:22: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 E122C21E8114; Mon, 15 Jul 2013 14:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, 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 y+RMi+fMsq6Y; Mon, 15 Jul 2013 14:22:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B1021E80EC; Mon, 15 Jul 2013 14:22:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715212222.19775.29699.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:22:22 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-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: Mon, 15 Jul 2013 21:22:24 -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 : Dynamic MANET On-demand (AODVv2) Routing Author(s) : Charles E. Perkins Stan Ratliff John Dowdell Filename : draft-ietf-manet-aodvv2-02.txt Pages : 56 Date : 2013-07-15 Abstract: The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-aodvv2-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bebemaster@gmail.com Tue Jul 16 09:56: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 D232D21F9302 for ; Tue, 16 Jul 2013 09:56:23 -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 hRssxW9EIv+u for ; Tue, 16 Jul 2013 09:56:22 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E5A7F21F9AA3 for ; Tue, 16 Jul 2013 09:56:12 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id v20so798335lbc.3 for ; Tue, 16 Jul 2013 09:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1bp/fEOAahKW2iZhtI+r6l8vHO6GCf+y2dzdcmTLFJs=; b=x/CJjDGBS5+rQW2mL5hB9CDMgH7/1b4U3oPJ9zjb7gqZvLEUfVl7Mjbu5PzPZBOYZf YzF/0+AHsWg7xNWpu0IcnRrOc3QUA2NLuvnCVJDjS6sulfolHZp2n242ubPSBe4SO+oG tliJLxt3omyLn1Rq5Mvq9vC54a69pgIi1+XMDZlp/PFZAmKi/DCTbDGB2cYgYTYgZgiS CNvEI7mPK1Dxou1RBgnUogP0K5UayWjqOuDp7rLgemlgguova7oIrjKCny37cofPczG1 qjjDC0uDxRwTTIIikUExAobvh/Aom3OiXVkQ1b7FbgvN9khVjv7d9rDX4qTXAlhDpgeQ cqKg== MIME-Version: 1.0 X-Received: by 10.152.26.2 with SMTP id h2mr1132730lag.52.1373993770858; Tue, 16 Jul 2013 09:56:10 -0700 (PDT) Received: by 10.152.123.116 with HTTP; Tue, 16 Jul 2013 09:56:10 -0700 (PDT) Received: by 10.152.123.116 with HTTP; Tue, 16 Jul 2013 09:56:10 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Jul 2013 12:56:10 -0400 Message-ID: From: Justin Dean To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=089e0158be44a2bed404e1a3dab9 Cc: "Emmanuel Baccelli \(Emmanuel.Baccelli@inria.fr\)" , "manet@ietf.org" Subject: Re: [manet] ETT metrics draft 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, 16 Jul 2013 16:56:25 -0000 --089e0158be44a2bed404e1a3dab9 Content-Type: text/plain; charset=ISO-8859-1 I've also had a little bit of time to look over the draft. My comments at this point are more general than Chris' were. I found the draft overly confusing. The was an ok summary of what the metric is supposed to do, but the it jumps right into details. Without a good idea of how things are supposed to work the variable descriptions just add to the confusion. I don't think it needs to be this complicated, in fact I find it worrisome that I wasn't able to more easily figure out how I would start implementing it. I'll provide more detailed feedback and possible text when I can find some cycles. Justin On Jul 15, 2013 6:15 AM, "Dearlove, Christopher (UK)" < chris.dearlove@baesystems.com> wrote: > I have just managed to find time for a quick look over version -02 of the > ETT metric draft. A few comments (I omit editorial comments, such as > consistency of use of capitalisation of Link Tuple for a later draft). > > Section 1 > > Would be useful context to note that adding metrics to OLSRv1 produced a > proprietary extension to RFC 3626. > > The Introduction should provide a bit more OLSrv2 context. > > Section 3 > > Refers to [RFC3626] implementation. This is extended as noted above, which > I think is important to applicability. > > The use of control message loss rate on Wi-Fi (IEEE 802.11) has the issue > that the control messages are sent broadcast, the data will be sent > unicast. There's the well-known "grey zone" problem here that is usually > solved with link quality (when using OLSRv1 with hop counts). It may well > be that in practice things work, but there is an issue here that I think > needs discussion. > > Section 5 > > The use of packet sequence numbers relies on an erratum to RFC 5444. Do we > assume everyone reads errata, or should this be commented on? > > There's a metric normalisation issue for OLSRv2 (this divided by that - > scaled?). > > Section 6 > > ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have used > something similar in link quality calculations) then it should be only > slightly larger than 1.0, which is worth saying. > > Section 7 > > Here reading through I made a note thatr INTERVAL_TIME TLVs are optional. > This is discussed later. But I think a section earlier on this may be > appropriate. That section could also discuss entity relationships I'll get > to below. > > Section 9 > > At the WG's requirement, we have been careful to divide up different > entities with different responsibilities, and controlled ways in which they > may interoperate. This has required some care at times. I don't think this > draft has put the same care in. > > There are three entities: The RFC 5444 packet multiplexer (and > demultiplexer), NHDP and OLSRv2. So for example OLSRv2 does not put in a > packet sequence number. OLSRv2 requests the 5444 multiplexer to add a > packet sequence number. Likewise how OLSRv2 interacts with HELLO messages > needs care, see OLSRv2 draft for how LINK_METRIC and MPR TLVs are handled. > > But this is more complicated than that. Because we are considering haps in > packet sequence numbers, that means all packets need to be considered. That > could include packets containing neither HELLO messages nor TC messages, > which normally neither NHDP nor OLSRv2 will see. (They get reported their > messages, and can access related packet information.) This is therefore in > part a function interacting directly with the 5444 multiplexer, which is > new, and we (WG, if this is adopted) should be clear on how to handle that > - or someone (in the IESG if not sooner) will ask many difficult questions. > Related to that is whether this extends NHDP, but is used by an extension > to OLSRv2, or extends just OLSRv2, and is solely defined in that context. > > Section 9.2 > > When it says "packets without packet sequence number MUST NOT be > processed, that's not quite right in terms of the 5444/NHDP/OLSRv2 model, > as discussed above. Also not clear from this wording that you just mean for > purpose of metric calculation. > > Section 9.2/9.3 (or other for resolution) > > Need a bit more clarity on what to do if you don't get helpful input > (missing PSN or INTERVAL_T IMETLV). You still need a metric if the Link > Tuple is on an OLSRv2 interface, obviously maximum, but that's only said in > the processing, not in the can't process part. > > Section 11 > > Looking at the L_in_metric calculation, is that calculation going to > produce a value in the range 1 to MAXIMUM_METRIC? (I don't have time right > now to check that). Even if it does, needs comment about > rounding/truncating to a representable value (note that L_in_metric must be > representable, it's in the OLSRv2 constraints this is bound by). > > Section 12 > > These are possibly suitable values for Wi-Fi. That may be fine for > Funkfeuer, but if this is adapted as a WG document we need to be more > general that that., and to separate what's specific to that and what isn't. > We need to be able to understand that if, for example, I want to use this > on a system that varies between say 1 kbit/s and 256 kbit/s, what other > parameters change? > > Section 14 > > Suggest referencing the NHDP/OLSRv2 integrity draft. > > > -- > 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 > > ******************************************************************** > 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 > --089e0158be44a2bed404e1a3dab9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I've also had a little bit of time to look over the draft. My commen= ts at this point are more general than Chris' were. I found the draft o= verly confusing. The was an ok summary of what the metric is supposed to do= , but the it jumps right into details. Without a good idea of how things ar= e supposed to work the variable descriptions just add to the confusion.=A0 = I don't think it needs to be this complicated, in fact I find it worris= ome that I wasn't able to more easily figure out how I would start impl= ementing it. I'll provide more detailed feedback and possible text when= I can find some cycles.

Justin

On Jul 15, 2013 6:15 AM, "Dearlove, Christo= pher (UK)" <chris.= dearlove@baesystems.com> wrote:
I have just managed to find time for a quick look over version -02 of the E= TT metric draft. A few comments (I omit editorial comments, such as consist= ency of use of capitalisation of Link Tuple for a later draft).

Section 1

Would be useful context to note that adding metrics to OLSRv1 produced a pr= oprietary extension to RFC 3626.

The Introduction should provide a bit more OLSrv2 context.

Section 3

Refers to [RFC3626] implementation. This is extended as noted above, which = I think is important to applicability.

The use of control message loss rate on Wi-Fi (IEEE 802.11) has the issue t= hat the control messages are sent broadcast, the data will be sent unicast.= There's the well-known "grey zone" problem here that is usua= lly solved with link quality (when using OLSRv1 with hop counts). It may we= ll be that in practice things work, but there is an issue here that I think= needs discussion.

Section 5

The use of packet sequence numbers relies on an erratum to RFC 5444. Do we = assume everyone reads errata, or should this be commented on?

There's a metric normalisation issue for OLSRv2 (this divided by that -= scaled?).

Section 6

ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have used som= ething similar in link quality calculations) then it should be only slightl= y larger than 1.0, which is worth saying.

Section 7

Here reading through I made a note thatr INTERVAL_TIME TLVs are optional. T= his is discussed later. But I think a section earlier on this may be approp= riate. That section could also discuss entity relationships I'll get to= below.

Section 9

At the WG's requirement, we have been careful to divide up different en= tities with different responsibilities, and controlled ways in which they m= ay interoperate. This has required some care at times. I don't think th= is draft has put the same care in.

There are three entities: The RFC 5444 packet multiplexer (and demultiplexe= r), NHDP and OLSRv2. So for example OLSRv2 does not put in a packet sequenc= e number. OLSRv2 requests the 5444 multiplexer to add a packet sequence num= ber. Likewise how OLSRv2 interacts with HELLO messages needs care, see OLSR= v2 draft for how LINK_METRIC and MPR TLVs are handled.

But this is more complicated than that. Because we are considering haps in = packet sequence numbers, that means all packets need to be considered. That= could include packets containing neither HELLO messages nor TC messages, w= hich normally neither NHDP nor OLSRv2 will see. (They get reported their me= ssages, and can access related packet information.) This is therefore in pa= rt a function interacting directly with the 5444 multiplexer, which is new,= and we (WG, if this is adopted) should be clear on how to handle that - or= someone (in the IESG if not sooner) will ask many difficult questions. Rel= ated to that is whether this extends NHDP, but is used by an extension to O= LSRv2, or extends just OLSRv2, and is solely defined in that context.

Section 9.2

When it says "packets without packet sequence number MUST NOT be proce= ssed, that's not quite right =A0in terms of the 5444/NHDP/OLSRv2 model,= as discussed above. Also not clear from this wording that you just mean fo= r purpose of metric calculation.

Section 9.2/9.3 (or other for resolution)

Need a bit more clarity on what to do if you don't get helpful input (m= issing PSN or INTERVAL_T IMETLV). You still need a metric if the Link Tuple= is on an OLSRv2 interface, obviously maximum, but that's only said in = the processing, not in the can't process part.

Section 11

Looking at the L_in_metric calculation, is that calculation going to produc= e a value in the range 1 to MAXIMUM_METRIC? (I don't have time right no= w to check that). Even if it does, needs comment about rounding/truncating = to a representable value (note that L_in_metric must be representable, it&#= 39;s in the OLSRv2 constraints this is bound by).

Section 12

These are possibly suitable values for Wi-Fi. That may be fine for Funkfeue= r, but if this is adapted as a WG document we need to be more general that = that., and to separate what's specific to that and what isn't. We n= eed to be able to understand that if, for example, I want to use this on a = system that varies between say 1 kbit/s and 256 kbit/s, what other paramete= rs change?

Section 14

Suggest referencing the NHDP/OLSRv2 integrity draft.


--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0| =A0Fax: +44 1245 242124
chris.dearlove@baesystems.= com | http://ww= w.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

********************************************************************
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
h= ttps://www.ietf.org/mailman/listinfo/manet
--089e0158be44a2bed404e1a3dab9-- From ulrich@herberg.name Tue Jul 16 14:29:58 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 85C5D21F9FF3 for ; Tue, 16 Jul 2013 14:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.032, 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 MjjNsyo3VSfp for ; Tue, 16 Jul 2013 14:29:57 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 380B621F8546 for ; Tue, 16 Jul 2013 14:29:56 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hv10so840126vcb.22 for ; Tue, 16 Jul 2013 14:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zo6IeF0D8VfSestMobAf/VKeo/qBMwwI6rysBjIYQ5w=; b=SzRL/i7wrrySvn04yuiLuioLfFpfFpXR126a0+aI3CNja1LAiB3y0SeKFwzBX95Ycn dnylPH3r0goYRhCmGMO33t0FnzaEl1Oiqt+bMaQG/5jVdJqYMLk/cIfBIcd5RmSauDBq x87+uxRcBDE1tjI8Ymx51i5+a96MJwtQI8xKU= 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=zo6IeF0D8VfSestMobAf/VKeo/qBMwwI6rysBjIYQ5w=; b=JA9rLQ6QQxWVpSMvtmgoNRx/DZHwB11j58T8RJvJkZDArWttxE5ojgr9zNC8bEX+i4 g3L6wpx/GVMvQh96jY0eWs4EZBOSwL8pqK54gnMN3+XoviYF45GtdIqr41kkhx4RmzVC 5edKKeeHcg/lE67n44cGY5KISH6oZt6EeooBIzofpvPPwO2eQnag5brY5g8ACHkXlLYU uQJcRkpjXJu6KDDu7tNPw86q4Rz8nDKM9sHDQxX/4+5bNR0CnHfHA0zxNCG8L6qgaIPQ T86jFVfY8vDWwICctYnqKWpax2HtskbtP1mbYfzc0cQpA2IuXjYD2MOdZZ6XyHJhK39e sU3w== MIME-Version: 1.0 X-Received: by 10.221.4.138 with SMTP id oc10mr1102909vcb.26.1374010191870; Tue, 16 Jul 2013 14:29:51 -0700 (PDT) Received: by 10.221.55.70 with HTTP; Tue, 16 Jul 2013 14:29:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Jul 2013 14:29:51 -0700 Message-ID: From: Ulrich Herberg To: Justin Dean Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmfBBenXBAohgftCH/mdF+prx/YcFNt23WWo/pga0YxPCaAD30FRC+RLYXW4YCDOQgbcRUj Cc: "Dearlove, Christopher \(UK\)" , "Emmanuel Baccelli \(Emmanuel.Baccelli@inria.fr\)" , "manet@ietf.org" Subject: Re: [manet] ETT metrics draft 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, 16 Jul 2013 21:29:58 -0000 Hi, I have also reviewed the draft. Since it's an early draft, just some high-level comments: - I like the idea of specifying the ETT metrics and I hope you will issue a new revision. - The introduction is a bit confusing. It talks about the Funkfeuer networks, and then suddenly jumps into details about ETT metric. I would suggest to focus the document on the metric itself, and mentioning the Funkfeuer networks only in the appendix. I also wonder why the intended status is informational? Shouldn't it be Experimental or Standards Track, since a protocol extension is specified? - section 3 (Applicability); again, I would defocus on the Funkfeuer networks, just mention in general the use cases where the metric is useful. You should focus more on OLSRv2 itself, IMO. - same section: "ETX metric that was used in the earlier [RFC3626] implementation". Note that RFC3626 only uses hop-count, so technically the olsr.org implementation was not RFC3626 compliant - section 7: Since the link tuples are extended, does that mean that draft-ietf-manet-olsrv2 is "updated" (in the IETF sense)? If so, the draft does not say that in the header, nor mention that in the introduction and abstract. I assume that an informational document could also not do that. - "L_ETT_last_pkt_seqno is the last received packet sequence number received from this link." Shouldn't there some section somewhere to describe requirements, such as access to lower layers (e.g., packet sequence numbers)? - section 9 mixes a bit the different layers (RFC5444 and RFC6130). I wonder if that could not be more separated. - some lower case "must" in section 9; should that be 2119 or not? - section 13: Shouldn't that be a new link metric type allocation? How is the metric used in the OLSRv2 network? - why is OLSRv2 only an informative reference? Can there be normative references in an Informational document? - I agree with Chris' and Justin's reviews. Best regards Ulrich On Tue, Jul 16, 2013 at 9:56 AM, Justin Dean wrote: > I've also had a little bit of time to look over the draft. My comments at > this point are more general than Chris' were. I found the draft overly > confusing. The was an ok summary of what the metric is supposed to do, but > the it jumps right into details. Without a good idea of how things are > supposed to work the variable descriptions just add to the confusion. I > don't think it needs to be this complicated, in fact I find it worrisome > that I wasn't able to more easily figure out how I would start implementing > it. I'll provide more detailed feedback and possible text when I can find > some cycles. > > Justin > > On Jul 15, 2013 6:15 AM, "Dearlove, Christopher (UK)" > wrote: >> >> I have just managed to find time for a quick look over version -02 of the >> ETT metric draft. A few comments (I omit editorial comments, such as >> consistency of use of capitalisation of Link Tuple for a later draft). >> >> Section 1 >> >> Would be useful context to note that adding metrics to OLSRv1 produced a >> proprietary extension to RFC 3626. >> >> The Introduction should provide a bit more OLSrv2 context. >> >> Section 3 >> >> Refers to [RFC3626] implementation. This is extended as noted above, which >> I think is important to applicability. >> >> The use of control message loss rate on Wi-Fi (IEEE 802.11) has the issue >> that the control messages are sent broadcast, the data will be sent unicast. >> There's the well-known "grey zone" problem here that is usually solved with >> link quality (when using OLSRv1 with hop counts). It may well be that in >> practice things work, but there is an issue here that I think needs >> discussion. >> >> Section 5 >> >> The use of packet sequence numbers relies on an erratum to RFC 5444. Do we >> assume everyone reads errata, or should this be commented on? >> >> There's a metric normalisation issue for OLSRv2 (this divided by that - >> scaled?). >> >> Section 6 >> >> ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have used >> something similar in link quality calculations) then it should be only >> slightly larger than 1.0, which is worth saying. >> >> Section 7 >> >> Here reading through I made a note thatr INTERVAL_TIME TLVs are optional. >> This is discussed later. But I think a section earlier on this may be >> appropriate. That section could also discuss entity relationships I'll get >> to below. >> >> Section 9 >> >> At the WG's requirement, we have been careful to divide up different >> entities with different responsibilities, and controlled ways in which they >> may interoperate. This has required some care at times. I don't think this >> draft has put the same care in. >> >> There are three entities: The RFC 5444 packet multiplexer (and >> demultiplexer), NHDP and OLSRv2. So for example OLSRv2 does not put in a >> packet sequence number. OLSRv2 requests the 5444 multiplexer to add a packet >> sequence number. Likewise how OLSRv2 interacts with HELLO messages needs >> care, see OLSRv2 draft for how LINK_METRIC and MPR TLVs are handled. >> >> But this is more complicated than that. Because we are considering haps in >> packet sequence numbers, that means all packets need to be considered. That >> could include packets containing neither HELLO messages nor TC messages, >> which normally neither NHDP nor OLSRv2 will see. (They get reported their >> messages, and can access related packet information.) This is therefore in >> part a function interacting directly with the 5444 multiplexer, which is >> new, and we (WG, if this is adopted) should be clear on how to handle that - >> or someone (in the IESG if not sooner) will ask many difficult questions. >> Related to that is whether this extends NHDP, but is used by an extension to >> OLSRv2, or extends just OLSRv2, and is solely defined in that context. >> >> Section 9.2 >> >> When it says "packets without packet sequence number MUST NOT be >> processed, that's not quite right in terms of the 5444/NHDP/OLSRv2 model, >> as discussed above. Also not clear from this wording that you just mean for >> purpose of metric calculation. >> >> Section 9.2/9.3 (or other for resolution) >> >> Need a bit more clarity on what to do if you don't get helpful input >> (missing PSN or INTERVAL_T IMETLV). You still need a metric if the Link >> Tuple is on an OLSRv2 interface, obviously maximum, but that's only said in >> the processing, not in the can't process part. >> >> Section 11 >> >> Looking at the L_in_metric calculation, is that calculation going to >> produce a value in the range 1 to MAXIMUM_METRIC? (I don't have time right >> now to check that). Even if it does, needs comment about rounding/truncating >> to a representable value (note that L_in_metric must be representable, it's >> in the OLSRv2 constraints this is bound by). >> >> Section 12 >> >> These are possibly suitable values for Wi-Fi. That may be fine for >> Funkfeuer, but if this is adapted as a WG document we need to be more >> general that that., and to separate what's specific to that and what isn't. >> We need to be able to understand that if, for example, I want to use this on >> a system that varies between say 1 kbit/s and 256 kbit/s, what other >> parameters change? >> >> Section 14 >> >> Suggest referencing the NHDP/OLSRv2 integrity draft. >> >> >> -- >> 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 >> >> ******************************************************************** >> 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 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From ulrich@herberg.name Tue Jul 16 14:56: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 222D621F9DDE for ; Tue, 16 Jul 2013 14:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.029, 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 5SsV3YkXxrmC for ; Tue, 16 Jul 2013 14:56:55 -0700 (PDT) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7014321F9DD0 for ; Tue, 16 Jul 2013 14:56:55 -0700 (PDT) Received: by mail-vb0-f42.google.com with SMTP id i3so874091vbh.29 for ; Tue, 16 Jul 2013 14:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=2mS2Xib1lJdRO0kjwKUMAEtNFUD/C+qxyprhJWQaH9s=; b=GkP3/FnkWlb5pceDb2fA7Cqcseg8Ap4q7iOgaQ52RmNjwZYbA0o3ZW5KgpJQfhSlp0 2VwdjkHjYNpxUfdhJNmEyDxR9tV22z1syh+Q5A10E6UaSZf+Z+c7MIk0z6KAnrwlJnVR RDjnrHJifDQj9SedpwDmZ2bNfIWkzNzgUfFLk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=2mS2Xib1lJdRO0kjwKUMAEtNFUD/C+qxyprhJWQaH9s=; b=etUsfz+hDtvEump2PNQIdzJIRbYSfowWjl7ofT6h0FSsGggowHizXDYDA57alCqi37 mVth9bfLONe4oYbN1vHFDI2+EVe2VXO88/I9gkzhXuPBLFkvskEMEQfELPiabOBQl5UX JJzYwUu3YpMQ1/mnaTYdGF7D0/QnkzJKOTRrZCsqGs7wqgjp0VH/Ro7mcQsF6jE+VbGz PbZfQpKWhEhKUwPqmHeVZCY7rpbo/IunkbP2CoJ7d51uc7R6lSs59NQgdPlUHnQRRY2L uO8D43zap+OIFZBv2bU9kGVVGiUfPICz30U9tbXpUBqSSTHWsGEYZW9MrR1B95IEhEi5 QX1A== MIME-Version: 1.0 X-Received: by 10.52.70.66 with SMTP id k2mr916430vdu.17.1374011814626; Tue, 16 Jul 2013 14:56:54 -0700 (PDT) Received: by 10.221.55.70 with HTTP; Tue, 16 Jul 2013 14:56:54 -0700 (PDT) Date: Tue, 16 Jul 2013 14:56:54 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org, Christopher Dearlove , Thomas Clausen Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnGrVC4DCE8eIRmrKwOhPyUDYT6beDCOhQIdJZqqWnfLiQ2mL6n9VOGnyUauIp1NAueys1P Subject: [manet] Review of draft-dearlove-manet-nhdp-olsrv2-tlv-extension-01 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, 16 Jul 2013 21:56:56 -0000 Hi, some comments on draft-dearlove-manet-nhdp-olsrv2-tlv-extension-01 - I think this is a good draft and important for extensibility of OLSRv2 - Section 4: It starts out with some descriptive text, and then the normative "An implementation MUST NOT reject a message because it contains such a TLV.". I had to go back in the descriptive text to get the meaning of "such a TLV". I think it would be better to repeat exactly which kind of TLV is meant in the normative part. Also, the sentence "This specification removes that latitude:" confused me, because actually the following sentence is not removed, but added. Since this draft updates RFC6130 and OLSRv2, where exactly would that be added in each of the drafts? - "[RFC5444] defines a multi-value TLV"; the link is not active in the html view. - "(An implementation must still be able to recognize whatever pattern of TLVs the sender chooses to use.)". Is that a normative must? - paragraph starting with "It should be stressed that this is not a ". At this point of reading the draft, I am not sure if that could not cause an interoperability problem with non-updated implementations. If I send a multi-value LINK-STATUS TLV with unknown values, what would happen to a non-updated implementation? I think that is my major comment about the draft, maybe add a section that summarizes whether/how this new draft would affect interoperability with implementations not using it (from what I understand, there would not be any interop problems). - "any test of (for example) Value = 1 or Value = 3 MUST be converted to a test of (for example) Value bitand 1 = 1, where "bitand" denotes a bitwise and operation." Would that affect interoperability? - Maybe add some example messages in the appendix, e.g., for multi-TLV LINK_STATUS? Best regards Ulrich From ulrich@herberg.name Tue Jul 16 15:05:34 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 EB64E21F9E88 for ; Tue, 16 Jul 2013 15:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.028, 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 VxKTF64c3k7h for ; Tue, 16 Jul 2013 15:05:33 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9EA21F9E4D for ; Tue, 16 Jul 2013 15:05:33 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id d10so950353vea.10 for ; Tue, 16 Jul 2013 15:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZHPKfC35tlxvb2u6UHFPMk5R7DDW9qsSxX99KZOCZAM=; b=gR4KHJFtY8U/B+G7inGI7Hw805y0MVAA99qg04BbrtR6PuXxWDwIoQwwZhIk3TQuDC CbnXydFBDPllUdxtcTsY3AvfYZLTFQbIfewJIlawtLOCwKyocKqzdkvDDnUJjWfVKzM9 7UpJNepgnZr3K0vIwJIZOLqyg6ciz97aBUQZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=ZHPKfC35tlxvb2u6UHFPMk5R7DDW9qsSxX99KZOCZAM=; b=nQkn+nbMIFqF2KMmMnVUydvOBI6C50oNX3OMV5rrA7tmWyezctArfyOVAzVkN4qmUn docHlLpawN3zlTay+nCm0J2Y6kWWKLACTYmRX/T5DfRWbY5KZTVrvVVL0kdYxMdjERLu iHcIfktOqL2ijG2AweZFMBfPm8TGtgWZAm/Qtqv1WyG4ol7qL48pFYNTI2qnoRyrcKP6 NjoBN2AFVgrQrZTeMA+dSDytjXRBuCqdVsxUfYmLCBlTVReoLcf9cBWH8ns7xJD0dCvN g01RiuG7l/RvBNtWPP5I88Xufy68E50cJyPLOBP7Um+i9ySkr4DIAyKnDq+l/Q+4jMBR 2/cg== MIME-Version: 1.0 X-Received: by 10.220.225.2 with SMTP id iq2mr1067471vcb.59.1374012332768; Tue, 16 Jul 2013 15:05:32 -0700 (PDT) Received: by 10.221.55.70 with HTTP; Tue, 16 Jul 2013 15:05:32 -0700 (PDT) Date: Tue, 16 Jul 2013 15:05:32 -0700 Message-ID: From: Ulrich Herberg To: Thomas Clausen , Christopher Dearlove , manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmKPB8DNrjNNUm5z91HxlixPHZY7SzkPaS2k0iM7h/2WUE9YPCZLQy3VzpZlJiOvZOaDkmm Subject: [manet] Review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 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, 16 Jul 2013 22:05:34 -0000 It looks like a reasonable draft to me. Two comments: - add an example topology to illustrate the issue - is there any implementation/deployment/simulation experience showing use cases for that optimization? (i.e., how much is traffic reduced for certain topologies? does the mechanism also have drawbacks such as reduced load balancing and resulting energy drain for battery driven routers etc) Ulrich From lotte.steenbrink@fu-berlin.de Tue Jul 16 14:36:36 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 857B511E80F3 for ; Tue, 16 Jul 2013 14:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckpIAEk-q5RV for ; Tue, 16 Jul 2013 14:36:30 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3080C11E80FC for ; Tue, 16 Jul 2013 14:36:30 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.80.1) for manet@ietf.org with esmtp (envelope-from ) id <1UzCv7-0049WC-6l>; Tue, 16 Jul 2013 23:36:29 +0200 Received: from dslb-178-000-157-243.pools.arcor-ip.net ([178.0.157.243] helo=[192.168.178.113]) by inpost2.zedat.fu-berlin.de (Exim 4.80.1) for manet@ietf.org with esmtpsa (envelope-from ) id <1UzCv7-000GX4-2c>; Tue, 16 Jul 2013 23:36:29 +0200 From: Lotte Steenbrink Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jul 2013 23:36:28 +0200 Message-Id: <88082EA1-FE0F-4EB6-9B3C-D7752166276A@fu-berlin.de> To: manet@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Originating-IP: 178.0.157.243 Subject: [manet] AODVv2-01 comments 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, 17 Jul 2013 06:45:26 -0000 Hello, I've read the AODVv2 draft -01. I think the draft is in good shape and = easy to=20 read. Here are some comments (mostly editorial) that could be considered = by=20 the authors to further improve the draft. While the draft usually features sound explanations, one paragraph = doesn't seem to be clear about what it is trying to convey: On Page 39, section 13.4. (Multicast RREP Response to RREQ): Broadcast RREP response to incoming RREQ was originally specified to=20= handle unidirectional links, but it is expensive. Due to the=20 significant overhead, AODVv2 routers MUST NOT use multicast RREP=20 unless configured to do so by setting the administrative parameter USE_MULTICAST_RREP. While there is an explanation why the use of Multicast RREP Responses is=20= discouraged, any hints as to why this functionality is specified in the = first=20 place are missing. The historical note does provide some context, but = only=20 serves to make the paragraph more confusing. My suggestion would be to replace the first sentence of the paragraph = with an=20 explanation how this feature could be useful. If no such explanation = exists, maybe the feature should be removed from the document altogether? On Page 10, section 5.1. (Route Table Entry): =20 Route.Address The (host or network) destination address of the node(s) associated with the routing table entry =20 is "routing table entry" the same as the route table entry referred to a=20= line above? If yes, the choice of words seems inconsistent, if no, it = could be=20 misleading and/or missing a clear explanation. On Page 12, section 5.1. (Route Table Entry): When a route is no longer Active, it becomes an Idle route. =20 After an idle route remains Idle for MAX_IDLETIME,=20 it becomes an Expired route. Shouldn't it say Idle route in the 2nd occurence of the word(s) as well=20= (instead of idle route)? On Page 29, section (7.5.1. Additional Handling for Incoming RREQ): =20 o The RREQ (with updated fields as specified above>) =20 Does that > really belong there? On Page 37, section 13.7.1. (Including Added Node Information): [=85]an AODVv2 router (HandlingRtr) handling a RREP message MAY = attempt=20 to verify connectivity to the next upstream router towards AODVv2 = router=20 originating an RREQ message, Shouldn't it say "towards the AODVv2 originating=85" instead of "towards = AODVv2=20 router originating"? And "a RREQ message" instead of "an RREQ message"? On Page 42, section 14. (Administratively Configurable Parameters and=20 Timer Values): =20 The tables in the following sections show the parameters along their definitions Shouldn't it say "along with their definitions"? is a 8-bit field =20 Isn't it "an 8-bit field" instead of "a 8-bit field?" With kind regards, Lotte Steenbrink From chris.dearlove@baesystems.com Wed Jul 17 02:09:05 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 D3D5121F9EC9 for ; Wed, 17 Jul 2013 02:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 BOeWNZPF-HgU for ; Wed, 17 Jul 2013 02:09:00 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 82AE821F9E68 for ; Wed, 17 Jul 2013 02:08:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,683,1367967600"; d="scan'208";a="356113710" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 17 Jul 2013 10:08:51 +0100 X-IronPort-AV: E=Sophos;i="4.89,683,1367967600"; d="scan'208";a="21938521" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 17 Jul 2013 10:08:50 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.180]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.02.0328.009; Wed, 17 Jul 2013 10:08:48 +0100 From: "Dearlove, Christopher (UK)" To: Ulrich Herberg , "manet@ietf.org" , Thomas Clausen Thread-Topic: Review of draft-dearlove-manet-nhdp-olsrv2-tlv-extension-01 Thread-Index: AQHOgm9jS0yIZE1BsEaHKR+Il7bAPZlokPSA Date: Wed, 17 Jul 2013 09:08:46 +0000 Message-ID: References: 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: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Review of draft-dearlove-manet-nhdp-olsrv2-tlv-extension-01 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, 17 Jul 2013 09:09:06 -0000 Some comments >>> below. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Ulrich Herberg [mailto:ulrich@herberg.name] = Sent: 16 July 2013 22:57 To: manet@ietf.org; Dearlove, Christopher (UK); Thomas Clausen Subject: Review of draft-dearlove-manet-nhdp-olsrv2-tlv-extension-01 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi, some comments on draft-dearlove-manet-nhdp-olsrv2-tlv-extension-01 - I think this is a good draft and important for extensibility of OLSRv2 - Section 4: It starts out with some descriptive text, and then the normative "An implementation MUST NOT reject a message because it contains such a TLV.". I had to go back in the descriptive text to get the meaning of "such a TLV". I think it would be better to repeat exactly which kind of TLV is meant in the normative part. Also, the sentence "This specification removes that latitude:" confused me, because actually the following sentence is not removed, but added. Since this draft updates RFC6130 and OLSRv2, where exactly would that be added in each of the drafts? - "[RFC5444] defines a multi-value TLV"; the link is not active in the html view. - "(An implementation must still be able to recognize whatever pattern of TLVs the sender chooses to use.)". Is that a normative must? - paragraph starting with "It should be stressed that this is not a ". At this point of reading the draft, I am not sure if that could not cause an interoperability problem with non-updated implementations. If I send a multi-value LINK-STATUS TLV with unknown values, what would happen to a non-updated implementation? I think that is my major comment about the draft, maybe add a section that summarizes whether/how this new draft would affect interoperability with implementations not using it (from what I understand, there would not be any interop problems). >>> The purpose here is that this is an update to OLSRv2. A fully compliant >>> will have to do what is described here. If an implementation is not >>> updated then with regard to e.g. LINK_STATUS then it's not certain >>> what will happen, it depends on what assumptions the implementer >>> has made about e.g. LINK_STATUS =3D 42. That it can't happen and the >>> whole message is rejected is a permitted possibility that this draft >>> unpermits. Beyond that, we're in unknown territory. I think I would >>> argue that - rejection aside - you should ignore LINK_STATUS =3D 42 >>> because you are told what to do if it is SYMMETRIC, HEARD, or LOST, >>> but not otherwise, Except that (and I have not checked) there may >>> be places in the protocol pseudo-code that use "otherwise" implicitly >>> assuming only those three cases exist. If anyone wants to do a rigorous >>> trawl through the drafts to check this out, that could be useful. >>> Note that (apart from the rejection) - "any test of (for example) Value =3D 1 or Value =3D 3 MUST be converted to a test of (for example) Value bitand 1 =3D 1, where "bitand" denotes a bitwise and operation." Would that affect interoperability? >>> It could. But the purpose here is to force the change. At the moment >>> there are few implementations of OLSRv2, and probably everyone with >>> one is reading this. And very likely is already doing this. Let's not g= et >>> ourselves trapped without thsi change. - Maybe add some example messages in the appendix, e.g., for multi-TLV LINK_STATUS? >>> This is the sort of thing to be considered once we get this accepted. >>> (I do however have some software that would make such examples >>> relatively straightforward to create.) Best regards Ulrich ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From chris.dearlove@baesystems.com Wed Jul 17 02:20:58 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 F15D621F9E12 for ; Wed, 17 Jul 2013 02:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 vyMb1NXkb4cX for ; Wed, 17 Jul 2013 02:20:54 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by ietfa.amsl.com (Postfix) with ESMTP id C278121F9E36 for ; Wed, 17 Jul 2013 02:20:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,683,1367967600"; d="scan'208";a="300443140" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 17 Jul 2013 10:20:52 +0100 X-IronPort-AV: E=Sophos;i="4.89,683,1367967600"; d="scan'208";a="22407115" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasodc005.greenlnk.net with ESMTP; 17 Jul 2013 10:20:52 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.180]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Wed, 17 Jul 2013 10:20:52 +0100 From: "Dearlove, Christopher (UK)" To: Ulrich Herberg , Thomas Clausen , "manet@ietf.org" Thread-Topic: [manet] Review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 Thread-Index: AQHOgnCkDUIMcJgQKkewyhAo+F1bf5lolXJQ Date: Wed, 17 Jul 2013 09:20:50 +0000 Message-ID: References: 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: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 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, 17 Jul 2013 09:20:58 -0000 With regard to whether this causes a problem, there are two answers: (a) This is just permission to do something. There's nothing mandatory abou= t it. Like all aspects of MPR selection, this is the implementer/deployer's= problem. (b) But even if we ignore (a), no, it should not have this effect. This is = handling cases where there's a known better two hop route to a neighbour th= an the one hop route. Given that, you'll never use the one hop route. (Reca= ll that this is only about routing MPRs.) So if you never use the one hop r= oute, then the value as a routing MPR is useless because that just means we= 'll advertise a link in TC messages that will never be used. For experience, this derives from work by Philippe Jacquet and colleagues (= that's how it got into the metrics draft - it wasn't in the very first draf= t, though that might have been unpublished pre -00, I don't recall). So the= re is some experience there. However checking that the precise specificatio= n given is neither too loose (which would make it wrong) or too tight (whic= h would mean we could improve it) needs to be part of the review process. (= Having brought up PJ's name, I should clarify he hasn't signed off on this = formulation.) -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of U= lrich Herberg Sent: 16 July 2013 23:06 To: Thomas Clausen; Dearlove, Christopher (UK); manet@ietf.org Subject: [manet] Review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- It looks like a reasonable draft to me. Two comments: - add an example topology to illustrate the issue - is there any implementation/deployment/simulation experience showing use cases for that optimization? (i.e., how much is traffic reduced for certain topologies? does the mechanism also have drawbacks such as reduced load balancing and resulting energy drain for battery driven routers etc) Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Wed Jul 17 10:08: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 63C7321F9D8F for ; Wed, 17 Jul 2013 10:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.026, 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 x0NhLQsJyx2u for ; Wed, 17 Jul 2013 10:08:43 -0700 (PDT) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 452D321F9D90 for ; Wed, 17 Jul 2013 10:08:29 -0700 (PDT) Received: by mail-vb0-f42.google.com with SMTP id i3so1583619vbh.1 for ; Wed, 17 Jul 2013 10:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KnHmKpO7arBUFfL2rj+m5F/9tpUNABVYpTaenbo+U5I=; b=JSAHhARTdirRgkesyqFdVgZ4v0rn6VggJ5LcYcXNlKXR2lKX42yy2HUDoK2YQ/bBvT F9y2VYF6RgtCHG+Aa1YuJC5L1j0KMVg7Vc5yqlLfxkPSe2sPTgKj7/0zlO7HVikpBzSe e9iYUoxEeldzBH08oMQj1JsktUycBcoq+sZU8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=KnHmKpO7arBUFfL2rj+m5F/9tpUNABVYpTaenbo+U5I=; b=Cd0dgbDmz44EyiyzV/5FoGEw6tyiBjp9sYj7EmvBOVZh/RWkh4tHhXtgG7ffeP+NkE s7oW0HlTHeQBzM2ubx5RvoxupYRFyaqWTj80MQ9cAxnEi6U/T9dVYycxRljn5JYoNmDB 2guSKn1pZySHHon6MGObzbNv0GvcHYsnffkGbxeD8/2e2Skzp2eelvCjhrmELXn7/VxL Bh8eUicc7/stC1hdkcooa7UAA0b/YC9KgR9XrJF6Vg/mwnbEQfpdvNvGMRpMR5/RDNft dhwCLSkzLfOZJ3Pft7JqvTb+BVBO9UNhFX7PQKx3ewdnD4knsNzmW+QrzReL208GqgbU shLw== MIME-Version: 1.0 X-Received: by 10.221.4.138 with SMTP id oc10mr2524290vcb.26.1374080909094; Wed, 17 Jul 2013 10:08:29 -0700 (PDT) Received: by 10.221.55.70 with HTTP; Wed, 17 Jul 2013 10:08:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 10:08:29 -0700 Message-ID: From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkONbBGEiYloT8sH1YOXlX56vdKpZUMWbrXNJhpT/eK8p5XNOtZYnj60FtwCz+Q8fAXu+gX Cc: "manet@ietf.org" , Thomas Clausen Subject: Re: [manet] Review of draft-dearlove-manet-olsrv2-rmpr-optimization-00 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, 17 Jul 2013 17:08:44 -0000 Thank you for the explanations. Best regards Ulrich On Wed, Jul 17, 2013 at 2:20 AM, Dearlove, Christopher (UK) wrote: > With regard to whether this causes a problem, there are two answers: > (a) This is just permission to do something. There's nothing mandatory ab= out it. Like all aspects of MPR selection, this is the implementer/deployer= 's problem. > (b) But even if we ignore (a), no, it should not have this effect. This i= s handling cases where there's a known better two hop route to a neighbour = than the one hop route. Given that, you'll never use the one hop route. (Re= call that this is only about routing MPRs.) So if you never use the one hop= route, then the value as a routing MPR is useless because that just means = we'll advertise a link in TC messages that will never be used. > > For experience, this derives from work by Philippe Jacquet and colleagues= (that's how it got into the metrics draft - it wasn't in the very first dr= aft, though that might have been unpublished pre -00, I don't recall). So t= here is some experience there. However checking that the precise specificat= ion given is neither too loose (which would make it wrong) or too tight (wh= ich would mean we could improve it) needs to be part of the review process.= (Having brought up PJ's name, I should clarify he hasn't signed off on thi= s formulation.) > > -- > 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 > > > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of= Ulrich Herberg > Sent: 16 July 2013 23:06 > To: Thomas Clausen; Dearlove, Christopher (UK); manet@ietf.org > Subject: [manet] Review of draft-dearlove-manet-olsrv2-rmpr-optimization-= 00 > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > It looks like a reasonable draft to me. Two comments: > - add an example topology to illustrate the issue > - is there any implementation/deployment/simulation experience > showing use cases for that optimization? (i.e., how much is traffic > reduced for certain topologies? does the mechanism also have drawbacks > such as reduced load balancing and resulting energy drain for battery > driven routers etc) > > Ulrich > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > From sratliff@cisco.com Thu Jul 18 11:26:10 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 9A87011E81BA for ; Thu, 18 Jul 2013 11:26:10 -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 J33Zyn5dh58h for ; Thu, 18 Jul 2013 11:26:03 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D657411E819E for ; Thu, 18 Jul 2013 11:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=881; q=dns/txt; s=iport; t=1374171958; x=1375381558; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RX7a/8Id9+bjZQ7t/YqegW7Oxnt5fP0FW0A3jCHFs+k=; b=bR4B6VypD+TqgEPipaRPa0qR7+97T5b7YW8ig8yi/n2Lt9bzFSWxQ7jB /wkGUsOAs2xD4dRxibHlmB3XWITYtMdZ5zkf0bAMkTboqxmT6j1/MnTMM +W5mZO2c7K/5Bhzz1lYYAjQzPEnq/IiiP03mMpDYewQAP+/SjAAFx7aTX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFACoy6FGtJV2d/2dsb2JhbABagwY1UMBDgRIWdIIkAQEBAQIBeQULAgEIIh0HMhQRAgQOBQiIAga2RI9cAjEHgw5uA4hwoDqDEoIq X-IronPort-AV: E=Sophos;i="4.89,695,1367971200"; d="scan'208";a="236545505" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 18 Jul 2013 18:25:54 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6IIPsR4012361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 18:25:54 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.173]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 13:25:54 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: Status of DLEP Thread-Index: AQHOgTSZ4NiFmtMsgUClXjAUc7+jmZlrGeGA Date: Thu, 18 Jul 2013 18:25:53 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1019421A@xmb-aln-x03.cisco.com> References: <51E3B17A.3000205@fkie.fraunhofer.de> In-Reply-To: <51E3B17A.3000205@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <66375D0E42917A4CB1F6BFF537499A8F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Status of DLEP 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, 18 Jul 2013 18:26:10 -0000 Henning,=20 Unfortunately, no. To be honest, I've just been swamped at work. However, I= 'd like to get some time with you and other interested parties sometime dur= ing the week, and discuss next-steps (just to make sure we're all on the sa= me page).=20 Regards, Stan On Jul 15, 2013, at 4:23 AM, Henning Rogge wrote: > Hi, >=20 > I was wondering what is the status of the next DLEP draft. No new draft f= or this IETF? No presentation about DLEP? >=20 > 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 >=20 From henning.rogge@fkie.fraunhofer.de Thu Jul 18 23:19: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 D23DF21E8054 for ; Thu, 18 Jul 2013 23:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 A5d+iyKX1fdY for ; Thu, 18 Jul 2013 23:19:21 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 405D521E809E for ; Thu, 18 Jul 2013 23:19:20 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V042B-0007dd-H6; Fri, 19 Jul 2013 08:19:19 +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 1V042B-0005Gp-ER; Fri, 19 Jul 2013 08:19:19 +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; Fri, 19 Jul 2013 08:19:19 +0200 Message-ID: <51E8DA5F.6040803@fkie.fraunhofer.de> Date: Fri, 19 Jul 2013 08:19:11 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <51E3B17A.3000205@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C1019421A@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C1019421A@xmb-aln-x03.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070909070500000500010500" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17533/Fri Jul 19 06:41:14 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 71f20a6753145be45d3fd9933e2b2e69 Cc: "manet@ietf.org" Subject: Re: [manet] Status of DLEP 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, 19 Jul 2013 06:19:26 -0000 --------------ms070909070500000500010500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I think both a meeting to discuss next-steps AND a discussion at the=20 working group meeting would be a good idea. DLEP is an important piece in the puzzle to integrate modern radios into = heterogeneous networks. Henning On 07/18/2013 08:25 PM, Stan Ratliff (sratliff) wrote: > Henning, > > Unfortunately, no. To be honest, I've just been swamped at work. > However, I'd like to get some time with you and other interested > parties sometime during the week, and discuss next-steps (just to > make sure we're all on the same page). > > Regards, Stan > > On Jul 15, 2013, at 4:23 AM, Henning Rogge > wrote: > >> Hi, >> >> I was wondering what is the status of the next DLEP draft. No new >> draft for this IETF? No presentation about DLEP? >> >> Henning Rogge -- Diplom-Informatiker Henning Rogge , >> Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und >> Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, >> 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 >> 9435 685 mailto:henning.rogge@fkie.fraunhofer.de >> http://www.fkie.fraunhofer.de >> > --=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 --------------ms070909070500000500010500 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 Fw0xMzA3MTkwNjE5MThaMCMGCSqGSIb3DQEJBDEWBBT9JPwsdBQ3Ao089C2lFM7v8E5xsjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAK5sTT3zlfICtaLUys/4r/X3OSgMcQy1H7vjbFAUhu9lS pQ6GLN4/yWB9H0l7RyD/Q5QG3oIl5Tab3420Rn7LDm92fQB/YC/VpjE5uJTKUm1hu384GQRV zOTHqDVn2OmlNkHOL0N3seFOIcsNtr8Oawq8LB7XY9vb1WjE8aWXvpf83iN3MIB+svYsMT5D VZCv/ClsEO2TAKM+K8IOjskbU4VXsadNyJney9punGDXxdwFizzBqOsik6XmIUYuJPl3JARz lPoarNN7GqriV/3Z+8jpsnanbyEAxHE6Ol2kKtSG1zg0RvOQGroWU/Ba8bt9VW38OUwgng+E IMkK2T/9dgAAAAAAAA== --------------ms070909070500000500010500-- From sratliff@cisco.com Fri Jul 19 07:01:20 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 4880521E80CF for ; Fri, 19 Jul 2013 07:01:20 -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 I2RguC4wQcoR for ; Fri, 19 Jul 2013 07:01:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0621E80C0 for ; Fri, 19 Jul 2013 07:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1837; q=dns/txt; s=iport; t=1374242475; x=1375452075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iPiFh1DEyHSqf6ekovN5fPdWS5u9gWNW17oF1K7rbQg=; b=LiFMurXJgbFjvkalW0XHbw9GlN7hUcl6ZZyQe4dbWdTQVG5XXSuAwYaC 8zXItDGN4D5EctQvH/iDgDsTQbRdNBdhd+rI9EoE6UH0z+vWEEcL3bIBc 159PqJW9vveuHlBRsyCII5SEyobNkdq5GmCXI6O0+Sqov5Y5SOO7CTQG1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFVF6VGtJXG8/2dsb2JhbABbgwY1UMBGgQ8WdIIkAQEBAwF5BQsCAQgYCh0HMhQRAgQOBQiIAga3F49cAjEHgxBuA6kqgxKCKg X-IronPort-AV: E=Sophos;i="4.89,701,1367971200"; d="scan'208";a="236943069" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 19 Jul 2013 14:01:14 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6JE1ELG016223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 14:01:14 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.173]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 09:01:13 -0500 From: "Stan Ratliff (sratliff)" To: Henning Rogge Thread-Topic: Status of DLEP Thread-Index: AQHOgTSZ4NiFmtMsgUClXjAUc7+jmZlrGeGAgADHS4CAAIEXgA== Date: Fri, 19 Jul 2013 14:01:13 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10195A0A@xmb-aln-x03.cisco.com> References: <51E3B17A.3000205@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C1019421A@xmb-aln-x03.cisco.com> <51E8DA5F.6040803@fkie.fraunhofer.de> In-Reply-To: <51E8DA5F.6040803@fkie.fraunhofer.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] Status of DLEP 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, 19 Jul 2013 14:01:20 -0000 Henning,=20 A slot at the WG meeting HAD already been requested=85 ;-) So, we're on th= e same page.=20 Regards, Stan On Jul 19, 2013, at 2:19 AM, Henning Rogge wrote: > Hi, >=20 > I think both a meeting to discuss next-steps AND a discussion at the work= ing group meeting would be a good idea. >=20 > DLEP is an important piece in the puzzle to integrate modern radios into = heterogeneous networks. >=20 > Henning >=20 > On 07/18/2013 08:25 PM, Stan Ratliff (sratliff) wrote: >> Henning, >>=20 >> Unfortunately, no. To be honest, I've just been swamped at work. >> However, I'd like to get some time with you and other interested >> parties sometime during the week, and discuss next-steps (just to >> make sure we're all on the same page). >>=20 >> Regards, Stan >>=20 >> On Jul 15, 2013, at 4:23 AM, Henning Rogge >> wrote: >>=20 >>> Hi, >>>=20 >>> I was wondering what is the status of the next DLEP draft. No new >>> draft for this IETF? No presentation about DLEP? >>>=20 >>> Henning Rogge -- Diplom-Informatiker Henning Rogge , >>> Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und >>> Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, >>> 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 >>> 9435 685 mailto:henning.rogge@fkie.fraunhofer.de >>> http://www.fkie.fraunhofer.de >>>=20 >>=20 >=20 >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 From henning.rogge@fkie.fraunhofer.de Sun Jul 21 22:31:14 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 B0C8121F95EF for ; Sun, 21 Jul 2013 22:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 FHhYcUZhg89t for ; Sun, 21 Jul 2013 22:31:09 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 21DE621F9FDE for ; Sun, 21 Jul 2013 22:31:08 -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 1V18i7-0001Iv-LP; Mon, 22 Jul 2013 07:31:03 +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 1V18i7-0003ae-In; Mon, 22 Jul 2013 07:31:03 +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; Mon, 22 Jul 2013 07:31:03 +0200 Message-ID: <51ECC391.9070703@fkie.fraunhofer.de> Date: Mon, 22 Jul 2013 07:30:57 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Stan Ratliff (sratliff)" References: <51E3B17A.3000205@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C1019421A@xmb-aln-x03.cisco.com> <51E8DA5F.6040803@fkie.fraunhofer.de> <2ED1D3801ACAAB459FDB4EAC9EAD090C10195A0A@xmb-aln-x03.cisco.com> In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10195A0A@xmb-aln-x03.cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050400060700090204060703" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17549/Mon Jul 22 06:43:04 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e39381ef53debe75338dede4cc492f79 Cc: "manet@ietf.org" Subject: Re: [manet] Status of DLEP 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, 22 Jul 2013 05:31:14 -0000 --------------ms050400060700090204060703 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 07/19/2013 04:01 PM, Stan Ratliff (sratliff) wrote: > Henning, > > A slot at the WG meeting HAD already been requested=85 ;-) So, we're o= n the same page. Good to hear this... 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 --------------ms050400060700090204060703 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 Fw0xMzA3MjIwNTMxMDJaMCMGCSqGSIb3DQEJBDEWBBSSQ+1Vh9pz5pSC+dSB6Ehj8nEARTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAdXzt60Kw/U/mnPPZXoH3CrLZwydm1u4nssZi8HA1R31A y13psnmVuSz+AlobBJLwAHI1/yyEaI2xHV+SN0/+HaCRVUjrK3gSAG+oYBuau/0fg3aQ63eQ aBNlug8Cpx3Cgz9EgRG9DAla38uC+EimQQ/fPUf0nIFyHtQh1Rc1A55W2JuRCWi2HvLgnqg2 mxcyHJqNEJjk5iSZWULbOHRi1IM5RmKdKkySTP7DRu0qTU9ljQ+Fbuq1p64qsOF2OIdMuBPm Ikc3vqmaKLJH+goL+Qkb76/ldGYC1vfzRVh+N/Aopy3T3Dw435JqFoxQ5wIRlz4E0/V0mgYA WMgWcB+eLQAAAAAAAA== --------------ms050400060700090204060703-- From henning.rogge@fkie.fraunhofer.de Mon Jul 22 02:15:38 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 5B2C221E80A8 for ; Mon, 22 Jul 2013 02:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 0CMSdGEmhaNq for ; Mon, 22 Jul 2013 02:15:28 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 81B1F21E80B2 for ; Mon, 22 Jul 2013 02:07:24 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1V1C5D-0006TA-Hi; Mon, 22 Jul 2013 11:07:07 +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 1V1C5D-0005Eh-F5; Mon, 22 Jul 2013 11:07:07 +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; Mon, 22 Jul 2013 11:07:07 +0200 Message-ID: <51ECF637.8050006@fkie.fraunhofer.de> Date: Mon, 22 Jul 2013 11:07:03 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060101050908050705090201" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17549/Mon Jul 22 06:43:04 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 64043460effe25529ce3256a788b0513 Cc: "Emmanuel Baccelli \(Emmanuel.Baccelli@inria.fr\)" , "manet@ietf.org" Subject: Re: [manet] ETT metrics draft 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, 22 Jul 2013 09:15:38 -0000 --------------ms060101050908050705090201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I finally had the time to work through the set of reviews from last week.= My comments are inline below. Comments inline On 07/15/2013 12:14 PM, Dearlove, Christopher (UK) wrote: > I have just managed to find time for a quick look over version -02 of > the ETT metric draft. A few comments (I omit editorial comments, such > as consistency of use of capitalisation of Link Tuple for a later > draft). > > Section 1 > > Would be useful context to note that adding metrics to OLSRv1 > produced a proprietary extension to RFC 3626. > > The Introduction should provide a bit more OLSrv2 context. > > Section 3 > > Refers to [RFC3626] implementation. This is extended as noted above, > which I think is important to applicability. I think we will have to work more on Section 1/3, maybe pushing the=20 whole "OLSr.org history" part to a section of its own so we can focus=20 more on OLSRv2 section 1/3? > The use of control message loss rate on Wi-Fi (IEEE 802.11) has the > issue that the control messages are sent broadcast, the data will be > sent unicast. There's the well-known "grey zone" problem here that is > usually solved with link quality (when using OLSRv1 with hop counts). > It may well be that in practice things work, but there is an issue > here that I think needs discussion. Normally the IP packet loss of the broadcast messages seems to be higher = than the IP packet loss of unicasts because of the retransmissions. OLSR.org had a "link quality" implementation (as defined in RFC 3626)=20 even before the ETX code, but the link quality didn't helped to=20 stabilize the network. > Section 5 > > The use of packet sequence numbers relies on an erratum to RFC 5444. > Do we assume everyone reads errata, or should this be commented on? That was the reason why I explicitly stated what kind of packet sequence = number this draft needs. Maybe we could mention that this requirement=20 was also added in the errata. > There's a metric normalisation issue for OLSRv2 (this divided by that > - scaled?). The "scaling" of this ETT metric has been chosen to be useful with WIFI=20 (802.11) speed. > Section 6 > > ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have > used something similar in link quality calculations) then it should > be only slightly larger than 1.0, which is worth saying. But not too small, otherwise a message aggregation timer might become a=20 problem. > Section 7 > > Here reading through I made a note thatr INTERVAL_TIME TLVs are > optional. This is discussed later. But I think a section earlier on > this may be appropriate. That section could also discuss entity > relationships I'll get to below. The order of "things to consider" is a bit off... > Section 9 > > At the WG's requirement, we have been careful to divide up different > entities with different responsibilities, and controlled ways in > which they may interoperate. This has required some care at times. I > don't think this draft has put the same care in. > > There are three entities: The RFC 5444 packet multiplexer (and > demultiplexer), NHDP and OLSRv2. So for example OLSRv2 does not put > in a packet sequence number. OLSRv2 requests the 5444 multiplexer to > add a packet sequence number. Likewise how OLSRv2 interacts with > HELLO messages needs care, see OLSRv2 draft for how LINK_METRIC and > MPR TLVs are handled. (I have implemented this similarly in my OLSRv2 code) > But this is more complicated than that. Because we are considering > haps in packet sequence numbers, that means all packets need to be > considered. Yes. > That could include packets containing neither HELLO > messages nor TC messages, which normally neither NHDP nor OLSRv2 will > see. (They get reported their messages, and can access related packet > information.) This is therefore in part a function interacting > directly with the 5444 multiplexer, Yes. > which is new, and we (WG, if this > is adopted) should be clear on how to handle that - or someone (in > the IESG if not sooner) will ask many difficult questions. I think we should handle this in a similar way than any extension that=20 adds/reads packet level TLVs. > Related to > that is whether this extends NHDP, but is used by an extension to > OLSRv2, or extends just OLSRv2, and is solely defined in that > context. Thats a bit tricky... metrics are defined in OLSRv2 but are an extension = for NHDP... and metrics can be useful in NHDP even without using OLSRv2. > Section 9.2 > > When it says "packets without packet sequence number MUST NOT be > processed, that's not quite right in terms of the 5444/NHDP/OLSRv2 > model, as discussed above. Also not clear from this wording that you > just mean for purpose of metric calculation. "MUST NOT be process for metric calculation as described below" ? > Section 9.2/9.3 (or other for resolution) > > Need a bit more clarity on what to do if you don't get helpful input > (missing PSN or INTERVAL_T IMETLV). You still need a metric if the > Link Tuple is on an OLSRv2 interface, obviously maximum, but that's > only said in the processing, not in the can't process part. Easiest way would be to ignore the whole Hello timer. The problem is=20 that the metric would not increase if contact to the neighbor is=20 suddenly lost. > Section 11 > > Looking at the L_in_metric calculation, is that calculation going to > produce a value in the range 1 to MAXIMUM_METRIC? (I don't have time > right now to check that). At the moment the range I use is 2^4 (256+ MBit/s, ETX 1.0) to 2^16 (1=20 Mbit/s, ETX 16). > Even if it does, needs comment about > rounding/truncating to a representable value (note that L_in_metric > must be representable, it's in the OLSRv2 constraints this is bound > by). I do this already in code, but maybe its worth adding to the draft that=20 the metric should be set to the nearest metric value that can be=20 represented in the compressed format defined in OLSRv2. > Section 12 > > These are possibly suitable values for Wi-Fi. That may be fine for > Funkfeuer, but if this is adapted as a WG document we need to be more > general that that., and to separate what's specific to that and what > isn't. We need to be able to understand that if, for example, I want > to use this on a system that varies between say 1 kbit/s and 256 > kbit/s, what other parameters change? If we change the parameters to extend the metric range to MINIMUM_METRIC = to MAXIMUM_METRIC, we could transport a linkspeed from 16 bit/s to 4 Gbit= /s. > Section 14 > > Suggest referencing the NHDP/OLSRv2 integrity draft. I will do so. 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 --------------ms060101050908050705090201 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 Fw0xMzA3MjIwOTA3MDZaMCMGCSqGSIb3DQEJBDEWBBTRq4tu9xwvRIvRFcAqAwwCWP6exDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAarGLPYPzMO7Vspnhc8/gJGxNFJE6MDYHayt7K8vN8GeA EiliRrMDu9AKEZ9Qcd8LQNkWP8ecOAoRM6CRq3XTyVueLfQwDMQceJwzAYA+HVQ+Fc+fNYkS h1LrwUlzTowaH0miO/xwx240pRGLM42vmmESSq3u9E6TliNhdrWJdvSE7vlZOCVdjOcRrqmG Yuk56lQwx6ZRfrjESRPgREB25oZMlDztPfrSqH8xce38g9PVu9j7rjTIP+ltnvGBPGRVA3Y0 pWWlPtUhiXzHJUM8vbza5U4mMAfB5KvH+OJ1j8ojhtlc51zf1EwLp5r19i8/g9Mlpqs10M1q P71LhkFdRQAAAAAAAA== --------------ms060101050908050705090201-- From henning.rogge@fkie.fraunhofer.de Mon Jul 22 02:17:20 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 7BA1111E810D for ; Mon, 22 Jul 2013 02:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 9Sewu+Eq4mak for ; Mon, 22 Jul 2013 02:17:05 -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 67A3C11E810A for ; Mon, 22 Jul 2013 02:09:08 -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 1V1C70-0006Vk-A6 for manet@ietf.org; Mon, 22 Jul 2013 11:08:58 +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 1V1C70-0005FJ-7b for manet@ietf.org; Mon, 22 Jul 2013 11:08:58 +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; Mon, 22 Jul 2013 11:08:58 +0200 Message-ID: <51ECF6A9.9070405@fkie.fraunhofer.de> Date: Mon, 22 Jul 2013 11:08:57 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000202060309040308060101" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17549/Mon Jul 22 06:43:04 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 324d8966091bca9045707e25a905f109 Subject: Re: [manet] ETT metrics draft 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, 22 Jul 2013 09:17:20 -0000 --------------ms000202060309040308060101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 07/16/2013 06:56 PM, Justin Dean wrote: > I've also had a little bit of time to look over the draft. My comments > at this point are more general than Chris' were. I found the draft > overly confusing. The was an ok summary of what the metric is supposed > to do, but the it jumps right into details. Do you think we need a chapter that describes the ETT metric in more=20 abstract terms as a step between the introduction and the metric=20 calculation description? > Without a good idea of how > things are supposed to work the variable descriptions just add to the > confusion. I don't think it needs to be this complicated, in fact I > find it worrisome that I wasn't able to more easily figure out how I > would start implementing it. I'll provide more detailed feedback and > possible text when I can find some cycles. 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 --------------ms000202060309040308060101 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 Fw0xMzA3MjIwOTA4NTdaMCMGCSqGSIb3DQEJBDEWBBReAxOhO3Low3IGAhmq+MOXl+cZ9TBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAwm63MtoqvRbqDxT2A0x20Cu3GaKw1Z30B6Tp7yH4Sqt7 ymxv0yBZNRtVXZb3cr4gao4ZymLkwxlZfZ6bBA1Q7W5orrKkIMMiudDcyqfnfED5G208YsKz i+DRZ5JkwfqxCmbPO5ecm8Z7nSEIlwvfKz2sX5/y1RJH0gbzhYUk5uWWq9XUuucXq0O655HW Y/2varXRfxfOtDbyHqF+gUuLonCgURHnsqn8Bvu3UQutVfth2/pPPl/twj/hfTdRb3kWwjJj /eQl5Saxz0garF+XZMYlEWTt2a7CcQcd7O8hwgNerumlL6kgy2T/EPIuzVrpsqnUmgTroXKf A/93yH1N0gAAAAAAAA== --------------ms000202060309040308060101-- From henning.rogge@fkie.fraunhofer.de Mon Jul 22 02:23:55 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 AD5FB21F855F for ; Mon, 22 Jul 2013 02:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[AWL=-0.571, 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 OeX2QBJff7-y for ; Mon, 22 Jul 2013 02:23:49 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id C02CD21F848E for ; Mon, 22 Jul 2013 02:14:54 -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 1V1CCk-0008BN-4F for manet@ietf.org; Mon, 22 Jul 2013 11:14:54 +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 1V1CCk-0005Kb-1g for manet@ietf.org; Mon, 22 Jul 2013 11:14:54 +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; Mon, 22 Jul 2013 11:14:54 +0200 Message-ID: <51ECF80C.4050003@fkie.fraunhofer.de> Date: Mon, 22 Jul 2013 11:14:52 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020402090101090605050905" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.97.8/17549/Mon Jul 22 06:43:04 2013) by a.mx.fkie.fraunhofer.de X-Scan-Signature: e565a2c6194577b4a33546026e9f1a7b Subject: Re: [manet] ETT metrics draft 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, 22 Jul 2013 09:23:55 -0000 --------------ms020402090101090605050905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 07/16/2013 11:29 PM, Ulrich Herberg wrote: > Hi, > > I have also reviewed the draft. Since it's an early draft, just some > high-level comments: > - I like the idea of specifying the ETT metrics and I hope you will > issue a new revision. We definitely will. Expect a new revision in the week after the IETF=20 meeting. > - The introduction is a bit confusing. It talks about the Funkfeuer > networks, and then suddenly jumps into details about ETT metric. I > would suggest to focus the document on the metric itself, and > mentioning the Funkfeuer networks only in the appendix. Maybe a "history" appendix that explains where the ETX part of the=20 metric comes from? > I also wonder > why the intended status is informational? Shouldn't it be Experimental > or Standards Track, since a protocol extension is specified? Good question, I am not sure about this but I am open for advise. > - section 3 (Applicability); again, I would defocus on the Funkfeuer= > networks, just mention in general the use cases where the metric is > useful. You should focus more on OLSRv2 itself, IMO. > - same section: "ETX metric that was used in the earlier [RFC3626] > implementation". Note that RFC3626 only uses hop-count, so technically > the olsr.org implementation was not RFC3626 compliant Yes. > - section 7: Since the link tuples are extended, does that mean that= > draft-ietf-manet-olsrv2 is "updated" (in the IETF sense)? If so, the > draft does not say that in the header, nor mention that in the > introduction and abstract. I wrote the link tuple extension as a way to have "link specific" data=20 stored for the metric. Do you think it would be better to put this into=20 a database described in this draft? > I assume that an informational document > could also not do that. > - "L_ETT_last_pkt_seqno is the last received packet sequence number > received from this link." Shouldn't there some section somewhere to > describe requirements, such as access to lower layers (e.g., packet > sequence numbers)? I don't consider packet sequence numbers as a different layer. Its a=20 different interface to the rfc5444 (de)multiplexer, but its still in the = same layer. We use IP addresses from the IP header in NHDP/OLSRv2 without worrying=20 about "lower layer access" too. > - section 9 mixes a bit the different layers (RFC5444 and RFC6130). I= > wonder if that could not be more separated. Hmm. > - some lower case "must" in section 9; should that be 2119 or not? Will have to look at this. > - section 13: Shouldn't that be a new link metric type allocation? > How is the metric used in the OLSRv2 network? Not sure if we want to allocate metric TLV extensions for specific=20 metric types. > - why is OLSRv2 only an informative reference? Can there be normative= > references in an Informational document? I thought only RFCs can be a normative reference, but my knowledge about = rfc types and references types in them is a bit limited. 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 --------------ms020402090101090605050905 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 Fw0xMzA3MjIwOTE0NTJaMCMGCSqGSIb3DQEJBDEWBBT6Cb2Emf+c3V1z6jT2+fAx+1HkEzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAvoVsgixX0Luhb+MlPCH+D2aY+v1KuXZQX4rOVzbmKw0k fTvNG1FuCzPQYDYnLuf/KwwbEBBejZPtuNUVNog87LMWGU65ihv1alraJWf2WBU1BhHPXiuk +0n5P/UYJWPeefAzPcmJYMEea2iMlPIInFFOCx8UjF29ROZ+8vWhX5uZEH1LcmyLo2SR5/nX 1ih1FBNODh56xp7h6Tjm875kcrIero30F0uha7vgjg7duVuAwsw+SMfLrGg/1BGob3ZcqYkI /WlGLnGvRlxRDS1ZyEVCsI+rAkWPflWt3XIvWHfP9rqfToP/PSmZaseTMpu2Ze+LmDF4nl/a aaXhQrhyvgAAAAAAAA== --------------ms020402090101090605050905-- From christopher.dearlove@googlemail.com Mon Jul 22 05:28: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 B4AB221F9A99 for ; Mon, 22 Jul 2013 05:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.581 X-Spam-Level: X-Spam-Status: No, score=-0.581 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_QP_LONG_LINE=1.396] 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 WoiGwCbzrNfj for ; Mon, 22 Jul 2013 05:28:49 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4CE21F9D87 for ; Mon, 22 Jul 2013 05:28:48 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id ey16so1807936wid.15 for ; Mon, 22 Jul 2013 05:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=LLxhrP2ZZKM+0kUyCMXhwCJ/rvjOseZxPDRjq0AR0kQ=; b=n4b0nDwit2GfwaahMXyi5CIjSS0wrovcXW7MJ2D5iMyUL1LRp8cHgecXhm3EMDkxvy yVz9UNrhT4yeF0Iin5AXjVfmoGejPNJBaJh6m65YD+m51cQwtGVSTFw/i8u86chfsxYz P6TIy2/D8W4hnX9/zy4MXk6d0mApNIoqTgWAxwX2QvyqsptTDEI+a+Dinl+jw+pBvTDv rApYxsWaJMLym6e/a6ZyWb0Und3KvR6yd30uwipBGIvGjs7ahi5umdp6sFraGXIOyvg4 W38t4NirMjRUzB6nuv5a30iqo6WB/6aQY/iDc3zP6E6G4nsGsVQpMn81aOYmNTxQiUVk heIw== X-Received: by 10.180.9.212 with SMTP id c20mr29445854wib.65.1374496128283; Mon, 22 Jul 2013 05:28:48 -0700 (PDT) Received: from [10.23.254.57] (dab-crx1-h-87-1.dab.02.net. [82.132.224.219]) by mx.google.com with ESMTPSA id o10sm40349753wiz.5.2013.07.22.05.28.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 05:28:47 -0700 (PDT) References: <51ECF637.8050006@fkie.fraunhofer.de> In-Reply-To: <51ECF637.8050006@fkie.fraunhofer.de> Mime-Version: 1.0 (iPhone Mail 8B117) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <32877AE0-2F5A-4C34-B3CC-B83762BB9A9B@gmail.com> X-Mailer: iPhone Mail (8B117) From: Christopher Dearlove Date: Mon, 22 Jul 2013 13:29:04 +0100 To: Henning Rogge Cc: "Dearlove, Christopher \(UK\)" , "Emmanuel Baccelli \(Emmanuel.Baccelli@inria.fr\)" , "manet@ietf.org" Subject: Re: [manet] ETT metrics draft 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, 22 Jul 2013 12:28:50 -0000 Our experience with link quality differs. It's not the loss rate, it's that m= aximum broadcast range is greater than unicast range (lower data rate). So n= eed to exclude links whose SNR suggests too long or poor. And this improved p= erformance (provided sufficiently dense network). -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) On 22 Jul 2013, at 10:07, Henning Rogge w= rote: > Hi, >=20 > I finally had the time to work through the set of reviews from last week. >=20 > My comments are inline below. >=20 > Comments inline >=20 > On 07/15/2013 12:14 PM, Dearlove, Christopher (UK) wrote: >> I have just managed to find time for a quick look over version -02 of >> the ETT metric draft. A few comments (I omit editorial comments, such >> as consistency of use of capitalisation of Link Tuple for a later >> draft). >>=20 >> Section 1 >>=20 >> Would be useful context to note that adding metrics to OLSRv1 >> produced a proprietary extension to RFC 3626. >>=20 >> The Introduction should provide a bit more OLSrv2 context. >>=20 >> Section 3 >>=20 >> Refers to [RFC3626] implementation. This is extended as noted above, >> which I think is important to applicability. >=20 > I think we will have to work more on Section 1/3, maybe pushing the whole "= OLSr.org history" part to a section of its own so we can focus more on OLSRv= 2 section 1/3? >=20 >> The use of control message loss rate on Wi-Fi (IEEE 802.11) has the >> issue that the control messages are sent broadcast, the data will be >> sent unicast. There's the well-known "grey zone" problem here that is >> usually solved with link quality (when using OLSRv1 with hop counts). >> It may well be that in practice things work, but there is an issue >> here that I think needs discussion. >=20 > Normally the IP packet loss of the broadcast messages seems to be higher t= han the IP packet loss of unicasts because of the retransmissions. >=20 > OLSR.org had a "link quality" implementation (as defined in RFC 3626) even= before the ETX code, but the link quality didn't helped to stabilize the ne= twork. >=20 >> Section 5 >>=20 >> The use of packet sequence numbers relies on an erratum to RFC 5444. >> Do we assume everyone reads errata, or should this be commented on? >=20 > That was the reason why I explicitly stated what kind of packet sequence n= umber this draft needs. Maybe we could mention that this requirement was als= o added in the errata. >=20 >> There's a metric normalisation issue for OLSRv2 (this divided by that >> - scaled?). >=20 > The "scaling" of this ETT metric has been chosen to be useful with WIFI (8= 02.11) speed. >=20 >> Section 6 >>=20 >> ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have >> used something similar in link quality calculations) then it should >> be only slightly larger than 1.0, which is worth saying. >=20 > But not too small, otherwise a message aggregation timer might become a pr= oblem. >=20 >> Section 7 >>=20 >> Here reading through I made a note thatr INTERVAL_TIME TLVs are >> optional. This is discussed later. But I think a section earlier on >> this may be appropriate. That section could also discuss entity >> relationships I'll get to below. >=20 > The order of "things to consider" is a bit off... >=20 >> Section 9 >>=20 >> At the WG's requirement, we have been careful to divide up different >> entities with different responsibilities, and controlled ways in >> which they may interoperate. This has required some care at times. I >> don't think this draft has put the same care in. >>=20 >> There are three entities: The RFC 5444 packet multiplexer (and >> demultiplexer), NHDP and OLSRv2. So for example OLSRv2 does not put >> in a packet sequence number. OLSRv2 requests the 5444 multiplexer to >> add a packet sequence number. Likewise how OLSRv2 interacts with >> HELLO messages needs care, see OLSRv2 draft for how LINK_METRIC and >> MPR TLVs are handled. >=20 > (I have implemented this similarly in my OLSRv2 code) >=20 >> But this is more complicated than that. Because we are considering >> haps in packet sequence numbers, that means all packets need to be >> considered. >=20 > Yes. >=20 > > That could include packets containing neither HELLO >> messages nor TC messages, which normally neither NHDP nor OLSRv2 will >> see. (They get reported their messages, and can access related packet >> information.) This is therefore in part a function interacting >> directly with the 5444 multiplexer, >=20 > Yes. >=20 > > which is new, and we (WG, if this >> is adopted) should be clear on how to handle that - or someone (in >> the IESG if not sooner) will ask many difficult questions. >=20 > I think we should handle this in a similar way than any extension that add= s/reads packet level TLVs. >=20 > > Related to >> that is whether this extends NHDP, but is used by an extension to >> OLSRv2, or extends just OLSRv2, and is solely defined in that >> context. >=20 > Thats a bit tricky... metrics are defined in OLSRv2 but are an extension f= or NHDP... and metrics can be useful in NHDP even without using OLSRv2. >=20 >> Section 9.2 >>=20 >> When it says "packets without packet sequence number MUST NOT be >> processed, that's not quite right in terms of the 5444/NHDP/OLSRv2 >> model, as discussed above. Also not clear from this wording that you >> just mean for purpose of metric calculation. >=20 > "MUST NOT be process for metric calculation as described below" ? >=20 >> Section 9.2/9.3 (or other for resolution) >>=20 >> Need a bit more clarity on what to do if you don't get helpful input >> (missing PSN or INTERVAL_T IMETLV). You still need a metric if the >> Link Tuple is on an OLSRv2 interface, obviously maximum, but that's >> only said in the processing, not in the can't process part. >=20 > Easiest way would be to ignore the whole Hello timer. The problem is that t= he metric would not increase if contact to the neighbor is suddenly lost. >=20 >> Section 11 >>=20 >> Looking at the L_in_metric calculation, is that calculation going to >> produce a value in the range 1 to MAXIMUM_METRIC? (I don't have time >> right now to check that). >=20 > At the moment the range I use is 2^4 (256+ MBit/s, ETX 1.0) to 2^16 (1 Mbi= t/s, ETX 16). >=20 > > Even if it does, needs comment about >> rounding/truncating to a representable value (note that L_in_metric >> must be representable, it's in the OLSRv2 constraints this is bound >> by). >=20 > I do this already in code, but maybe its worth adding to the draft that th= e metric should be set to the nearest metric value that can be represented i= n the compressed format defined in OLSRv2. >=20 >> Section 12 >>=20 >> These are possibly suitable values for Wi-Fi. That may be fine for >> Funkfeuer, but if this is adapted as a WG document we need to be more >> general that that., and to separate what's specific to that and what >> isn't. We need to be able to understand that if, for example, I want >> to use this on a system that varies between say 1 kbit/s and 256 >> kbit/s, what other parameters change? >=20 > If we change the parameters to extend the metric range to MINIMUM_METRIC t= o MAXIMUM_METRIC, we could transport a linkspeed from 16 bit/s to 4 Gbit/s. >=20 >> Section 14 >>=20 >> Suggest referencing the NHDP/OLSRv2 integrity draft. >=20 > I will do so. >=20 > Henning Rogge >=20 > --=20 > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=C3=BCr > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Fraunhofer Stra=C3=9Fe 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-961, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Mon Jul 22 07:58:46 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 AC87511E80AE for ; Mon, 22 Jul 2013 07:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.025, 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 uIvluI-tmzQr for ; Mon, 22 Jul 2013 07:58:41 -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 62DB121F9970 for ; Mon, 22 Jul 2013 07:58:41 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id p13so4791109vbe.14 for ; Mon, 22 Jul 2013 07:58:39 -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=gHVUqTk7ta/oR6GrVV8zZKxXyMtojgEdmDy3t7ukvFw=; b=vVYvXv+lu2mGC/qr7NwWVIftYDWNuOtnhOdu65lsm4f2kbCkGH9YlvXwle4jSvp4eF GF+Y+Z95d+9XoT/ltYuplq+GstydbbP/b6JEjZYJlRYpxy8EJEfGCTW5GZj5hLnULuWg 7SF9OioVdlmoRpoe9+sEE2j4gM5CF9m5jxO4o= 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=gHVUqTk7ta/oR6GrVV8zZKxXyMtojgEdmDy3t7ukvFw=; b=Y8I/bIWiM6SjVBft+6qlDXUCYKuqtjDU6J2/vHfCon3+EZJaeX+R7QIBTTofD5sErc MOFRsP1x8WNuC3z3ue3/S6/Hi9/yHaV4xhKcEzFvyQcGVjdScM7c5Y2gTqO91GReYjES s4uDCa6UptbRJlOCJIEe06R/SiH31IbXyaX+oUkVbsHv/I2Qwnkgnn5uik+5rfYFoN2N kGW8UWWmgVauCs1Ax8xMPMbnDu+4rbDCAaZ36UZ6bmxdf0yi7HRQkYk3uzqpL5G0o3Mm +6m/ZdeCYfTegzF3tiC8DgUKPShz0nhgWxEepUHa+53Spqt3thRM10aG32XFkKkIofsi cxPw== MIME-Version: 1.0 X-Received: by 10.52.94.6 with SMTP id cy6mr7844147vdb.108.1374505119416; Mon, 22 Jul 2013 07:58:39 -0700 (PDT) Received: by 10.221.55.70 with HTTP; Mon, 22 Jul 2013 07:58:39 -0700 (PDT) In-Reply-To: <51ECF80C.4050003@fkie.fraunhofer.de> References: <51ECF80C.4050003@fkie.fraunhofer.de> Date: Mon, 22 Jul 2013 07:58:39 -0700 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlBKW0yttk7U+CpLYacLpXQhDnGip0fMrp3oHSAn2YgHK3rHlbEE64rL+QpZ2iw63JjyZsM Cc: manet@ietf.org Subject: Re: [manet] ETT metrics draft 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, 22 Jul 2013 14:58:46 -0000 Henning, thanks for your reply. See below: On Mon, Jul 22, 2013 at 2:14 AM, Henning Rogge wrote: > On 07/16/2013 11:29 PM, Ulrich Herberg wrote: >> >> Hi, >> >> I have also reviewed the draft. Since it's an early draft, just some >> high-level comments: >> - I like the idea of specifying the ETT metrics and I hope you will >> issue a new revision. > > > We definitely will. Expect a new revision in the week after the IETF > meeting. Good! > > >> - The introduction is a bit confusing. It talks about the Funkfeuer >> networks, and then suddenly jumps into details about ETT metric. I >> would suggest to focus the document on the metric itself, and >> mentioning the Funkfeuer networks only in the appendix. > > > Maybe a "history" appendix that explains where the ETX part of the metric > comes from? Yes, that would be a good idea IMO. >> I also wonder >> >> why the intended status is informational? Shouldn't it be Experimental >> or Standards Track, since a protocol extension is specified? > > > Good question, I am not sure about this but I am open for advise. Let's discuss that during the IETF. >> - section 3 (Applicability); again, I would defocus on the Funkfeuer >> networks, just mention in general the use cases where the metric is >> useful. You should focus more on OLSRv2 itself, IMO. >> - same section: "ETX metric that was used in the earlier [RFC3626] >> implementation". Note that RFC3626 only uses hop-count, so technically >> the olsr.org implementation was not RFC3626 compliant > > > Yes. > > >> - section 7: Since the link tuples are extended, does that mean that >> draft-ietf-manet-olsrv2 is "updated" (in the IETF sense)? If so, the >> draft does not say that in the header, nor mention that in the >> introduction and abstract. > > > I wrote the link tuple extension as a way to have "link specific" data > stored for the metric. Do you think it would be better to put this into a > database described in this draft? After a second thought, I actually think it's fine not to "update" the OLSRv2 spec, since this is an optional extension, and so the information sets in OLSRv2 remain unchanged for implementations not using the ETT extension. >> I assume that an informational document >> >> could also not do that. >> - "L_ETT_last_pkt_seqno is the last received packet sequence number >> received from this link." Shouldn't there some section somewhere to >> describe requirements, such as access to lower layers (e.g., packet >> sequence numbers)? > > > I don't consider packet sequence numbers as a different layer. Its a > different interface to the rfc5444 (de)multiplexer, but its still in the > same layer. > > We use IP addresses from the IP header in NHDP/OLSRv2 without worrying about > "lower layer access" too. I agree that there is some ambiguity. I think such a (short) requirements section could be helpful for implementers to make sure that they can get appropriate information from other layers. But if you think this is self-evident, I am fine if you leave it as is. >> - section 9 mixes a bit the different layers (RFC5444 and RFC6130). I >> wonder if that could not be more separated. > > > Hmm. > > >> - some lower case "must" in section 9; should that be 2119 or not? > > > Will have to look at this. > > >> - section 13: Shouldn't that be a new link metric type allocation? >> How is the metric used in the OLSRv2 network? > > > Not sure if we want to allocate metric TLV extensions for specific metric > types. I thought that this is the purpose of the registry. Let's discuss that during the IETF. >> - why is OLSRv2 only an informative reference? Can there be normative >> references in an Informational document? > > > I thought only RFCs can be a normative reference, but my knowledge about rfc > types and references types in them is a bit limited. Yes, but OLSRv2 needs to be a normative reference for the ETT draft. In case this draft is completed before OLSRv2 becomes an RFC (which I hope not!), then it will be hold in the RFC editor queue until OLSRv2 gets the RFC number. Here is some info about the reference types: http://www.ietf.org/iesg/statement/normative-informative.html Best regards Ulrich From sratliff@cisco.com Mon Jul 22 08:34: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 E2EF111E80EF for ; Mon, 22 Jul 2013 08:34:23 -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 TSrNTGtLnKKL for ; Mon, 22 Jul 2013 08:34:15 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1318D11E80D9 for ; Mon, 22 Jul 2013 08:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8748; q=dns/txt; s=iport; t=1374507255; x=1375716855; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=z9z7am/UXiBKWYk8xZvdrcw1DBPGqeY8VdebgZ0xtuQ=; b=QPfFdJZS38slt/cLw62W4he0JkURIM+HZRK9PUwqxOpqmoFyOqLAJNDg 0kPjED8dtQNTQSs/692+mIPzwohRzm3kITrpHZ8F2ebotzTz0mlWWa35w jVPwKH+XvOy3cwQ4rOA2QXW1aDyU+X7alglb7XYiM94NBLrHVXMUfzzee I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFALhQ7VGtJV2c/2dsb2JhbABagwY1UMAwgRYWdIIkAQEBAwEBAQFrBAcFCwIBCBgKHQchBgsUEQEBBA4FCId2AwkGDK8ADYhejSqCOQILJgeDEG4DiHCLFoFugxKKfoUmgxKCKg X-IronPort-AV: E=Sophos;i="4.89,720,1367971200"; d="scan'208";a="237663520" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 22 Jul 2013 15:34:06 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6MFY5RB006671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 15:34:05 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.173]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 22 Jul 2013 10:34:05 -0500 From: "Stan Ratliff (sratliff)" To: Christopher Dearlove Thread-Topic: [manet] ETT metrics draft Thread-Index: Ac6BQ/wpsZ7j34UuTmyrmons4tyaQAFoMFSAAAcOLAAABnYtgA== Date: Mon, 22 Jul 2013 15:34:05 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C10197118@xmb-aln-x03.cisco.com> References: <51ECF637.8050006@fkie.fraunhofer.de> <32877AE0-2F5A-4C34-B3CC-B83762BB9A9B@gmail.com> In-Reply-To: <32877AE0-2F5A-4C34-B3CC-B83762BB9A9B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.144] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <60B81C4BBC3EB94BB1BA4AC19DD058BF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" , "Dearlove, Christopher \(UK\)" , "Emmanuel Baccelli \(Emmanuel.Baccelli@inria.fr\)" Subject: Re: [manet] ETT metrics draft 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, 22 Jul 2013 15:34:24 -0000 FWIW, I agree with Chris. The difference in the range for broadcast/multica= st vs. unicast is important, as well as the disparity in the data rates for= those traffic types.=20 Regards, Stan On Jul 22, 2013, at 8:29 AM, Christopher Dearlove wrote: > Our experience with link quality differs. It's not the loss rate, it's th= at maximum broadcast range is greater than unicast range (lower data rate).= So need to exclude links whose SNR suggests too long or poor. And this imp= roved performance (provided sufficiently dense network). >=20 > -- =20 > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) >=20 > On 22 Jul 2013, at 10:07, Henning Rogge wrote: >=20 >> Hi, >>=20 >> I finally had the time to work through the set of reviews from last week= . >>=20 >> My comments are inline below. >>=20 >> Comments inline >>=20 >> On 07/15/2013 12:14 PM, Dearlove, Christopher (UK) wrote: >>> I have just managed to find time for a quick look over version -02 of >>> the ETT metric draft. A few comments (I omit editorial comments, such >>> as consistency of use of capitalisation of Link Tuple for a later >>> draft). >>>=20 >>> Section 1 >>>=20 >>> Would be useful context to note that adding metrics to OLSRv1 >>> produced a proprietary extension to RFC 3626. >>>=20 >>> The Introduction should provide a bit more OLSrv2 context. >>>=20 >>> Section 3 >>>=20 >>> Refers to [RFC3626] implementation. This is extended as noted above, >>> which I think is important to applicability. >>=20 >> I think we will have to work more on Section 1/3, maybe pushing the whol= e "OLSr.org history" part to a section of its own so we can focus more on O= LSRv2 section 1/3? >>=20 >>> The use of control message loss rate on Wi-Fi (IEEE 802.11) has the >>> issue that the control messages are sent broadcast, the data will be >>> sent unicast. There's the well-known "grey zone" problem here that is >>> usually solved with link quality (when using OLSRv1 with hop counts). >>> It may well be that in practice things work, but there is an issue >>> here that I think needs discussion. >>=20 >> Normally the IP packet loss of the broadcast messages seems to be higher= than the IP packet loss of unicasts because of the retransmissions. >>=20 >> OLSR.org had a "link quality" implementation (as defined in RFC 3626) ev= en before the ETX code, but the link quality didn't helped to stabilize the= network. >>=20 >>> Section 5 >>>=20 >>> The use of packet sequence numbers relies on an erratum to RFC 5444. >>> Do we assume everyone reads errata, or should this be commented on? >>=20 >> That was the reason why I explicitly stated what kind of packet sequence= number this draft needs. Maybe we could mention that this requirement was = also added in the errata. >>=20 >>> There's a metric normalisation issue for OLSRv2 (this divided by that >>> - scaled?). >>=20 >> The "scaling" of this ETT metric has been chosen to be useful with WIFI = (802.11) speed. >>=20 >>> Section 6 >>>=20 >>> ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have >>> used something similar in link quality calculations) then it should >>> be only slightly larger than 1.0, which is worth saying. >>=20 >> But not too small, otherwise a message aggregation timer might become a = problem. >>=20 >>> Section 7 >>>=20 >>> Here reading through I made a note thatr INTERVAL_TIME TLVs are >>> optional. This is discussed later. But I think a section earlier on >>> this may be appropriate. That section could also discuss entity >>> relationships I'll get to below. >>=20 >> The order of "things to consider" is a bit off... >>=20 >>> Section 9 >>>=20 >>> At the WG's requirement, we have been careful to divide up different >>> entities with different responsibilities, and controlled ways in >>> which they may interoperate. This has required some care at times. I >>> don't think this draft has put the same care in. >>>=20 >>> There are three entities: The RFC 5444 packet multiplexer (and >>> demultiplexer), NHDP and OLSRv2. So for example OLSRv2 does not put >>> in a packet sequence number. OLSRv2 requests the 5444 multiplexer to >>> add a packet sequence number. Likewise how OLSRv2 interacts with >>> HELLO messages needs care, see OLSRv2 draft for how LINK_METRIC and >>> MPR TLVs are handled. >>=20 >> (I have implemented this similarly in my OLSRv2 code) >>=20 >>> But this is more complicated than that. Because we are considering >>> haps in packet sequence numbers, that means all packets need to be >>> considered. >>=20 >> Yes. >>=20 >>> That could include packets containing neither HELLO >>> messages nor TC messages, which normally neither NHDP nor OLSRv2 will >>> see. (They get reported their messages, and can access related packet >>> information.) This is therefore in part a function interacting >>> directly with the 5444 multiplexer, >>=20 >> Yes. >>=20 >>> which is new, and we (WG, if this >>> is adopted) should be clear on how to handle that - or someone (in >>> the IESG if not sooner) will ask many difficult questions. >>=20 >> I think we should handle this in a similar way than any extension that a= dds/reads packet level TLVs. >>=20 >>> Related to >>> that is whether this extends NHDP, but is used by an extension to >>> OLSRv2, or extends just OLSRv2, and is solely defined in that >>> context. >>=20 >> Thats a bit tricky... metrics are defined in OLSRv2 but are an extension= for NHDP... and metrics can be useful in NHDP even without using OLSRv2. >>=20 >>> Section 9.2 >>>=20 >>> When it says "packets without packet sequence number MUST NOT be >>> processed, that's not quite right in terms of the 5444/NHDP/OLSRv2 >>> model, as discussed above. Also not clear from this wording that you >>> just mean for purpose of metric calculation. >>=20 >> "MUST NOT be process for metric calculation as described below" ? >>=20 >>> Section 9.2/9.3 (or other for resolution) >>>=20 >>> Need a bit more clarity on what to do if you don't get helpful input >>> (missing PSN or INTERVAL_T IMETLV). You still need a metric if the >>> Link Tuple is on an OLSRv2 interface, obviously maximum, but that's >>> only said in the processing, not in the can't process part. >>=20 >> Easiest way would be to ignore the whole Hello timer. The problem is tha= t the metric would not increase if contact to the neighbor is suddenly lost= . >>=20 >>> Section 11 >>>=20 >>> Looking at the L_in_metric calculation, is that calculation going to >>> produce a value in the range 1 to MAXIMUM_METRIC? (I don't have time >>> right now to check that). >>=20 >> At the moment the range I use is 2^4 (256+ MBit/s, ETX 1.0) to 2^16 (1 M= bit/s, ETX 16). >>=20 >>> Even if it does, needs comment about >>> rounding/truncating to a representable value (note that L_in_metric >>> must be representable, it's in the OLSRv2 constraints this is bound >>> by). >>=20 >> I do this already in code, but maybe its worth adding to the draft that = the metric should be set to the nearest metric value that can be represente= d in the compressed format defined in OLSRv2. >>=20 >>> Section 12 >>>=20 >>> These are possibly suitable values for Wi-Fi. That may be fine for >>> Funkfeuer, but if this is adapted as a WG document we need to be more >>> general that that., and to separate what's specific to that and what >>> isn't. We need to be able to understand that if, for example, I want >>> to use this on a system that varies between say 1 kbit/s and 256 >>> kbit/s, what other parameters change? >>=20 >> If we change the parameters to extend the metric range to MINIMUM_METRIC= to MAXIMUM_METRIC, we could transport a linkspeed from 16 bit/s to 4 Gbit/= s. >>=20 >>> Section 14 >>>=20 >>> Suggest referencing the NHDP/OLSRv2 integrity draft. >>=20 >> I will do so. >>=20 >> Henning Rogge >>=20 >> --=20 >> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >> Kommunikationssysteme (KOM) >> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >> Telefon +49 228 9435-961, Fax +49 228 9435 685 >> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>=20 >> _______________________________________________ >> 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 hrogge@googlemail.com Mon Jul 22 08:44: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 CF2DB11E8130 for ; Mon, 22 Jul 2013 08:44:12 -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 cSQBXybQAgM4 for ; Mon, 22 Jul 2013 08:44:07 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id B144D11E8102 for ; Mon, 22 Jul 2013 08:44:07 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c11so3636797qcv.23 for ; Mon, 22 Jul 2013 08:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=PHXxGTiXxNm/Iu8lFh/XwQwty4p2ymNFxTCIrbzRZQQ=; b=FLYAaiuObBAZVsYgGJHAlJHoKX0RZhI5SMpuIe/8FBhw2UUAcvE/DJ39nw8r8P90Iu 4vtZ55EXOQoVLJ3qDKPjij/Z2yQzUa/2hFAydJlq0txZDlAlPkDlm7w1hXBvLIx5mrhw aEgBSBICu1rMz2YUqhp/+x+xZEMf37h/irxq7h8yfaS8bmBblklMAF5g6o+8OMWminFr D9HuIuMd8u8cWHB0E2AyGFkYWXOUB4VjvgMlz/XS286Ec90eBObgUV3BiPNaY2xf8foh Gjxp4/rSXOydjQaogkdyk1eisTkWg1hP755hypUw717e9GTrqVYCj8qTpqW7O+8FqD0K MuLg== X-Received: by 10.49.41.41 with SMTP id c9mr32650781qel.19.1374507847001; Mon, 22 Jul 2013 08:44:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.164.198 with HTTP; Mon, 22 Jul 2013 08:43:46 -0700 (PDT) In-Reply-To: <2ED1D3801ACAAB459FDB4EAC9EAD090C10197118@xmb-aln-x03.cisco.com> References: <51ECF637.8050006@fkie.fraunhofer.de> <32877AE0-2F5A-4C34-B3CC-B83762BB9A9B@gmail.com> <2ED1D3801ACAAB459FDB4EAC9EAD090C10197118@xmb-aln-x03.cisco.com> From: Henning Rogge Date: Mon, 22 Jul 2013 17:43:46 +0200 Message-ID: To: "Stan Ratliff (sratliff)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Dearlove, Christopher \(UK\)" , "Emmanuel Baccelli \(Emmanuel.Baccelli@inria.fr\)" , "manet@ietf.org" Subject: Re: [manet] ETT metrics draft 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, 22 Jul 2013 15:44:12 -0000 I did a little bit searching how the Community Mesh networks handle this. One common option used is to increase the multicast rate to 5.5 or 6 MBit/s. Henning Rogge On Mon, Jul 22, 2013 at 5:34 PM, Stan Ratliff (sratliff) wrote: > FWIW, I agree with Chris. The difference in the range for broadcast/multi= cast vs. unicast is important, as well as the disparity in the data rates f= or those traffic types. > > Regards, > Stan > > On Jul 22, 2013, at 8:29 AM, Christopher Dearlove wrote: > >> Our experience with link quality differs. It's not the loss rate, it's t= hat maximum broadcast range is greater than unicast range (lower data rate)= . So need to exclude links whose SNR suggests too long or poor. And this im= proved performance (provided sufficiently dense network). >> >> -- >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >> >> On 22 Jul 2013, at 10:07, Henning Rogge wrote: >> >>> Hi, >>> >>> I finally had the time to work through the set of reviews from last wee= k. >>> >>> My comments are inline below. >>> >>> Comments inline >>> >>> On 07/15/2013 12:14 PM, Dearlove, Christopher (UK) wrote: >>>> I have just managed to find time for a quick look over version -02 of >>>> the ETT metric draft. A few comments (I omit editorial comments, such >>>> as consistency of use of capitalisation of Link Tuple for a later >>>> draft). >>>> >>>> Section 1 >>>> >>>> Would be useful context to note that adding metrics to OLSRv1 >>>> produced a proprietary extension to RFC 3626. >>>> >>>> The Introduction should provide a bit more OLSrv2 context. >>>> >>>> Section 3 >>>> >>>> Refers to [RFC3626] implementation. This is extended as noted above, >>>> which I think is important to applicability. >>> >>> I think we will have to work more on Section 1/3, maybe pushing the who= le "OLSr.org history" part to a section of its own so we can focus more on = OLSRv2 section 1/3? >>> >>>> The use of control message loss rate on Wi-Fi (IEEE 802.11) has the >>>> issue that the control messages are sent broadcast, the data will be >>>> sent unicast. There's the well-known "grey zone" problem here that is >>>> usually solved with link quality (when using OLSRv1 with hop counts). >>>> It may well be that in practice things work, but there is an issue >>>> here that I think needs discussion. >>> >>> Normally the IP packet loss of the broadcast messages seems to be highe= r than the IP packet loss of unicasts because of the retransmissions. >>> >>> OLSR.org had a "link quality" implementation (as defined in RFC 3626) e= ven before the ETX code, but the link quality didn't helped to stabilize th= e network. >>> >>>> Section 5 >>>> >>>> The use of packet sequence numbers relies on an erratum to RFC 5444. >>>> Do we assume everyone reads errata, or should this be commented on? >>> >>> That was the reason why I explicitly stated what kind of packet sequenc= e number this draft needs. Maybe we could mention that this requirement was= also added in the errata. >>> >>>> There's a metric normalisation issue for OLSRv2 (this divided by that >>>> - scaled?). >>> >>> The "scaling" of this ETT metric has been chosen to be useful with WIFI= (802.11) speed. >>> >>>> Section 6 >>>> >>>> ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have >>>> used something similar in link quality calculations) then it should >>>> be only slightly larger than 1.0, which is worth saying. >>> >>> But not too small, otherwise a message aggregation timer might become a= problem. >>> >>>> Section 7 >>>> >>>> Here reading through I made a note thatr INTERVAL_TIME TLVs are >>>> optional. This is discussed later. But I think a section earlier on >>>> this may be appropriate. That section could also discuss entity >>>> relationships I'll get to below. >>> >>> The order of "things to consider" is a bit off... >>> >>>> Section 9 >>>> >>>> At the WG's requirement, we have been careful to divide up different >>>> entities with different responsibilities, and controlled ways in >>>> which they may interoperate. This has required some care at times. I >>>> don't think this draft has put the same care in. >>>> >>>> There are three entities: The RFC 5444 packet multiplexer (and >>>> demultiplexer), NHDP and OLSRv2. So for example OLSRv2 does not put >>>> in a packet sequence number. OLSRv2 requests the 5444 multiplexer to >>>> add a packet sequence number. Likewise how OLSRv2 interacts with >>>> HELLO messages needs care, see OLSRv2 draft for how LINK_METRIC and >>>> MPR TLVs are handled. >>> >>> (I have implemented this similarly in my OLSRv2 code) >>> >>>> But this is more complicated than that. Because we are considering >>>> haps in packet sequence numbers, that means all packets need to be >>>> considered. >>> >>> Yes. >>> >>>> That could include packets containing neither HELLO >>>> messages nor TC messages, which normally neither NHDP nor OLSRv2 will >>>> see. (They get reported their messages, and can access related packet >>>> information.) This is therefore in part a function interacting >>>> directly with the 5444 multiplexer, >>> >>> Yes. >>> >>>> which is new, and we (WG, if this >>>> is adopted) should be clear on how to handle that - or someone (in >>>> the IESG if not sooner) will ask many difficult questions. >>> >>> I think we should handle this in a similar way than any extension that = adds/reads packet level TLVs. >>> >>>> Related to >>>> that is whether this extends NHDP, but is used by an extension to >>>> OLSRv2, or extends just OLSRv2, and is solely defined in that >>>> context. >>> >>> Thats a bit tricky... metrics are defined in OLSRv2 but are an extensio= n for NHDP... and metrics can be useful in NHDP even without using OLSRv2. >>> >>>> Section 9.2 >>>> >>>> When it says "packets without packet sequence number MUST NOT be >>>> processed, that's not quite right in terms of the 5444/NHDP/OLSRv2 >>>> model, as discussed above. Also not clear from this wording that you >>>> just mean for purpose of metric calculation. >>> >>> "MUST NOT be process for metric calculation as described below" ? >>> >>>> Section 9.2/9.3 (or other for resolution) >>>> >>>> Need a bit more clarity on what to do if you don't get helpful input >>>> (missing PSN or INTERVAL_T IMETLV). You still need a metric if the >>>> Link Tuple is on an OLSRv2 interface, obviously maximum, but that's >>>> only said in the processing, not in the can't process part. >>> >>> Easiest way would be to ignore the whole Hello timer. The problem is th= at the metric would not increase if contact to the neighbor is suddenly los= t. >>> >>>> Section 11 >>>> >>>> Looking at the L_in_metric calculation, is that calculation going to >>>> produce a value in the range 1 to MAXIMUM_METRIC? (I don't have time >>>> right now to check that). >>> >>> At the moment the range I use is 2^4 (256+ MBit/s, ETX 1.0) to 2^16 (1 = Mbit/s, ETX 16). >>> >>>> Even if it does, needs comment about >>>> rounding/truncating to a representable value (note that L_in_metric >>>> must be representable, it's in the OLSRv2 constraints this is bound >>>> by). >>> >>> I do this already in code, but maybe its worth adding to the draft that= the metric should be set to the nearest metric value that can be represent= ed in the compressed format defined in OLSRv2. >>> >>>> Section 12 >>>> >>>> These are possibly suitable values for Wi-Fi. That may be fine for >>>> Funkfeuer, but if this is adapted as a WG document we need to be more >>>> general that that., and to separate what's specific to that and what >>>> isn't. We need to be able to understand that if, for example, I want >>>> to use this on a system that varies between say 1 kbit/s and 256 >>>> kbit/s, what other parameters change? >>> >>> If we change the parameters to extend the metric range to MINIMUM_METRI= C to MAXIMUM_METRIC, we could transport a linkspeed from 16 bit/s to 4 Gbit= /s. >>> >>>> Section 14 >>>> >>>> Suggest referencing the NHDP/OLSRv2 integrity draft. >>> >>> I will do so. >>> >>> Henning Rogge >>> >>> -- >>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr >>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE >>> Kommunikationssysteme (KOM) >>> Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany >>> Telefon +49 228 9435-961, Fax +49 228 9435 685 >>> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de >>> >>> _______________________________________________ >>> 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 --=20 We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From iesg-secretary@ietf.org Tue Jul 23 06:58: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 761B111E8218; Tue, 23 Jul 2013 06:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=0.332, 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 mKP2AQcMQJJ2; Tue, 23 Jul 2013 06:58:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0336411E8165; Tue, 23 Jul 2013 06:58:11 -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.53 Sender: Message-ID: <20130723135810.4379.24368.idtracker@ietfa.amsl.com> Date: Tue, 23 Jul 2013 06:58:10 -0700 Cc: manet@ietf.org Subject: [manet] Last Call: (Integrity Protection for Control Messages in NHDP and OLSRv2) to Proposed Standard X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 13:58:11 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Integrity Protection for Control Messages in NHDP and OLSRv2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-08-14. 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 specifies integrity and replay protection for the MANET Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This protection is achieved by using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a timestamp TLV based on POSIX time. The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described in RFC 5444. This document updates RFC 6130 and RFC xxxx by mandating the implementation of this integrity and replay protection in NHDP and OLSRv2. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-sec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-sec/ballot/ No IPR declarations have been submitted directly on this I-D. From ulrich@herberg.name Thu Jul 25 12:03:14 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 24D9721F8546 for ; Thu, 25 Jul 2013 12:03:14 -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=[AWL=-0.000, 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 802WY9a51zro for ; Thu, 25 Jul 2013 12:03:13 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5D721F85E0 for ; Thu, 25 Jul 2013 12:02:56 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id id13so354875vcb.4 for ; Thu, 25 Jul 2013 12:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=+DwR1CQet8TfaRYSXj/a6e8y76MHLMTAeReutiV0z9A=; b=DqRggyX8esWCw83DaDlTzaJ1EoczVqI3ByPwxaR3oVQjrS3KKj1fqGpR1VV6wQqG6f 3B0lTCzsocMA5OJRf2ULHen0EwlkRGbsQk0p8u6T/vPe2UH+Lg/ZV6xTaS2N+blOrU6e e+3fLARozIGuo8aQtzieMnrDnfLhbPG2oGvSg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=+DwR1CQet8TfaRYSXj/a6e8y76MHLMTAeReutiV0z9A=; b=mWpuIlnr56c2aGaHCPr+5MS3z+Tdd/fS7JGh/9yLJB07GMk64eKiOPsl7YsLS0DvGJ D7Spw1uglpbMHnSjnxyr5nLH9b4F36fy/qxmkBaCupY3ChVrWTw408Sm8dIUbQOdz9qp zgDFaYrTJpSFp2bxruej1azSFybK3BWzu1SHErPrvw8Ef5W+IovTlzTxUXE0E+q2q64P JoHqSpuPw7m6N6znSKg1m8gEVGGjNJxKzM/CEP4ECskMaUr+4ROB5LmOGyeoYR3ewZo4 /ZTOpw0NkIpWvqvIVeleFBOXDZmX+2RmMFbSGHsW+CjoQ3wkZKDCPLvDzmzHmyZz20dG 90ZA== MIME-Version: 1.0 X-Received: by 10.220.101.197 with SMTP id d5mr1358662vco.59.1374778976385; Thu, 25 Jul 2013 12:02:56 -0700 (PDT) Received: by 10.221.55.70 with HTTP; Thu, 25 Jul 2013 12:02:56 -0700 (PDT) Date: Thu, 25 Jul 2013 12:02:56 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkwIKK9ACJuURIE2Hw8jiAK8/B6aIKlRg0v58DQXvN8qMhbKaZqUFQHJENmAqwgcvJg2GzC Subject: [manet] Slides please 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, 25 Jul 2013 19:03:14 -0000 Hi, please don't forget to send your slides in time, at the latest until next Wednesday at noon. I need enough time to upload them and put them on the laptop that will be used for the presentation. Thanks Ulrich From emmanuel.baccelli@gmail.com Sat Jul 27 08:54:14 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 1BFB421F9A29; Sat, 27 Jul 2013 08:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 eE8G3Z-I5lkq; Sat, 27 Jul 2013 08:54:13 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94521F99DE; Sat, 27 Jul 2013 08:54:13 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so10152060oag.9 for ; Sat, 27 Jul 2013 08:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=7LpStShdo1R8ONZpQqsixFaUqUgdB5XtPdsW87uWAqg=; b=GHfy31Ml3byP7SAKpDEu0ujsO7znC6DUH1TD72rYB2IH1tAW3Sus6yZByvWHRlkYyp 55s3yf6xXDMzlLKv1ZvrG8C7R97lr6OwAo5MrXbFbBmo1389IIrBjOl2J9pgeYsf4KUa OGLuw5/Q6bq+GE/4r+lj110+af5z0Yg25Vgr/cZdYsoT7t0eIAKWNJj3yhLLiVZRAQty mtftCrNJrwmZ2zOzh0A5XDoTPxx+Im1BnamLQhu7eSAJiWjCYLNEkxmmDs2ZpxPgEmQc oqZatjYQx/v4Zb+VWSQyA5QOaPEiztwZ2zuYF/H/yEilCAd1OopF9VVHoy8fMqNe9P9T eX2Q== X-Received: by 10.60.161.44 with SMTP id xp12mr52265901oeb.91.1374940453005; Sat, 27 Jul 2013 08:54:13 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.76.82.133 with HTTP; Sat, 27 Jul 2013 08:53:52 -0700 (PDT) From: Emmanuel Baccelli Date: Sat, 27 Jul 2013 17:53:52 +0200 X-Google-Sender-Auth: tTvz1-Exy2dK_GbJ-Y0Vt8tziS8 Message-ID: To: MANET IETF , ROLL WG Content-Type: multipart/alternative; boundary=089e01184a2449f34504e28045e7 Subject: [manet] MANIAC Challenge workshop 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, 27 Jul 2013 15:54:14 -0000 --089e01184a2449f34504e28045e7 Content-Type: text/plain; charset=ISO-8859-1 Hi all, For those interested in mobile data offloading, tomorrow morning (Sunday) takes place the MANIAC Challenge workshop, at the IETF hotel, in room Tiergarten 1/2, from 9:00AM until lunch time. http://2013.maniacchallenge.org/program/ The workshop will feature talks by several cooperative forwarding strategies developers, as well as talks by Stan Ratliff on IETF standards work-in-progress related to cooperative mobile data offloading, and by Henning Rogge on Freifunk and community wireless mesh networking. Come check it out! Best, Emmanuel --089e01184a2449f34504e28045e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

For those interested in m= obile data offloading, tomorrow morning (Sunday) takes place the MANIAC Cha= llenge workshop, at the IETF hotel, in room Tiergarten 1/2, from 9:00AM unt= il lunch time.=A0http:= //2013.maniacchallenge.org/program/

The workshop will feature talks by several = cooperative forwarding strategies developers, as well as talks by Stan Ratl= iff on IETF standards work-in-progress related to cooperative mobile data o= ffloading, and by Henning Rogge on Freifunk and community wireless mesh net= working.

Come check it out!

Best,

Emmanuel


--089e01184a2449f34504e28045e7-- From ulrich@herberg.name Mon Jul 29 02:16:55 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 71D4521F9E00 for ; Mon, 29 Jul 2013 02:16:55 -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 PtUE1ZZzU6t9 for ; Mon, 29 Jul 2013 02:16:54 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id C2FCA21F99FA for ; Mon, 29 Jul 2013 02:16:51 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id m1so2322309ves.13 for ; Mon, 29 Jul 2013 02:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=EdsbKU3sMz0OYHvVqDKmSzbAr3PQpBUfaF4XZgbxBkI=; b=eb1myyZVX7Idmx9XoKGfMqHWla0UPd1e79TQaj8O6ebKBO4s2iftaH4afGtTvkL37v hgJ7kodQj1RsEX2iLCRnbFX2hau6+pkF4xKVQXZwnYrSlPrOAnaF0IHP6X4Mv688FdBQ Fudz99KEeKseRH+CZivRxD3vWL7PARxI3qD5I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=EdsbKU3sMz0OYHvVqDKmSzbAr3PQpBUfaF4XZgbxBkI=; b=DtZEgsFSUAyOAsfqiDuIDNsxJBBLgDkFiVaqSdFbtOywr/3HxJwSK7tmHAuw+acRh9 /VO3GbCsovr9tS2s5fgD+s2+EZ66uFiyohhnIRV1or594pts12jGMKzLuQb9LulBwftG GyvlzAYXEuEqTjC9BmEZt9Ml2+PsPWIGxQjtjsEF7iLwhVxPpWq1ubhREi8qrNf6tgjj igGYgcOeSdMrCrJc35inJSf2oHA1sDJUG7g9GDEqAxe9hB4NnM446cd95fddsi2cocv1 LI/r2qUAerVlNxDL3F2u/Qa/KySqIypJz7jsHJ457GV2KWTGr9/3ICefiztVLWRLA09n ui9w== MIME-Version: 1.0 X-Received: by 10.52.188.73 with SMTP id fy9mr21611685vdc.53.1375089411006; Mon, 29 Jul 2013 02:16:51 -0700 (PDT) Received: by 10.221.55.70 with HTTP; Mon, 29 Jul 2013 02:16:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jul 2013 11:16:50 +0200 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlOeIpUIxFpTqyNg5L54QyqbR79ORPjW8YSe9zBszqAk6JESmQhzdXNbnEEVMuiA1qHCF3m Subject: [manet] Fwd: moving more responsibility to working groups 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, 29 Jul 2013 09:16:55 -0000 FYI ---------- Forwarded message ---------- From: IETF Chair Date: Mon, Jul 29, 2013 at 11:07 AM Subject: moving more responsibility to working groups To: "ietf-announce@ietf.org" Cc: "ietf@ietf.org list" I would like to report an experiment that the IESG is starting. (There's also an associated blog article about this at http://www.ietf.org/blog/2013/07/the-role-of-working-groups/) Internet Drafts sent for approval as RFCs are reviewed by individuals during the IETF Last Call, the Area Directors, IANA, as well as a number of volunteers from various directorates and review teams. The reviews from these teams has gained a significant role in ensuring that the IETF produces high-quality, understandable and implementable RFCs. Yet, as discussed in http://www.ietf.org/blog/2013/05/balancing-the-process/ we have a general problem that quite a lot of the work around IETF documents happens at the end of the process. In particular, a number of the reviews during IETF last call point out issues that end up being raised by the IESG as comments. It is of course good that issues are caught, but raising them earlier would be better. And it would be better if the working groups - the intended focus point of work on a topic - would get to handle them, as opposed to raising these issues with the IESG. The has IESG discussed these issues and decided to experiment with three actions designed to move more work to the responsibility of the working groups: (1) Perform some reviews that are now happening at IETF Last Call a bit earlier. This will put the working group in a bigger role in resolving cross-area and general issues. (2) Invite document shepherds on IESG telechats when there's a document that is likely to require discussion. This will make it possible for the document shepherd to be directly involved in the discussions. (3) When a document up for approval has a number of issues, hand over the process back to the working group, as opposed to the IESG tracking the issues. Among other things, this will ensure that changes are discussed in an open working group list and agreed through consensus. We are at the beginning of the experiment. We've done (2) and (3) a few times and plan to use it more from now on. We are discussing with the review teams to plan how (1) comes into effect. Building quality and cross-area review to the process earlier is of course a big effort. We are making a small change to current directorate review procedures. If successful, this will enable working groups to deal with issues before IETF Last Call and IESG review and empower the working groups to be in charge of the documents throughout their life cycle. We are also hoping that document quality will improve and number of issues discussed in the IESG will be lower. >From the point of view of the document authors and WG participants, all the above works through your working group chairs. They will be talking to you when documents come back to the working group. They or the document shepherds will be even more part of the IESG discussions and will keep the working groups updated on the progress of the documents. They will work with review teams to request earlier review. You will be seeing some reviews in the working group mailing lists. The current plan is to do these reviews after WGLC has completed, in parallel with ongoing reviews from your responsible ADs and chairs preparing the write-ups for the document to be submitted to the IETF Last Call. While the number of reviews as such is not changed, some additional effort and care will however be required from the reviewers, directorate coordinators/secretaries, the working group chairs, and other participants. The experiment will show us whether this effort is reasonable and if there are any unexpected effects. The experiment is performed on a voluntary basis by each directorate, for a limited number of drafts at the beginning. We will be collecting experiences so that in six months we can evaluate the experience. I would also like to thank the document shepherds, chairs, and review teams for participation in this effort! Jari From internet-drafts@ietf.org Tue Jul 30 08:40:46 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 BED6311E8101; Tue, 30 Jul 2013 08:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, 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 2-GtH2oPevM3; Tue, 30 Jul 2013 08:40:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EB511E821F; Tue, 30 Jul 2013 08:40:26 -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.60p1 Message-ID: <20130730154026.12682.30268.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 08:40:26 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-rfc6622-bis-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: Tue, 30 Jul 2013 15:40:46 -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 : Integrity Check Value and Timestamp TLV Definitions for = Mobile Ad Hoc Networks (MANETs) Author(s) : Ulrich Herberg Thomas Heide Clausen Christopher Dearlove Filename : draft-ietf-manet-rfc6622-bis-04.txt Pages : 29 Date : 2013-07-30 Abstract: This document revises, extends and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-rfc6622-bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-rfc6622-bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-rfc6622-bis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ulrich@herberg.name Wed Jul 31 00:54: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 58A3211E8170 for ; Wed, 31 Jul 2013 00:54:12 -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 d98XWr5HwMAd for ; Wed, 31 Jul 2013 00:54:11 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5D32211E816F for ; Wed, 31 Jul 2013 00:54:11 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id h10so367433vbh.6 for ; Wed, 31 Jul 2013 00:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=a+F9AVeVceMhq1stCqBUfzDqtcSQoOz3wgiAmdR/obE=; b=VtVIif4WOrIYCYBR8OMp21QTEMMFwJzGhQGgsLGWnjazguZ4ax2kkQftb7U2Pqiuqc QB3T6pfumvrnXQ4eGlKTaZak8QAeuBpInq+neJKMRc7ngPlEzKgE6I1wOMk1Nqw0Z42r yqPB4Uonqw4TBBb9wuHuBBV8DFJxBlFRqDCW0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=a+F9AVeVceMhq1stCqBUfzDqtcSQoOz3wgiAmdR/obE=; b=DrsDhhafsiYEwEnyydu4CPU3tmVMKVgvZLeKTXoadbfVzkB9S3LCUpUmE4zkxlAQY8 TbJXt1zNgJYnJq39sgN8ca3iK+N98xBM0QpCtjv3bAEG2XKEiiwUZwurhkUbfURbiyRr g1dfCGX1dToLP1oOyHaWIsS4YDc+82+IaVC2w8VCNBUuRyQHwR+uTvxZUmSghlAMQu+2 7fMqjWThSlMu5eORc77YDk5idm9ckQuuXLXvGHz8OzYAWrfDUMmt6JEOtGicbMRRocZ1 OJGujA2S+5MtScGJzmuhy7aIc6osntOVnpbD8kkLfcUHiT7hVaAtUygn5kQKXllcY0nV 9r0w== MIME-Version: 1.0 X-Received: by 10.52.165.12 with SMTP id yu12mr23848093vdb.40.1375257250737; Wed, 31 Jul 2013 00:54:10 -0700 (PDT) Received: by 10.221.55.70 with HTTP; Wed, 31 Jul 2013 00:54:10 -0700 (PDT) Date: Wed, 31 Jul 2013 09:54:10 +0200 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnYWJZ3NJasRLYEPlF2u99fIOleCs+Gwy3YKUgpaRzKAg+wkTbZOwUIlWVnG1OQmk8fDt29 Cc: Stan Ratliff Subject: [manet] Final reminder: slides 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, 31 Jul 2013 07:54:12 -0000 This is a final reminder for the slides. I have not received slides for the following presentations: - draft-ietf-manet-dlep - draft-ietf-manet-aodvv2 Please send me the slides today, or you will have to present without slides. Ulrich