From nobody Fri Jul 1 00:50:41 2016 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 1C13D12D1DA for ; Fri, 1 Jul 2016 00:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM6j7gMnyuAr for ; Fri, 1 Jul 2016 00:50:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A4312D1D2 for ; Fri, 1 Jul 2016 00:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=924; q=dns/txt; s=iport; t=1467359438; x=1468569038; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nGjmzURzQDpx06Kv+LcV6HDBHZVRn7BL7dqrl1ilKpI=; b=T556z5xPLMRTmeC18KWNoi/yH2XCA12xDWbmBFlBg0H+tMlD/56JreuK Pi1efrk/hqH4lCnW+NXDoE5w7qMssLjShVkfD6OpFRGtF/AGOxDbDbMpD hoIMxNpidfYveC+2FbiW9OSUlmRlMfZ8zVwdjst8sde1+T9TJYuo2WoNS g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBdH3ZX/5tdJa1agz6BUq1EjBCBe?= =?us-ascii?q?4YYAoE0OBQBAQEBAQEBZSeETAEBBAF5BQsCAQgOCi4hESUCBA4FiBYDDwi/bQ2?= =?us-ascii?q?EGwEBAQEBAQEBAQEBAQEBAQEBAQEBARyGKIF3CIJOgkOBfYMsgi8BBI45iiM0A?= =?us-ascii?q?Yw2gg2PKogWh3IBHjaDcG6IdAEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,555,1459814400"; d="scan'208";a="121043273" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jul 2016 07:50:37 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u617ob7L019475 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Jul 2016 07:50:37 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 1 Jul 2016 02:50:36 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 1 Jul 2016 02:50:36 -0500 From: "Pascal Thubert (pthubert)" To: Henning Rogge Thread-Topic: [manet] draft-ietf-olsrv2-multipath-09 Thread-Index: AQHR0yPr4AACWZ1mFkO8y3AHh0avDqADDcDSgABV9YD//9CE1g== Date: Fri, 1 Jul 2016 07:50:36 +0000 Message-ID: <8669452A-AE1F-45E5-8301-D68EEB469740@cisco.com> References: <9CC61969-5F6A-4F14-87C6-99B47080DDB3@gmail.com> <9E1B5776-D8D8-4697-9BF4-EA24A84EF8A7@cisco.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: MANET IETF Subject: Re: [manet] draft-ietf-olsrv2-multipath-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 07:50:40 -0000 Yes, Henning. The points being: - signaling the topology in the packet - providing redistribution rules between RPL and OLSR instances. For the former RPL uses an IPv6 option which does an equivalent to 1Q plus = some topological mishap detection.=20 OLSR may find the existing RPL signaling sufficient, just like for SRH. If so, the latter would enable to build interesting networks coupling mobi= lity and IOT. Regards, Pascal > Le 1 juil. 2016 =E0 07:41, Henning Rogge a =E9crit : >=20 > On Fri, Jul 1, 2016 at 7:32 AM, Pascal Thubert (pthubert) > wrote: >> Maybe on occasion we can chat about the way RPL handles instances, which= are >> like L3 VLANs. >=20 > Wouldn't the multi-topology extension of OLSRv2 having a similar > effect? Multiple (partly) overlapping routing topologies with the same > routing agent. >=20 > Henning Rogge From nobody Fri Jul 1 07:39:46 2016 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 1725512D150 for ; Fri, 1 Jul 2016 07:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxRjPyO0B8ii for ; Fri, 1 Jul 2016 07:39:42 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF0312B061 for ; Fri, 1 Jul 2016 07:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2897; q=dns/txt; s=iport; t=1467383978; x=1468593578; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Uf8BDdpCAmwOzqW2NoT1RBZ+00BEtKM5sRvyybkBKNA=; b=EFjhP1BPxjdBn+noNQb0wPRQfErP6HIE5iPxBjwicjlGf/Ovdz4cKeaK 1NVfh/BlfDifn1dz18168MqDBp9UUYacDde25/c1tSihRafh5bzuM5CHR M8i+mL5psyUSXc4+6IfPSuIHgQs43LDUquAUq7gyVDXWrgTXJwmsEw306 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgBnf3ZX/4cNJK1dgz5WfAa5SoF7J?= =?us-ascii?q?IV0AoEwOBQBAQEBAQEBZRwLhE0BBQEBODQCGQIBCDYQJwsbAQYDAgQTFIgcDsQ?= =?us-ascii?q?jAQEBAQEBAQMBAQEBAQEBIIYohE2KGwWTVoU6AYYIiDuBak6ECIhqkAgBHjaDc?= =?us-ascii?q?G6HdX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,557,1459814400"; d="scan'208";a="292530517" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jul 2016 14:39:37 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u61Edbg3018291 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 1 Jul 2016 14:39:37 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 1 Jul 2016 09:39:36 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 1 Jul 2016 09:39:36 -0500 From: "Alvaro Retana (aretana)" To: "manet@ietf.org" Thread-Topic: [gaia] I-D Action: draft-irtf-gaia-alternative-network-deployments-07.txt Thread-Index: AQHR06ZkziTtgKsFJUmtEL6dIx50tA== Date: Fri, 1 Jul 2016 14:39:36 +0000 Message-ID: References: <20160601092040.16081.41390.idtracker@ietfa.amsl.com> In-Reply-To: <20160601092040.16081.41390.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <5D39EEBF33655E40889097D989BA462B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [manet] FW: [gaia] I-D Action: draft-irtf-gaia-alternative-network-deployments-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 14:39:44 -0000 FYI.. It might be a good idea to take quick look at this document. It is to be published by the IRTF and is currently in the IESG Conflict Review process. Thanks! Alvaro. On 6/1/16, 5:20 AM, "gaia on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Global Access to the Internet for All of >the IETF. > > Title : Alternative Network Deployments: Taxonomy, >characterization, technologies and architectures > Authors : Jose Saldana > Andres Arcia-Moret > Bart Braem > Ermanno Pietrosemoli > Arjuna Sathiaseelan > Marco Zennaro > Filename : draft-irtf-gaia-alternative-network-deployments-07.txt > Pages : 41 > Date : 2016-06-01 > >Abstract: > This document presents a taxonomy of a set of "Alternative Network > Deployments" that emerged in the last decade with the aim of bringing > Internet connectivity to people or for providing local communication > infrastructure to serve various complementary needs and objectives. > They employ architectures and topologies different from those of > mainstream networks, and rely on alternative governance and business > models. > > The document also surveys the technologies deployed in these > networks, and their differing architectural characteristics, > including a set of definitions and shared properties. > > The classification considers models such as Community Networks, > Wireless Internet Service Providers (WISPs), networks owned by > individuals but leased out to network operators who use them as a > low-cost medium to reach the underserved population, networks that > provide connectivity by sharing wireless resources of the users and > rural utility cooperatives. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-irtf-gaia-alternative-network-deplo >yments/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-irtf-gaia-alternative-network-deployment >s-07 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-gaia-alternative-network-de= pl >oyments-07 > > >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/ > >_______________________________________________ >gaia mailing list >gaia@irtf.org >https://www.irtf.org/mailman/listinfo/gaia From nobody Fri Jul 1 07:56:57 2016 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 B090112B061 for ; Fri, 1 Jul 2016 07:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA0ddZ-a0-vL for ; Fri, 1 Jul 2016 07:56:54 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D5412D146 for ; Fri, 1 Jul 2016 07:56:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,557,1459810800"; d="scan'208";a="84531833" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 01 Jul 2016 15:56:52 +0100 X-IronPort-AV: E=Sophos;i="5.26,557,1459810800"; d="scan'208";a="124373416" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 01 Jul 2016 15:56:51 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.56]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Fri, 1 Jul 2016 15:56:51 +0100 From: "Dearlove, Christopher (UK)" To: "Alvaro Retana (aretana)" , "manet@ietf.org" Thread-Topic: [gaia] I-D Action: draft-irtf-gaia-alternative-network-deployments-07.txt Thread-Index: AQHR06ZkziTtgKsFJUmtEL6dIx50tKADqVYA Date: Fri, 1 Jul 2016 14:56:50 +0000 Message-ID: References: <20160601092040.16081.41390.idtracker@ietfa.amsl.com> 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 Archived-At: Subject: Re: [manet] [gaia] I-D Action: draft-irtf-gaia-alternative-network-deployments-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 14:56:55 -0000 Based on a very quick skim of just the routing part, it should use the term= s ad hoc network and MANET as well as mesh network, and it references RFC 7= 188 rather than RFC 7181 for OLSRv2. I wish I had more time, but that's all I've got right now. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Alvaro Retana (are= tana) Sent: 01 July 2016 15:40 To: manet@ietf.org Subject: [manet] FW: [gaia] I-D Action: draft-irtf-gaia-alternative-network= -deployments-07.txt ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- *** WARNING *** EXTERNAL EMAIL -- This message originates from outside our organization. FYI.. It might be a good idea to take quick look at this document. It is to be published by the IRTF and is currently in the IESG Conflict Rev= iew process. Thanks! Alvaro. On 6/1/16, 5:20 AM, "gaia on behalf of internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts = >directories. >This draft is a work item of the Global Access to the Internet for All = >of the IETF. > > Title : Alternative Network Deployments: Taxonomy, >characterization, technologies and architectures > Authors : Jose Saldana > Andres Arcia-Moret > Bart Braem > Ermanno Pietrosemoli > Arjuna Sathiaseelan > Marco Zennaro > Filename : draft-irtf-gaia-alternative-network-deployments-07.txt > Pages : 41 > Date : 2016-06-01 > >Abstract: > This document presents a taxonomy of a set of "Alternative Network > Deployments" that emerged in the last decade with the aim of bringing > Internet connectivity to people or for providing local communication > infrastructure to serve various complementary needs and objectives. > They employ architectures and topologies different from those of > mainstream networks, and rely on alternative governance and business > models. > > The document also surveys the technologies deployed in these > networks, and their differing architectural characteristics, > including a set of definitions and shared properties. > > The classification considers models such as Community Networks, > Wireless Internet Service Providers (WISPs), networks owned by > individuals but leased out to network operators who use them as a > low-cost medium to reach the underserved population, networks that > provide connectivity by sharing wireless resources of the users and > rural utility cooperatives. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-irtf-gaia-alternative-network-de >plo >yments/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-irtf-gaia-alternative-network-deploym >ent >s-07 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-gaia-alternative-network-d >epl >oyments-07 > > >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/ > >_______________________________________________ >gaia mailing list >gaia@irtf.org >https://www.irtf.org/mailman/listinfo/gaia _______________________________________________ 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 nobody Fri Jul 1 08:22:04 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E181512D6B2; Fri, 1 Jul 2016 08:21:58 -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: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160701152158.24593.71885.idtracker@ietfa.amsl.com> Date: Fri, 01 Jul 2016 08:21:58 -0700 Archived-At: Cc: manet@ietf.org, The IESG , manet-chairs@ietf.org Subject: [manet] WG Action: Rechartered Mobile Ad-hoc Networks (manet) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:21:59 -0000 The Mobile Ad-hoc Networks (manet) WG in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Mobile Ad-hoc Networks (manet) ----------------------------------------------------------------------- Current status: Active WG Chairs: Stan Ratliff Justin Dean Secretaries: Ulrich Herberg Assigned Area Director: Alvaro Retana Routing Area Directors: Alia Atlas Alvaro Retana Deborah Brungard Mailing list: Address: manet@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/manet Archive: https://mailarchive.ietf.org/arch/browse/manet/ Charter: https://datatracker.ietf.org/doc/charter-ietf-manet/ The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing applications within both static and dynamic topologies with increased dynamics due to node motion or other factors. Approaches are intended to be relatively lightweight in nature, suitable for multiple hardware and wireless environments, and address scenarios where MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should also be supported by MANET specifications and management features. When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. The WG will put special attention on the standardization of a bidirectional, dynamic link exchange protocol (DLEP) between the router and the modem. The MANET WG will coordinate with other Working Groups, such as the pim WG for multicast support, the Routing Area WG (rtgwg), OSPF WG and Babel WG on the general use of DLEP, as well as the IPPM WG on topics related to traffic classification. The MANET WG is responsible for the maintenance of OLSRv2 [RFC 7181], NHDP [RFC 6130] and the Generalized MANET Packet/Message Format [RFC5444], and their extensions. Work Items: - Develop a dynamic link exchange protocol (DLEP). - DLEP extension to provide a credit-windowing scheme for destination-specific flow control. - DLEP extensions for reporting statistics by traffic classification. - Multicast MANET protocol framework based on Simplified Multicast Forwarding [RFC 6621] for scoped forwarding within MANET networks. As part of this framework the WG will produce a well defined MANET multicast forwarding information base (FIB). - Document outlining challenges and best practices for deploying and managing MANET networks. Milestones: Nov 2016 - MANET Management Document (Informational) Nov 2016 - DLEP Credit Windowing Extensions (Standards Track) Nov 2016 - DLEP (Standards Track) Jul 2017 - DLEP traffic extensions (Standards Track) Nov 2017 - Multicast FIB (Standards Track) From nobody Mon Jul 4 05:16:03 2016 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 55B9B12B047; Mon, 4 Jul 2016 05:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmVYjmdIg67x; Mon, 4 Jul 2016 05:16:00 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59DC12B032; Mon, 4 Jul 2016 05:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9008; q=dns/txt; s=iport; t=1467634559; x=1468844159; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Dnh8fXeLi+Z+FhDJOJLJ+04swGPsdcJaRfHcVHKOUDo=; b=Fru0Lr8lDtZwOiTwvKYdEUMHNQ26YWT2J2CRz2V7GGGBHe4hgEKBqJZD Z7HOvn/kHjl+nHii5Fqlh0UnTQ8DNOTdbtODRj6rKd1MU3qjStWRTPmy7 AIP85DhaXaQbteJVq/l5l0MOCAg+PVNakkG//gXga06WA+t9ilPLEA0u2 I=; X-IronPort-AV: E=Sophos;i="5.26,574,1459814400"; d="scan'208,217";a="638362265" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2016 12:15:57 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u64CFvJ4001426; Mon, 4 Jul 2016 12:15:57 GMT To: Justin Dean , "Alvaro Retana (aretana)" References: <20160630071134.29630.40419.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: Date: Mon, 4 Jul 2016 14:15:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F5317D69E588E94B6AC97380" Archived-At: Cc: "manet-chairs@ietf.org" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , Thomas Heide Clausen , Benoit Claise Subject: Re: [manet] Benoit Claise's No Objection on charter-ietf-manet-03-07: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 12:16:02 -0000 This is a multi-part message in MIME format. --------------F5317D69E588E94B6AC97380 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Glad to see Justin's reply. A positive attitude. Regards, Benoit > There is value in providing a document which can help explain to the > wider IETF what MANET is and can and can't do. What the limitations > are and possible gaps in technologies that may possibly be. We have > previously produced two different management documents both of which > didn't come to fruition. I think something of a mixture of the two as > well as details regarding HOW people have deployed and managed these > networks and what are the limitations/advantages/disadvantages in > those deployments. Parts of the OLSRv2 management draft can be taken > as concrete example use cases using the only standard MANET protocol > but there are properties of a MANET that are independent of the > protocol: interment connectivity, address management, transit issues, > protocol management, non-typical "link" properties, etc. We should be > able to address what these challenges are and how we (those that have > deployed MANET networks) have overcome those challenges. > > I think this is an opportunity and we have most of the pieces and all > of the right people already. > > Justin > > On Thu, Jun 30, 2016 at 12:06 PM, Alvaro Retana (aretana) > > wrote: > > On 6/30/16, 11:20 AM, "manet on behalf of Ulrich Herberg" > on behalf > of ulrich@herberg.name > wrote: > > Ulrich: > > Hi! > > >I am not sure how to produce a document > >that describes to how manage MANETs in general for standard protocols > >that don't even exist. > >So I also don't know how this item in the charter will be addressed. > > Please note that the charter item says: "Document outlining > challenges and > best practices for deploying and > managing MANET networks." > > It doesn't say anything about a network using protocol A or > protocol B. > You and I (and the rest of the WG of course) know that the protocols > developed in this WG are not the only manet protocols that exist -- in > fact, the protocols discussed in the WG are not the only protocols > that > exist. And a routing protocol is not the only part that needs > management > in a network. To be clear, the item is not about managing OLSRv2 in a > network (or any other protocol). > > MANET networks are not fully understood outside this WG, which > sometimes > results in improper (or even unrealistic) expectations of what is > required/possible. This document gives the WG the opportunity to > clearly > spell out the "challenges and best practices". Even though the WG is > inside the routing area and generally focuses on routing > protocols, it is > clearly the one place where people with deployment and management > of MANET > networks work -- which is why it is chartered with this work. > > I am sure that the WG will benefit from the experience of deploying > OLSRv2, which obviously should be taken into consideration. > However, the > intent goes beyond a single protocol... > > Thanks! > > Alvaro. > > --------------F5317D69E588E94B6AC97380 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Glad to see Justin's reply. A positive attitude.

Regards, Benoit
There is value in providing a document which can help explain to the wider IETF what MANET is and can and can't do.  What the limitations are and possible gaps in technologies that may possibly be.  We have previously produced two different management documents both of which didn't come to fruition.  I think something of a mixture of the two as well as details regarding HOW people have deployed and managed these networks and what are the limitations/advantages/disadvantages in those deployments.  Parts of the OLSRv2 management draft can be taken as concrete example use cases using the only standard MANET protocol but there are properties of a MANET that are independent of the protocol: interment connectivity, address management, transit issues, protocol management, non-typical "link" properties, etc.  We should be able to address what these challenges are and how we (those that have deployed MANET networks) have overcome those challenges. 

I think this is an opportunity and we have most of the pieces and all of the right people already.

Justin

On Thu, Jun 30, 2016 at 12:06 PM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:
On 6/30/16, 11:20 AM, "manet on behalf of Ulrich Herberg"
<manet-bounces@ietf.org on behalf of ulrich@herberg.name> wrote:

Ulrich:

Hi!

>I am not sure how to produce a document
>that describes to how manage MANETs in general for standard protocols
>that don't even exist.
>So I also don't know how this item in the charter will be addressed.

Please note that the charter item says: "Document outlining challenges and
best practices for deploying and
managing MANET networks."

It doesn't say anything about a network using protocol A or protocol B.
You and I (and the rest of the WG of course) know that the protocols
developed in this WG are not the only manet protocols that exist -- in
fact, the protocols discussed in the WG are not the only protocols that
exist.  And a routing protocol is not the only part that needs management
in a network.  To be clear, the item is not about managing OLSRv2 in a
network (or any other protocol).

MANET networks are not fully understood outside this WG, which sometimes
results in improper (or even unrealistic) expectations of what is
required/possible.  This document gives the WG the opportunity to clearly
spell out the "challenges and best practices".  Even though the WG is
inside the routing area and generally focuses on routing protocols, it is
clearly the one place where people with deployment and management of MANET
networks work -- which is why it is chartered with this work.

I am sure that the WG will benefit from the experience of deploying
OLSRv2, which obviously should be taken into consideration.  However, the
intent goes beyond a single protocol...

Thanks!

Alvaro.



--------------F5317D69E588E94B6AC97380-- From nobody Tue Jul 5 06:45:10 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BBC12D0E7; Tue, 5 Jul 2016 06:45:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160705134505.22259.14926.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2016 06:45:05 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-10.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 13:45:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Jiazi Yi Benoit Parrein Filename : draft-ietf-manet-olsrv2-multipath-10.txt Pages : 24 Date : 2016-07-05 Abstract: This document specifies a multi-path extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-10 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 nobody Tue Jul 5 07:00:19 2016 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 1E5EE12D134 for ; Tue, 5 Jul 2016 07:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhvQinmP-k0C for ; Tue, 5 Jul 2016 07:00:16 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC9812D594 for ; Tue, 5 Jul 2016 07:00:15 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id h129so135474731lfh.1 for ; Tue, 05 Jul 2016 07:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=9k7hfcesVLd74dc78QguxkXoTQrhJG2iZ/18Nybcg8Y=; b=hTp6Ce5zhkADBplYJUtVIMIyJ8iY0x5QmsZ2vLbTIKgC2nJzwaFMSsMAHaSoOGnQ+O 89qUJWpsWPr7yLOBHbY1+wMXOMNSdX4X8kC9gUYXBWxO5ty30HsbjDlJmv/vxyYxgVLA 6MPAdhfoPybj3s6Brm/ivCLTGAX5wpz3JRkP+3QoVg/sOUDsVisX8UVCmPUzuyjI5LH9 qAempRcbvS8SY4CTpnbz8P9fdVPIs8wgCYZJORqqmp4HY1sn1rY3aEqPPkCRi51l9oma OiJ+Qo/KRdCkaxJPht+nZMFg7Gfuog6yVdLUwi5envjR0kk7OCwyggzFgJenDBuCLyEW SAOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=9k7hfcesVLd74dc78QguxkXoTQrhJG2iZ/18Nybcg8Y=; b=B+QhtOrEeBtLIOQiyO87BBj0auceY1Uu6BTx3XqdrGjK19hDMJM09tcrtKIwsEdhAB 6nD3vB8/EfDOxdDiAV7Albm7xhvC8tLpNembJdQVyVic/4tB4Mq1wNya1MVIa3pl2Cmq MbXQT6ccgNJ/9fz9aOR6QP/YI4fijCRiWuteNsH7kf3z+nxp0oSrxVVUIGTVuHXi5xUb YdJo2QOWmy8mLeguNUDsZY4Xuyn4TG/75QIlrQ2ltPt0oXKbDdi7RUb77vistGRxf1cr UPDBhiohiTai6vrgkrtkB5tv2Hr4mnCL9IRGyRifVofh9PnzczPSg6a8rlwoHMZYDQpR DOfg== X-Gm-Message-State: ALyK8tJKHG7V0+b53Nu5uyrzEeAza1KZ57sOG9jbuPmk3EljdIK3G+O2YE6bCNo3lbJ+9l4MzZzqGgOXAhsEAg== X-Received: by 10.25.18.35 with SMTP id h35mr3629754lfi.82.1467727213677; Tue, 05 Jul 2016 07:00:13 -0700 (PDT) MIME-Version: 1.0 Sender: yi.jiazi@gmail.com Received: by 10.114.2.231 with HTTP; Tue, 5 Jul 2016 07:00:12 -0700 (PDT) In-Reply-To: <20160705134505.22259.85013.idtracker@ietfa.amsl.com> References: <20160705134505.22259.85013.idtracker@ietfa.amsl.com> From: Jiazi YI Date: Tue, 5 Jul 2016 16:00:12 +0200 X-Google-Sender-Auth: QhLJTZwZ3u4MpBqQ3DTcFy6FNCk Message-ID: To: manet Content-Type: multipart/alternative; boundary=001a113fbed232d3460536e3dfdd Archived-At: Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-olsrv2-multipath-10.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 14:00:18 -0000 --001a113fbed232d3460536e3dfdd Content-Type: text/plain; charset=UTF-8 Hi, We just submitted a new revision of the olsrv2-multipath draft. The updates are mainly based on the discussion in the session https://www.ietf.org/mail-archive/web/manet/current/msg19075.html Another important improvement is that we clarified the used of IPv6 source routing header. After discussion with the Alvaro, MANET chairs, 6man chairs, etc., we now use the approach described in https://www.ietf.org/mail-archive/web/manet/current/msg19149.html Generally speaking, we follow the packet format and processing of RFC6554, while use the experimental value of the IPv6 Routing Type. Thanks again for the valuable comments and discussions. If you have any further comments, please let us know. regards Jiazi ---------- Forwarded message ---------- From: Date: Tue, Jul 5, 2016 at 3:45 PM Subject: New Version Notification for draft-ietf-manet-olsrv2-multipath-10.txt To: Benoit Parrein , Jiazi Yi < jiazi@jiaziyi.com>, Benoit Parrein A new version of I-D, draft-ietf-manet-olsrv2-multipath-10.txt has been successfully submitted by Jiazi Yi and posted to the IETF repository. Name: draft-ietf-manet-olsrv2-multipath Revision: 10 Title: Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Document date: 2016-07-05 Group: manet Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-multipath-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ Htmlized: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-10 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-10 Abstract: This document specifies a multi-path extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. 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. The IETF Secretariat --001a113fbed232d3460536e3dfdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

We just submitted = a new revision of the olsrv2-multipath draft.=C2=A0

The updates are mainly based on the discussion in the session=C2=A0
=


Anot= her important improvement is that we clarified the used of IPv6 source rout= ing header. After discussion with the Alvaro, MANET chairs, 6man chairs, et= c., we now use the approach described in=C2=A0


Generally speakin= g, we follow the packet format and processing of RFC6554, while use the exp= erimental value of the IPv6 Routing Type.=C2=A0

Th= anks again for the valuable comments and discussions. If you have any furth= er comments, please let us know.=C2=A0

regards

Jiazi


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Tue, Jul 5, 2016 at 3:= 45 PM
Subject: New Version Notification for draft-ietf-manet-olsrv2-mult= ipath-10.txt
To: Benoit Parrein <Benoit.Parrein@polytech.univ-nantes.fr>, Jiazi= Yi <jiazi@jiaziyi.com>, Ben= oit Parrein <b= enoit.parrein@polytech.univ-nantes.fr>



A new version of I-D, draft-ietf-manet-olsrv2-multipath-10.txt
has been successfully submitted by Jiazi Yi and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-manet-olsrv2-multi= path
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A010
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multi-path Extension for the Optim= ized Link State Routing Protocol version 2 (OLSRv2)
Document date:=C2=A0 2016-07-05
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 manet
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 24
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-mane= t-olsrv2-multipath-10.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-10
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsr= v2-multipath-10

Abstract:
=C2=A0 =C2=A0This document specifies a multi-path extension for the Optimiz= ed Link
=C2=A0 =C2=A0State Routing Protocol version 2 (OLSRv2) to discover multiple=
=C2=A0 =C2=A0disjoint paths, so as to improve reliability of the OLSRv2 pro= tocol.
=C2=A0 =C2=A0The interoperability with OLSRv2 is retained.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a113fbed232d3460536e3dfdd-- From nobody Wed Jul 6 10:45:57 2016 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 5CD3C12D519 for ; Wed, 6 Jul 2016 10:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iQQOuk2yd-Q for ; Wed, 6 Jul 2016 10:45:54 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id 47AFF12D177 for ; Wed, 6 Jul 2016 10:45:53 -0700 (PDT) Received: (qmail 1393 invoked by uid 0); 6 Jul 2016 17:45:50 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 6 Jul 2016 17:45:50 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id FVlh1t01z2SSUrH01VlkeU; Wed, 06 Jul 2016 11:45:48 -0600 X-Authority-Analysis: v=2.1 cv=OPe0g0qB c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=cAmyUtKerLwA:10 a=5vjwwrbCAAAA:8 a=48vgC7mUAAAA:8 a=rWLHjOkUfME7mRvEMNsA:9 a=fBiHtIx5j6vQPLPc:21 a=Z1aNAUcjQ8S52-zQ:21 a=QEXdDO2ut3YA:10 a=pV4yRLctw-KkoPKGQz8o:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject; bh=Xq7ldc6AfvILFAyRF1jPaR2mD60LYasKUzdDFkFJk7s=; b=Ep+F6MsK4PJvZVH6JNuacIYpl9 aYQsQjCQWF/fRp/qtEjdEfGQ7bQ1jxRW7euFkM89b+p8y8BLPqcr2dUafsgrbW/O8V0uynsxWq0Rf fImIYVfpcrQRo5+JnkFmKxnDW; Received: from box313.bluehost.com ([69.89.31.113]:57792 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bKqtL-00058m-2y; Wed, 06 Jul 2016 11:45:43 -0600 To: Rick Taylor , draft-ietf-manet-dlep@ietf.org, manet@ietf.org, sratliff@idirect.net References: <3ca9ff337d414c9499cb7c0e34867971@VAUSDITCHM2.idirect.net> <25f3b91480d64425b4ec774506208029@VAUSDITCHM2.idirect.net> <1466586684.28636.15.camel@tropicalstormsoftware.com> <725f8efa-993f-e1d8-39ff-2e722294b63b@labn.net> <1466602693.28636.41.camel@tropicalstormsoftware.com> <1466673041.28636.63.camel@tropicalstormsoftware.com> <1557cee5ca0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Lou Berger Message-ID: <87d2a2ba-c5de-9426-53c7-30c7829e3bde@labn.net> Date: Wed, 6 Jul 2016 13:45:38 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1557cee5ca0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source-IP: 69.89.31.113 X-Exim-ID: 1bKqtL-00058m-2y X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: box313.bluehost.com ([127.0.0.1]) [69.89.31.113]:57792 X-Source-Auth: lberger@labn.net X-Email-Count: 0 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [manet] DLEP question X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 17:45:56 -0000 Rick, Do you have an ETA on this change? -- i.e., will the update be out before the Berlin draft cutoff? Thanks, Lou On 6/23/2016 7:04 AM, Lou Berger wrote: > Rick, > the proposed change will resolve my comment/concern. > > Thank you, > Lou > > On June 23, 2016 5:11:59 AM Rick Taylor wrote: > ... >> However, adding optional IP address/subnet information to the announce >> response is a minor change, and may cover a use-case we have not >> considered, and aligns the content with Destination Update. >> >> We will most likely be issuing an update to take onboard the AD >> comments we have received, so we have a good opportunity to address >> this. >> >> Thanks for really having a good look at the doc! >> >> Rick >> >>> Thanks, >>> Lou >>> >>> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 6 10:47:19 2016 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 8247E12D0AC; Wed, 6 Jul 2016 10:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4jjXHZy5aHl; Wed, 6 Jul 2016 10:47:15 -0700 (PDT) Received: from smtp2.idirect.net (smtp2.idirect.net [198.180.159.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502BC12D094; Wed, 6 Jul 2016 10:47:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,320,1464667200"; d="scan'208";a="1395835" IronPort-PHdr: =?us-ascii?q?9a23=3AtRjDqB0ny//jyLg3smDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?se4UKvad9pjvdHbS+e9qxAeQG96Ks7Qe1aGP6vqocFdDyK7JiGoFfp1IWk1Nou?= =?us-ascii?q?QttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXsq3G/pQQfBg/4fVIs?= =?us-ascii?q?YL+kQsiI0Y/ujrr60qaQSj0AvCC6b7J2IUf+hiTqne5Sv7FfLL0swADCuHpCdr?= =?us-ascii?q?ce72ppIVWOg0S0vZ/or9ZLuh5dsPM59sNGTb6yP+FhFeQZX3waNDUR49CjnxTZ?= =?us-ascii?q?QgaVri8YWGgMnRdSKwzM5he8WJrt5G+yjOt222GmNNzySqp8DS6j5KRDVAXvkC?= =?us-ascii?q?YMPjoi7GbNj9d3gr5EqQis4Rd4xtiQKMuZLvNwYubccM8UAG9IWMtNEiBFD5uU?= =?us-ascii?q?boYTAawGJ+kS593xvVIAsV6/CBWiQebmzDJUw3Py0LUS0uk9H0fBxgN2W5pEtX?= =?us-ascii?q?3SocndNaoOX6ay1qaChWHGZvVbxR/85ZTGNBc7rqffc6h3dJ+b80AzEwLLgBHY?= =?us-ascii?q?kpDsOTeYx65F53OB5vZkVOyho28rqht8qSTpwMow3NqazrkJw0zJoH0qiL0+Is?= =?us-ascii?q?e1HQsiOYap?= X-IPAS-Result: =?us-ascii?q?A2D9AAD6Qn1X/8n6+gpdGQEBAQEBg3Z8Bo0kq3GBbAsXC4V?= =?us-ascii?q?2AhyBRhQBAQEBAQEBAYELgjKCGgEBAQEDAQEBIBE6FwQCAQgOAwQBAQECAiMDA?= =?us-ascii?q?gICJQsUAQgIAgQBEgiINqxcj10BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhSe?= =?us-ascii?q?ETIRXgmqCWgWZDQYBjj+BcY1AhleJMx6EJm6Hc38BAQE?= From: "Ratliff, Stanley" To: Lou Berger , Rick Taylor , "draft-ietf-manet-dlep@ietf.org" , "manet@ietf.org" Thread-Topic: [manet] DLEP question Thread-Index: AQHRzA7Nwoeuk5LAXEuopotE78FYX5/0lMGwgABPlwD//73KwIAA1OcAgAAoe4CAACIRgIAAYMaAgADm0ICAAB+uAIAU3oEA//+9JQA= Date: Wed, 6 Jul 2016 17:47:13 +0000 Message-ID: <68de7ee473024428af6b0ed0890c8543@VAUSDITCHM2.idirect.net> References: <3ca9ff337d414c9499cb7c0e34867971@VAUSDITCHM2.idirect.net> <25f3b91480d64425b4ec774506208029@VAUSDITCHM2.idirect.net> <1466586684.28636.15.camel@tropicalstormsoftware.com> <725f8efa-993f-e1d8-39ff-2e722294b63b@labn.net> <1466602693.28636.41.camel@tropicalstormsoftware.com> <1466673041.28636.63.camel@tropicalstormsoftware.com> <1557cee5ca0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <87d2a2ba-c5de-9426-53c7-30c7829e3bde@labn.net> In-Reply-To: <87d2a2ba-c5de-9426-53c7-30c7829e3bde@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [manet] DLEP question X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 17:47:17 -0000 TG91LCANCg0KVGhhdCdzIHdoYXQgd2UncmUgaG9waW5nIGZvciAtIHRvIGdldCBpdCBvdXQgYmVm b3JlIHRoZSBkcmFmdCBjdXRvZmYuIFdpdGggdGhlIHByZXNzdXJlcyBvZiB0aGUgZGF5IGpvYiwg SSBjYW4ndCBndWFyYW50ZWUsIGJ1dCBJJ20gdHJ5aW5nLi4uIDstKSANCg0KUmVnYXJkcywNClN0 YW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb3UgQmVyZ2VyIFtt YWlsdG86bGJlcmdlckBsYWJuLm5ldF0NCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDA2LCAyMDE2 IDE6NDYgUE0NCj4gVG86IFJpY2sgVGF5bG9yIDxyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5j b20+OyBkcmFmdC1pZXRmLW1hbmV0LQ0KPiBkbGVwQGlldGYub3JnOyBtYW5ldEBpZXRmLm9yZzsg UmF0bGlmZiwgU3RhbmxleSA8c3JhdGxpZmZAaWRpcmVjdC5uZXQ+DQo+IFN1YmplY3Q6IFJlOiBb bWFuZXRdIERMRVAgcXVlc3Rpb24NCj4gDQo+IFJpY2ssDQo+IA0KPiAgICAgRG8geW91IGhhdmUg YW4gRVRBIG9uIHRoaXMgY2hhbmdlPyAtLSBpLmUuLCB3aWxsIHRoZSB1cGRhdGUgYmUgb3V0IGJl Zm9yZQ0KPiB0aGUgQmVybGluIGRyYWZ0IGN1dG9mZj8NCj4gDQo+IFRoYW5rcywNCj4gTG91DQo+ IE9uIDYvMjMvMjAxNiA3OjA0IEFNLCBMb3UgQmVyZ2VyIHdyb3RlOg0KPiA+IFJpY2ssDQo+ID4g dGhlIHByb3Bvc2VkIGNoYW5nZSB3aWxsIHJlc29sdmUgbXkgY29tbWVudC9jb25jZXJuLg0KPiA+ DQo+ID4gVGhhbmsgeW91LA0KPiA+IExvdQ0KPiA+DQo+ID4gT24gSnVuZSAyMywgMjAxNiA1OjEx OjU5IEFNIFJpY2sgVGF5bG9yIDxyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb20+DQo+IHdy b3RlOg0KPiA+IC4uLg0KPiA+PiBIb3dldmVyLCBhZGRpbmcgb3B0aW9uYWwgSVAgYWRkcmVzcy9z dWJuZXQgaW5mb3JtYXRpb24gdG8gdGhlDQo+ID4+IGFubm91bmNlIHJlc3BvbnNlIGlzIGEgbWlu b3IgY2hhbmdlLCBhbmQgbWF5IGNvdmVyIGEgdXNlLWNhc2Ugd2UgaGF2ZQ0KPiA+PiBub3QgY29u c2lkZXJlZCwgYW5kIGFsaWducyB0aGUgY29udGVudCB3aXRoIERlc3RpbmF0aW9uIFVwZGF0ZS4N Cj4gPj4NCj4gPj4gV2Ugd2lsbCBtb3N0IGxpa2VseSBiZSBpc3N1aW5nIGFuIHVwZGF0ZSB0byB0 YWtlIG9uYm9hcmQgdGhlIEFEDQo+ID4+IGNvbW1lbnRzIHdlIGhhdmUgcmVjZWl2ZWQsIHNvIHdl IGhhdmUgYSBnb29kIG9wcG9ydHVuaXR5IHRvIGFkZHJlc3MNCj4gPj4gdGhpcy4NCj4gPj4NCj4g Pj4gVGhhbmtzIGZvciByZWFsbHkgaGF2aW5nIGEgZ29vZCBsb29rIGF0IHRoZSBkb2MhDQo+ID4+ DQo+ID4+IFJpY2sNCj4gPj4NCj4gPj4+IFRoYW5rcywNCj4gPj4+IExvdQ0KPiA+Pj4NCj4gPj4+ DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiA+IG1hbmV0QGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KPiANCj4gDQoNCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpUaGlzIGVsZWN0 cm9uaWMgbWVzc2FnZSBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgY29udGFpbnMK aW5mb3JtYXRpb24gZnJvbSBpRGlyZWN0LCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCwgcHJvcHJp ZXRhcnkKYW5kL29yIGNvbmZpZGVudGlhbC4gSXQgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsCm9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3Nl ZC4gSWYgeW91IGFyZSBub3QgdGhlIG9yaWdpbmFsCnJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJl c3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIHRoZSBlbWFpbCB0byB0aGUKaW50ZW5kZWQgcmVjaXBp ZW50LCBiZSBhZHZpc2VkIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbAppbiBlcnJv ciwgYW5kIHRoYXQgYW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZm9yd2FyZGluZywgcHJpbnRpbmcs IG9yCmNvcHlpbmcgb2YgdGhpcyBlbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3Ug cmVjZWl2ZWQgdGhpcyBlbWFpbAppbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgaW1tZWRp YXRlbHkgbm90aWZ5IHRoZSBzZW5kZXIuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCg== From nobody Wed Jul 6 10:49:56 2016 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 3AC3512D505 for ; Wed, 6 Jul 2016 10:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZTZRNxWiKPr for ; Wed, 6 Jul 2016 10:49:48 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 0EBA812D0AC for ; Wed, 6 Jul 2016 10:49:48 -0700 (PDT) Received: (qmail 18314 invoked by uid 0); 6 Jul 2016 17:49:46 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 6 Jul 2016 17:49:46 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id FVpj1t00G2SSUrH01Vpmed; Wed, 06 Jul 2016 11:49:46 -0600 X-Authority-Analysis: v=2.1 cv=ecGuId0H c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=cAmyUtKerLwA:10 a=wU2YTnxGAAAA:8 a=5vjwwrbCAAAA:8 a=48vgC7mUAAAA:8 a=texx4mzSAAAA:8 a=DLxNTdEm4b0iqjsvuakA:9 a=KCZb6lnTi8TnbJyA:21 a=T-NQzr0mmtbFGg0A:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=pV4yRLctw-KkoPKGQz8o:22 a=w1C3t2QeGrPiZgrLijVG:22 a=e3VUpYyorgOgWWTuA9h7:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject; bh=CV24cS1xvTobW6oVuNsuJlrQ7WqqEVbyG6iBQq221rs=; b=i2ILU86VOHY1Emyjy059/4tK4I BQZJYXLirkX0XVfdnw9FOfYYIV6Ezc4eWhfYcqYXii2Dp1WlL5GDzZIkzGHoku0FACSwwllX27VdF plUFXcF1JrZbbD/ZbEwDBTLRM; Received: from box313.bluehost.com ([69.89.31.113]:59578 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bKqxC-0005oQ-W4; Wed, 06 Jul 2016 11:49:43 -0600 To: "Ratliff, Stanley" , Rick Taylor , "draft-ietf-manet-dlep@ietf.org" , "manet@ietf.org" References: <3ca9ff337d414c9499cb7c0e34867971@VAUSDITCHM2.idirect.net> <25f3b91480d64425b4ec774506208029@VAUSDITCHM2.idirect.net> <1466586684.28636.15.camel@tropicalstormsoftware.com> <725f8efa-993f-e1d8-39ff-2e722294b63b@labn.net> <1466602693.28636.41.camel@tropicalstormsoftware.com> <1466673041.28636.63.camel@tropicalstormsoftware.com> <1557cee5ca0.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <87d2a2ba-c5de-9426-53c7-30c7829e3bde@labn.net> <68de7ee473024428af6b0ed0890c8543@VAUSDITCHM2.idirect.net> From: Lou Berger Message-ID: <77bd08d0-c605-faaa-be03-7961d35fe638@labn.net> Date: Wed, 6 Jul 2016 13:49:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <68de7ee473024428af6b0ed0890c8543@VAUSDITCHM2.idirect.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source-IP: 69.89.31.113 X-Exim-ID: 1bKqxC-0005oQ-W4 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: box313.bluehost.com ([127.0.0.1]) [69.89.31.113]:59578 X-Source-Auth: lberger@labn.net X-Email-Count: 0 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [manet] DLEP question X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 17:49:54 -0000 Thank you! On 7/6/2016 1:47 PM, Ratliff, Stanley wrote: > Lou, > > That's what we're hoping for - to get it out before the draft cutoff. With the pressures of the day job, I can't guarantee, but I'm trying... ;-) > > Regards, > Stan > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, July 06, 2016 1:46 PM >> To: Rick Taylor ; draft-ietf-manet- >> dlep@ietf.org; manet@ietf.org; Ratliff, Stanley >> Subject: Re: [manet] DLEP question >> >> Rick, >> >> Do you have an ETA on this change? -- i.e., will the update be out before >> the Berlin draft cutoff? >> >> Thanks, >> Lou >> On 6/23/2016 7:04 AM, Lou Berger wrote: >>> Rick, >>> the proposed change will resolve my comment/concern. >>> >>> Thank you, >>> Lou >>> >>> On June 23, 2016 5:11:59 AM Rick Taylor >> wrote: >>> ... >>>> However, adding optional IP address/subnet information to the >>>> announce response is a minor change, and may cover a use-case we have >>>> not considered, and aligns the content with Destination Update. >>>> >>>> We will most likely be issuing an update to take onboard the AD >>>> comments we have received, so we have a good opportunity to address >>>> this. >>>> >>>> Thanks for really having a good look at the doc! >>>> >>>> Rick >>>> >>>>> Thanks, >>>>> Lou >>>>> >>>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> > > _____________________________________________________ > This electronic message and any files transmitted with it contains > information from iDirect, which may be privileged, proprietary > and/or confidential. It is intended solely for the use of the individual > or entity to whom they are addressed. If you are not the original > recipient or the person responsible for delivering the email to the > intended recipient, be advised that you have received this email > in error, and that any use, dissemination, forwarding, printing, or > copying of this email is strictly prohibited. If you received this email > in error, please delete it and immediately notify the sender. > _____________________________________________________ From nobody Fri Jul 8 00:37:26 2016 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 8927212D0EC for ; Fri, 8 Jul 2016 00:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thomasclausen.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jola5XVOBRW for ; Fri, 8 Jul 2016 00:37:22 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59D812B04E for ; Fri, 8 Jul 2016 00:37:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id AA90B280785 for ; Fri, 8 Jul 2016 00:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thomasclausen.org; s=1.tigertech; t=1467963442; bh=D1/N3B+Fp8XVJC3hcKMx+8dW7Xy26Oo6IR50/5nlUSc=; h=From:Date:Subject:References:In-Reply-To:To:From; b=kwBHxDRBFJnud/uINj4LosVQSj7HdE06mq+2qnK/mprfJNoMtS6sqj+XjyYAGQ2Lo bMPJfBrIPlt0dUwZQduHm4OI+blhUDMqVEkQebrnBrEPnbgc+/OEZyBIF2q4lWEwBE V57BK42KgpbKPXzUIf4Pyg+VeWHwRuHab5/68VxQ= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.1] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 50AEB280150 for ; Fri, 8 Jul 2016 00:37:22 -0700 (PDT) From: Thomas Heide Clausen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Fri, 8 Jul 2016 09:37:20 +0200 Message-Id: <078BE592-5D84-41C3-B3D4-E7DD28F1DE6E@thomasclausen.org> References: In-Reply-To: To: manet@ietf.org X-Mailer: iPad Mail (14A5261v) Archived-At: Subject: Re: [manet] Last call on OLSRv2 Sec Threats still open X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 07:37:25 -0000 According to my calendar, July 1 has come and past, now. Thomas > On 22 Jun 2016, at 15:56, Justin Dean wrote: >=20 > There was a mixup. Last Call for OLSRv2-Sec-Threats document is still ope= n and will end on July 1st. I'll take this opportunity to again remind peop= le to please read and comment to the list. >=20 > Justin > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Fri Jul 8 12:03:14 2016 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 3CA6612D0AF for ; Fri, 8 Jul 2016 12:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.623 X-Spam-Level: X-Spam-Status: No, score=-5.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VnivAXYnheg for ; Fri, 8 Jul 2016 12:03:09 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id D9B6012D686 for ; Fri, 8 Jul 2016 12:02:59 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u68J0FpO034814 for ; Fri, 8 Jul 2016 15:00:15 -0400 From: "Wiggins, David - 0665 - MITLL" To: manet IETF Thread-Topic: DLEP Credit Windowing synchronization issue Thread-Index: AQHR2UtV73uTy8brFkmOHy3EpK/j4A== Date: Fri, 8 Jul 2016 19:02:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3550834973_193390408" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-08_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607080179 Archived-At: Subject: [manet] DLEP Credit Windowing synchronization issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:03:13 -0000 --B_3550834973_193390408 Content-type: multipart/alternative; boundary="B_3550834973_193337988" --B_3550834973_193337988 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I think I see a problem in the Credit Windowing extension draft. In a nutshell, the way that credit window synchronization is specified will probably cause destinations to endlessly cycle up and down. The text at issue is in section 9.2 (draft 4): Upon receipt of a Credit Window Status data item, an implementation SHOULD compare its own credit counts with that of the originator. If the receiver of Credit Window Status detects that the local credit counts are not synchronized with the originator, the receiving implementation MAY either: o Attempt resynchronization using an additional Credit Grant, if applicable, or o Issue a DLEP Destination Down message, to clear credit counts on the session. Let's say that an implementation does send periodic Destination Updates containing Credit Window Status data items, as is suggested a bit further down in the draft. Furthermore, let's pretend that the sender is able to fill in the credit counts that are current at the instant the update message is put on the wire. There will still be some delay, maybe just a few milliseconds, before the DLEP peer receives and processes the update message. During that time, additional data traffic might have been sent, which would alter the credit counts on both sides, but the update message will still have the snapshot taken when it was sent. If there is a steady stream of data traffic, this could be quite likely to occur. So the receiving peer's credit counts will not match the ones in the message. I interpret the draft text "counts are not synchronized" to mean "counts are not exactly equal." Assuming additional data traffic was sent while the update was in flight (as described above), the counts on the receiving side will be lower than those in the update message. So the draft's first remedy, "attempt resynchronization using an additional Credit Grant," doesn't make sense because the sender already appears to have more credits than it should (and credit grants can't be negative). The only choice left is to Down the destination. Presumably it will come back up eventually, only to have it all happen again. This could possibly be solved by having a margin in the credit comparison, e.g., only assume we're out of sync if off by over 1000 credits. I'm not sure how to pick the number for the margin, though. It depends on the traffic flow. This is just the first fix that came to mind; there are likely better strategies. Let me know if this makes sense or if I have missed something. Thanks, David --B_3550834973_193337988 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
I think I see a problem in the Credit Windowing extension draft.
In a nutshell, the way that credit wind= ow synchronization is specified
wil= l probably cause destinations to endlessly cycle up and down.

The= text at issue is in section 9.2 (draft 4):

   Upon rec= eipt of a Credit Window Status data item, an implementation
   SHOULD compare its own credit counts w= ith that of the originator.  If
   the receiver of Credit Window Status detects that the lo= cal credit
   counts are = not synchronized with the originator, the receiving
   implementation MAY either: o Attempt resynchro= nization using an
   addi= tional Credit Grant, if applicable, or o Issue a DLEP Destination
   Down message, to clear credit co= unts on the session.

Let's say that an implementation does send p= eriodic Destination Updates
contain= ing Credit Window Status data items, as is suggested a bit further
down in the draft.  Furthermore, l= et's pretend that the sender is able to
fill in the credit counts that are current at the instant the update
message is put on the wire. &nbs= p;There will still be some delay, maybe just a
few milliseconds, before the DLEP peer receives and processes th= e update
message.  During= that time, additional data traffic might have been sent,
which would alter the credit counts on both sides, bu= t the update message
will still hav= e the snapshot taken when it was sent.  If there is a steady
=
stream of data traffic, this could be qu= ite likely to occur.  So the
receiving peer's credit counts will not match the ones in the message.

I interpret the draft text "counts are not synchronized" to mean "= counts
are not exactly equal." = ; Assuming additional data traffic was sent while
the update was in flight (as described above), the count= s on the receiving
side will be low= er than those in the update message.  So the draft's first
remedy, "attempt resynchronization using a= n additional Credit Grant,"
doesn't= make sense because the sender already appears to have more credits
than it should (and credit grants can't be = negative).  The only choice
left is to Down the destination.  Presumably it will come back = up
eventually, only to have it all = happen again.

This could possibly be solved by having a margin in= the credit comparison,
e.g., only = assume we're out of sync if off by over 1000 credits.  I'm not
sure how to pick the number for the ma= rgin, though.  It depends on the
traffic flow.  This is just the first fix that came to min= d; there are
likely better strategi= es.

Let me know if this makes sense or if I have missed something= .

Thanks,
David

--B_3550834973_193337988-- --B_3550834973_193390408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgoY4rwNAAAAAHNuMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTYwMjEwMTMwNjAwWhcNMTkwMjA5MTMwNjAwWjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCiKFVMUMne1LGJfzRn943ZeccfuQI37zhvT3/LYCK/6Yaa jKbXmDz3AoT/XI551vtwvvc0wQNRfNIkB0oYfa8OkD+EYqO3sDV4IejFP9XQKkRxgb3bESa8 Frl30C0vScQ3A8h3mSQ8lFOLgo3ndiGnfF0mtUt2TbE7LAO4Jn3yxw1JqXgDk/gbXBy3zSsj uqQeWWlj2OQ3D1WBTM0fEZjMLCUfAANHxE58isDHHksnlm20EOBoaqNStCcYbFQNSjlBQ0ng 0dky+2Wx8lllMttw0R9oznENQ6RKLrzQaTSQ5tRjYpGLGIPxAhPL7MWerZrDZrdsjwTMJoge +siq0HJdAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUIABH8cDVoyihib5dIjevNJCX+r4wDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQBFmdkJgK08 BFDtjsYcbWuUE5mzlX/7RoxLNHbg/yc5w8QnpzblBYAKH4bCZJVBfPA6I7hTrOdTs/zp4LWo lD4tyS5Nz3+D4UrBCccvoOSdccD4R4hhqCLLUwX58GHETEafw6G+HbadVhFtmIdc1l23rwCw c/U2/I2Apl6R7bfpYXHCdPc0qW2ierJVPQUDtacF7vOLDRwLc7XqL1V+TfMU1yxaClfQbNXD auyuCDzQgMN1lvAMvUaA7EeUlZ8aQRwOmMMiaqDXftUp5aAufYz0oKHNwhrLlmssypjKJ0pP e3VJ6Lo6Ujx0v7GfXyW1xBDpe2GX6WQLYSfgwjU8XF6sMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKGOK8DQAAAABzbjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFD5RJAOO2XNWw3X+ 6WkGk8cQdkjuMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDcwODE5MDI1M1owDQYJKoZIhvcNAQEBBQAEggEALYuxWjr5YC9U5BmRELXCd/o160ovfVKp 2Uh2jpyZT0TxE41eq2iI/uOWt7Tuaikmxv27xt1o0U/qPTThEGH7Z49o7sCuKpbpshhjwf/h zBIggjFog0KGd0dvAWgjJZR5DqR6AalMJtcPxBRjEXdPQKLFtu4v44QIDUbdFmhX42bzIEuw C1GNAsXIcTPNNwSdlmITIBHYSyDtR2WFTM2qo5dtg6MTTEDnZSMGXJbn4zLwidsL0RYMISrM XxT5M022N4WcXLLk7gz0O5jxln/0rc4mCNriexNqs6jjupE/2owOmFZPn/Br9duBbwVAzbYe 2p6QxqxH7u1LVKXdKL0OKg== --B_3550834973_193390408-- From nobody Tue Jul 12 02:56:34 2016 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 33D0612D769 for ; Tue, 12 Jul 2016 02:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.206 X-Spam-Level: X-Spam-Status: No, score=-8.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVcQEb9eQz_a for ; Tue, 12 Jul 2016 02:56:29 -0700 (PDT) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4F912B026 for ; Tue, 12 Jul 2016 02:56:29 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.28,351,1464649200"; d="scan'208,217"; a="38537090" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 12 Jul 2016 10:56:27 +0100 X-IronPort-AV: E=Sophos;i="5.28,351,1464649200"; d="scan'208,217";a="125676325" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 12 Jul 2016 10:56:27 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.169]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Tue, 12 Jul 2016 10:56:19 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: Reviewing draft-ietf-manet-olsrv2-multipath-10 Thread-Index: AdHcIPCTIck57pgnQ/yeM54X9HDzaA== Date: Tue, 12 Jul 2016 09:56:19 +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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EA401GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 09:56:32 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EA401GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I haven't got to the end yet, but there are some points to make as far as I= have got, and in order not to wait until finished. In particular I have a = significant issue in Section 8.2. Section 1.1 third bullet. As those scenarios haven't been established, I su= ggest "may" before "require". And perhaps "Some" rather than "Certain". Section 1.1 fourth bullet, I don't see anything in the draft supporting thi= s (delay). Page 4, first paragraph "and" after "specification". Page 4, third bullet, not sure what "co-relation" means. Page 4, fifth bullet, should indicate IPv4. Page 5, second bullet ("The disjoint ..."). I'm not sure what "by definitio= n" means here. Obviously lost packets have no ordering. But the order of th= ose packets left usually matters. Page 5, last bullet. I think it's important to note that there's no work ye= t defining how (or indeed if) MT and MP OLSRv2 can interoperate. Page 6 "in the air". I don't this this helps. I think we usually say "TLV T= ype" - I would (in due course) check that the RFC Editor makes consistent w= ith RFC 5444 - though it can't hurt to do that as well. Page 7, second bullet. I think it's useful to note that the reactive work i= s local, there are no message transmission delays introduced by it. Section 5.1, MAX_SRC_HOPS. Why must it be set to 0 in an IPv6 network? And = for IPv4 networks it must be less than 11 - but not 0. (0 is less than 11!) CUTOFF_RATION "greater than or equal" is more idiomatic. Section 6 first paragraph I think mixes discussion of signalling and data p= ackets that could be clearer. Section 6.1, first line. I think "use" is better than "share". Section 7.1 SR_time - Tuple, not Tuples. Section 7.2 PT_addresses. If n is the number of intermediate routers, then = the hop count is n+1. Section 8.1 "Please note that" is odd wording. Section 8.1 "does not carry". Need normative wording. Previous discussion o= n why this should be "MUST NOT" (I think better than "SHOULD NOT". But then= the problem is there's no explanation, and it's really easy for someone to= say "why not just add ..." without an appreciation of why not. Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really careful to = allow routers to independently pick parameters - it's why messages have val= idity times. This breaks that, by using a local SR+HOLD_TIME for the validi= ty time of remote information (SR_addr). This is not acceptable. This needs= to be either the validity time of the HELLO or TC message or some other me= chanism. (I have not yet checked if there are any other such cases.) -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EA401GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

I haven’t got to the end yet, but there are so= me points to make as far as I have got, and in order not to wait until fini= shed. In particular I have a significant issue in Section 8.2.

 

Section 1.1 third bullet. As those scenarios haven&#= 8217;t been established, I suggest “may” before “require&= #8221;. And perhaps “Some” rather than “Certain”.

 

Section 1.1 fourth bullet, I don’t see anythin= g in the draft supporting this (delay).

 

Page 4, first paragraph “and” after R= 20;specification”.

 

Page 4, third bullet, not sure what “co-relati= on” means.

 

Page 4, fifth bullet, should indicate IPv4.

 

Page 5, second bullet (“The disjoint …&#= 8221;). I’m not sure what “by definition” means here. Obv= iously lost packets have no ordering. But the order of those packets left u= sually matters.

 

Page 5, last bullet. I think it’s important to= note that there’s no work yet defining how (or indeed if) MT and MP = OLSRv2 can interoperate.

 

Page 6 “in the air”. I don’t this = this helps. I think we usually say “TLV Type” - I would (in due= course) check that the RFC Editor makes consistent with RFC 5444 - though = it can’t hurt to do that as well.

 

Page 7, second bullet. I think it’s useful to = note that the reactive work is local, there are no message transmission del= ays introduced by it.

 

Section 5.1, MAX_SRC_HOPS. Why must it be set to 0 i= n an IPv6 network? And for IPv4 networks it must be less than 11 - but not = 0. (0 is less than 11!)

 

CUTOFF_RATION “greater than or equal” is= more idiomatic.

 

Section 6 first paragraph I think mixes discussion o= f signalling and data packets that could be clearer.

 

Section 6.1, first line. I think “use” i= s better than “share”.

 

Section 7.1 SR_time - Tuple, not Tuples.<= /p>

 

Section 7.2 PT_addresses. If n is the number of inte= rmediate routers, then the hop count is n+1.

 

Section 8.1 “Please note that” is odd wo= rding.

 

Section 8.1 “does not carry”. Need norma= tive wording. Previous discussion on why this should be “MUST NOTR= 21; (I think better than “SHOULD NOT”. But then the problem is = there’s no explanation, and it’s really easy for someone to say= “why not just add …” without an appreciation of why not.

 

Section 8.2 Everywhere in OLSRv2 (and NHDP) we have = been really careful to allow routers to independently pick parameters - it&= #8217;s why messages have validity times. This breaks that, by using a loca= l SR+HOLD_TIME for the validity time of remote information (SR_addr). This is not acceptable. This needs to be eit= her the validity time of the HELLO or TC message or some other mechanism. (= I have not yet checked if there are any other such cases.)

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________= ________________________________________________

T:  +44 (0)1245 24= 2194  |  E: chris.dearlove@baesystems.com

BAE Systems Appli= ed Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Esse= x CM2 8HN.
www.= baesystems.com/ai

B= AE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guil= dford, Surrey, GU2 7YP

 

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EA401GLKXM0002VGREEN_-- From nobody Tue Jul 12 07:43:00 2016 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 1483012DC48 for ; Tue, 12 Jul 2016 07:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 395JIfj4-ssa for ; Tue, 12 Jul 2016 07:42:56 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEE412D85E for ; Tue, 12 Jul 2016 06:55:27 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id q132so14302016lfe.3 for ; Tue, 12 Jul 2016 06:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=M2yDLaqyEZgcqNIw/GOQfLH5kQPvuzrJSV6wEzs1Z/E=; b=D5Nro0YewZvnAl6vlg+5nsoZt8Tj4E1EbygBPeeg+MRGylwuEwUdqRa4yXnikm/THe hAarAzJkQQl1mbTeE0hBvvKRSWD5AnnkIoLQuIxjqE7GeU2+UuqNrypWNkrP//vyoo+w LfdxKWu0LD20x87oJJe47HpoN6YKyPDnlz1pJEXBIsUZITpCZGBJXKBKCjg8vfKonm5L 03WxVSsRpJnt05oQynHaFZabOQHTaIDZjfTVLjNuhLGSbV/vUPm6Hp6TM0OW7n5Pid+v 3VMWHaJU4s0DrOeLgD8CfUAbEvc7VUINdsl85Ji0rBUjO1KCKpxXXZc+n0Qe5Htiqk7F lswA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=M2yDLaqyEZgcqNIw/GOQfLH5kQPvuzrJSV6wEzs1Z/E=; b=Gavdv4ZSebNnhoM3YLrJaYtxXkohVh+AqiApg7SoNdcJGrbzqTsU7tWZ9lM2G1OhnG sI3Q2LMG1oBCFWwrCfAJqN7+gbUqqEGeQKpq4MVCjcJTu1GteT6XGY5oK3DZc3rYyQfP h6zHAOsMswDJM3gX5pUAW4njSlhPoHt7y6aOgwYdJEa7v5ubF/O6TEVb/PW4TmnAWm02 U+zekBIYV0/OduQ6/REL+DtpbQGB8JAvi4kOau5C8ghXrb7m/lErDPogxUNnQFUjjGUQ cLnAYZYhQ5PvqtpprwwuGR41Uy5xbq+wJvGf7IwS2iwd3FBXkLBpRMlLJZjMGX0bdXCk en6A== X-Gm-Message-State: ALyK8tJ81AkMrPwZ2QUFxoGhfkW6ANiWyqX56S6+oWXMr7fCh9fsJULntviXu0DxSlys93sMNjcXp6zzvKAu0Q== X-Received: by 10.25.214.161 with SMTP id p33mr1115104lfi.169.1468331725923; Tue, 12 Jul 2016 06:55:25 -0700 (PDT) MIME-Version: 1.0 Sender: yi.jiazi@gmail.com Received: by 10.114.2.231 with HTTP; Tue, 12 Jul 2016 06:55:25 -0700 (PDT) In-Reply-To: References: From: Jiazi YI Date: Tue, 12 Jul 2016 15:55:25 +0200 X-Google-Sender-Auth: u74MIljwhxbVR_61Ji03b3kb67g Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a1140d2beefb77e0537709e61 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 14:42:58 -0000 --001a1140d2beefb77e0537709e61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Chris, Thanks for your comments. On the issue related to section 8.2 first: On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > I haven=E2=80=99t got to the end yet, but there are some points to make a= s far as > I have got, and in order not to wait until finished. In particular I have= a > significant issue in Section 8.2. > > > > > > Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really careful t= o > allow routers to independently pick parameters - it=E2=80=99s why message= s have > validity times. This breaks that, by using a local SR+HOLD_TIME for the > validity time of remote information (SR_addr). This is not acceptable. Th= is > needs to be either the validity time of the HELLO or TC message or some > other mechanism. (I have not yet checked if there are any other such case= s.) > Actually, the SR_HOLD_TIME depends on the TC_INTERVAL, which is not local and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2? best Jiazi > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > ******************************************************************** > 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 > > --001a1140d2beefb77e0537709e61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chris,=C2=A0

Thanks for your comment= s. On the issue related to section 8.2 first:

On Tue, Jul 12, 2016 at 11:56 AM, Dearlove,= Christopher (UK) <chris.dearlove@baesystems.com> wrote:

I haven=E2=80=99t got to the end yet, but there are = some points to make as far as I have got, and in order not to wait until fi= nished. In particular I have a significant issue in Section 8.2.<= /u>

=C2=A0

<s= nip>=C2=A0

=C2=A0

Section 8.2 Everywhere in OLSRv2 (and NHDP) we have = been really careful to allow routers to independently pick parameters - it= =E2=80=99s why messages have validity times. This breaks that, by using a l= ocal SR+HOLD_TIME for the validity time of remote information (SR_addr). This is not acceptable. This needs to be eit= her the validity time of the HELLO or TC message or some other mechanism. (= I have not yet checked if there are any other such cases.)

<= /blockquote>

Actually, the SR_HOLD_TIME depends on the T= C_INTERVAL, which is not local and similar to other foo_HOLD_TIMEs in NHDP/= OLSRv2?=C2=A0

best

Jiazi<= /div>
=C2=A0

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
_____________________________________________________= _____________________

T: =C2= =A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

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


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


--001a1140d2beefb77e0537709e61-- From nobody Tue Jul 12 09:01:42 2016 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 25DEA12D0B6 for ; Tue, 12 Jul 2016 09:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AkKZzCIDs5d for ; Tue, 12 Jul 2016 09:01:38 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F16212D1A3 for ; Tue, 12 Jul 2016 09:01:37 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.28,352,1464649200"; d="scan'208,217"; a="88003443" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 12 Jul 2016 17:01:35 +0100 X-IronPort-AV: E=Sophos;i="5.28,352,1464649200"; d="scan'208,217";a="125773449" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasmds016.greenlnk.net with ESMTP; 12 Jul 2016 17:01:35 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.169]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0248.002; Tue, 12 Jul 2016 17:01:35 +0100 From: "Dearlove, Christopher (UK)" To: Jiazi YI Thread-Topic: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 Thread-Index: AdHcIPCTIck57pgnQ/yeM54X9HDzaAAG7e2AAAZRIsA= Date: Tue, 12 Jul 2016 16:01:34 +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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EA65DGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 16:01:40 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EA65DGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIHRoYXTigJlzIG1pc3NpbmcgdGhlIHBvaW50Lg0KDQpUaGUgcGF0dGVybiBpcyBwYXJhbWV0 ZXIgKGUuZy4gVF9IT0xEX1RJTUUpIHNldHMgZmllbGQgaW4gbWVzc2FnZSAodmFsaWRpdHkgdGlt ZSBpbiBUQyBtZXNzYWdlKS4gRXhwaXJ5IHRpbWVzIGluIFR1cGxlcyBhcmUgc2V0IGZyb20gdmFs aWRpdHkgdGltZXMgaW4gbWVzc2FnZXMuDQoNClVzaW5nIGEgbG9jYWwgcGFyYW1ldGVyIHRvIHNl dCBhIGhvbGQgdGltZSBmb3IgcmVjZWl2ZWQgaW5mb3JtYXRpb24gaXMgYnJva2VuLiBZb3XigJls bCBzZWUgdGhhdCBpZiB0aGUgcGFyYW1ldGVyIHZhbHVlcyBhcmUgZGlmZmVyZW50LiAoVHJ5IGxv bmcgdmFsdWVzIGF0IG5vZGUgQSwgc2hvcnQgdmFsdWVzIGF0IG5vZGUgQiwgYW5kIHdhdGNoIGlm IHlvdSB1c2UgQuKAmXMgcGFyYW1ldGVyIHRoYW4gdGhlIGluZm9ybWF0aW9uIHdpbGwgZXhwaXJl IGJlZm9yZSBiZWluZyByZWZyZXNoZWQuKQ0KDQpUaGlzIGlzIGEgbXVzdCBjaGFuZ2UgZGV0YWls Lg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXIN CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllcw0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVA YmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpC QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBh cmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0 ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBw bGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMg Tm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1 aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCkZyb206IHlpLmppYXppQGdtYWlsLmNvbSBbbWFp bHRvOnlpLmppYXppQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIEppYXppIFlJDQpTZW50OiAxMiBK dWx5IDIwMTYgMTQ6NTUNClRvOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KQ2M6IG1hbmV0 QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBSZXZpZXdpbmcgZHJhZnQtaWV0Zi1tYW5l dC1vbHNydjItbXVsdGlwYXRoLTEwDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ug b3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4g ZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hl dGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMg b3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBj YW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8v aW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRz L0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1 c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQu YmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0Rl YWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KSGkgQ2hyaXMsDQoNClRo YW5rcyBmb3IgeW91ciBjb21tZW50cy4gT24gdGhlIGlzc3VlIHJlbGF0ZWQgdG8gc2VjdGlvbiA4 LjIgZmlyc3Q6DQoNCk9uIFR1ZSwgSnVsIDEyLCAyMDE2IGF0IDExOjU2IEFNLCBEZWFybG92ZSwg Q2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpJIGhhdmVu4oCZdCBnb3QgdG8g dGhlIGVuZCB5ZXQsIGJ1dCB0aGVyZSBhcmUgc29tZSBwb2ludHMgdG8gbWFrZSBhcyBmYXIgYXMg SSBoYXZlIGdvdCwgYW5kIGluIG9yZGVyIG5vdCB0byB3YWl0IHVudGlsIGZpbmlzaGVkLiBJbiBw YXJ0aWN1bGFyIEkgaGF2ZSBhIHNpZ25pZmljYW50IGlzc3VlIGluIFNlY3Rpb24gOC4yLg0KDQo8 c25pcD4NCg0KU2VjdGlvbiA4LjIgRXZlcnl3aGVyZSBpbiBPTFNSdjIgKGFuZCBOSERQKSB3ZSBo YXZlIGJlZW4gcmVhbGx5IGNhcmVmdWwgdG8gYWxsb3cgcm91dGVycyB0byBpbmRlcGVuZGVudGx5 IHBpY2sgcGFyYW1ldGVycyAtIGl04oCZcyB3aHkgbWVzc2FnZXMgaGF2ZSB2YWxpZGl0eSB0aW1l cy4gVGhpcyBicmVha3MgdGhhdCwgYnkgdXNpbmcgYSBsb2NhbCBTUitIT0xEX1RJTUUgZm9yIHRo ZSB2YWxpZGl0eSB0aW1lIG9mIHJlbW90ZSBpbmZvcm1hdGlvbiAoU1JfYWRkcikuIFRoaXMgaXMg bm90IGFjY2VwdGFibGUuIFRoaXMgbmVlZHMgdG8gYmUgZWl0aGVyIHRoZSB2YWxpZGl0eSB0aW1l IG9mIHRoZSBIRUxMTyBvciBUQyBtZXNzYWdlIG9yIHNvbWUgb3RoZXIgbWVjaGFuaXNtLiAoSSBo YXZlIG5vdCB5ZXQgY2hlY2tlZCBpZiB0aGVyZSBhcmUgYW55IG90aGVyIHN1Y2ggY2FzZXMuKQ0K DQpBY3R1YWxseSwgdGhlIFNSX0hPTERfVElNRSBkZXBlbmRzIG9uIHRoZSBUQ19JTlRFUlZBTCwg d2hpY2ggaXMgbm90IGxvY2FsIGFuZCBzaW1pbGFyIHRvIG90aGVyIGZvb19IT0xEX1RJTUVzIGlu IE5IRFAvT0xTUnYyPw0KDQpiZXN0DQoNCkppYXppDQoNCg0KLS0NCkNocmlzdG9waGVyIERlYXJs b3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZSBMYWJvcmF0b3JpZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0 NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5k ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hu b2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3 LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lz dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQg JiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2gg UGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KVGhpcyBl bWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVk DQpyZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZA0KcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBh bmQgbm90aWZ5IHRoZSBzZW5kZXIuDQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBm b3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yDQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0 Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tYW5ldA0KDQo= --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EA65DGLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ObywgdGhhdOKAmXMgbWlzc2lu ZyB0aGUgcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgcGF0dGVybiBpcyBwYXJhbWV0ZXIgKGUuZy4gVF9I T0xEX1RJTUUpIHNldHMgZmllbGQgaW4gbWVzc2FnZSAodmFsaWRpdHkgdGltZSBpbiBUQyBtZXNz YWdlKS4gRXhwaXJ5IHRpbWVzIGluIFR1cGxlcyBhcmUgc2V0IGZyb20gdmFsaWRpdHkgdGltZXMg aW4gbWVzc2FnZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Vc2luZyBhIGxvY2FsIHBhcmFtZXRlciB0byBzZXQgYSBo b2xkIHRpbWUgZm9yIHJlY2VpdmVkIGluZm9ybWF0aW9uIGlzIGJyb2tlbi4gWW914oCZbGwgc2Vl IHRoYXQgaWYgdGhlIHBhcmFtZXRlciB2YWx1ZXMgYXJlIGRpZmZlcmVudC4gKFRyeSBsb25nIHZh bHVlcyBhdCBub2RlDQogQSwgc2hvcnQgdmFsdWVzIGF0IG5vZGUgQiwgYW5kIHdhdGNoIGlmIHlv dSB1c2UgQuKAmXMgcGFyYW1ldGVyIHRoYW4gdGhlIGluZm9ybWF0aW9uIHdpbGwgZXhwaXJlIGJl Zm9yZSBiZWluZyByZWZyZXNoZWQuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBhIG11c3QgY2hhbmdlIGRl dGFpbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwv bzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0Ui PkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4N CkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExhYm9yYXRvcmllczxicj4NCjwvc3Bh bj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdE N0QiPjogJm5ic3A7JiM0Mzs0NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8 L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5k ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxt c2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENN MiA4SE4uPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4g c3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl IExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3 NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5 MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1 cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB5aS5qaWF6aUBnbWFpbC5jb20gW21haWx0bzp5aS5q aWF6aUBnbWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkppYXppIFlJPGJyPg0KPGI+U2Vu dDo8L2I+IDEyIEp1bHkgMjAxNiAxNDo1NTxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlz dG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+IG1hbmV0QGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbbWFuZXRdIFJldmlld2luZyBkcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1tdWx0 aXBhdGgtMTA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFjayAxLjBwdDtw YWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl bnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8 ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlzIG1lc3NhZ2Ug b3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4g ZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbnNp ZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVu IGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+PC9pPjxzdHJv bmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bh bj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3 MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLA0KIGNs aWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3Jr L3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+DQpoZXJlPC9h Pi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIi Pjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMs IHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5j b20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRo JTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48L3NwYW4+PC9l bT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBDaHJpcywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gT24gdGhlIGlzc3VlIHJlbGF0 ZWQgdG8gc2VjdGlvbiA4LjIgZmlyc3Q6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBKdWwgMTIsIDIwMTYgYXQgMTE6NTYgQU0sIERlYXJsb3ZlLCBDaHJpc3Rv cGhlciAoVUspICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkkgaGF2ZW7igJl0IGdvdCB0byB0aGUgZW5kIHlldCwgYnV0IHRoZXJlIGFyZSBzb21lIHBv aW50cyB0byBtYWtlIGFzIGZhciBhcyBJIGhhdmUgZ290LCBhbmQgaW4gb3JkZXIgbm90IHRvIHdh aXQgdW50aWwgZmluaXNoZWQuIEluIHBhcnRpY3VsYXIgSSBoYXZlIGEgc2lnbmlmaWNhbnQgaXNz dWUgaW4gU2VjdGlvbg0KIDguMi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZsdDtzbmlwJmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZWN0aW9uIDguMiBFdmVyeXdo ZXJlIGluIE9MU1J2MiAoYW5kIE5IRFApIHdlIGhhdmUgYmVlbiByZWFsbHkgY2FyZWZ1bCB0byBh bGxvdyByb3V0ZXJzIHRvIGluZGVwZW5kZW50bHkgcGljayBwYXJhbWV0ZXJzIC0gaXTigJlzIHdo eSBtZXNzYWdlcyBoYXZlIHZhbGlkaXR5IHRpbWVzLiBUaGlzIGJyZWFrcyB0aGF0LA0KIGJ5IHVz aW5nIGEgbG9jYWwgU1ImIzQzO0hPTERfVElNRSBmb3IgdGhlIHZhbGlkaXR5IHRpbWUgb2YgcmVt b3RlIGluZm9ybWF0aW9uIChTUl9hZGRyKS4gVGhpcyBpcyBub3QgYWNjZXB0YWJsZS4gVGhpcyBu ZWVkcyB0byBiZSBlaXRoZXIgdGhlIHZhbGlkaXR5IHRpbWUgb2YgdGhlIEhFTExPIG9yIFRDIG1l c3NhZ2Ugb3Igc29tZSBvdGhlciBtZWNoYW5pc20uIChJIGhhdmUgbm90IHlldCBjaGVja2VkIGlm IHRoZXJlIGFyZSBhbnkgb3RoZXIgc3VjaCBjYXNlcy4pPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWN0 dWFsbHksIHRoZSBTUl9IT0xEX1RJTUUgZGVwZW5kcyBvbiB0aGUgVENfSU5URVJWQUwsIHdoaWNo IGlzIG5vdCBsb2NhbCBhbmQgc2ltaWxhciB0byBvdGhlciBmb29fSE9MRF9USU1FcyBpbiBOSERQ L09MU1J2Mj8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YmVzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5KaWF6aTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzAwN0U3RSI+LS0NCjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIg RGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMg QXBwbGllZCBJbnRlbGxpZ2VuY2UgTGFib3JhdG9yaWVzPGJyPg0KPC9zcGFuPjwvYj48Yj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0 JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUg MjQyMTk0PC9hPg0KICZuYnNwO3wgJm5ic3A7PGI+RTogPC9iPjxhIGhyZWY9Im1haWx0bzpjaHJp cy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3Zl QGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojM0E4QjkyIj5CQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBU ZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48 YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThCOTIiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bh bj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJ bnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxl cyBObzogMDEzMzc0NTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3RlcmVkIE9mZmljZTog U3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHA+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNo bWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZDxicj4N CnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0 aGUgc2VuZGVyLjxicj4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkg cHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+DQpkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBh bnkgb3RoZXIgcGVyc29uLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5l dCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0 QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21hbmV0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EA65DGLKXM0002VGREEN_-- From nobody Tue Jul 12 13:34:25 2016 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 B399912D67A for ; Tue, 12 Jul 2016 13:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcyLvJ9S3I59 for ; Tue, 12 Jul 2016 13:34:22 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C6812D65E for ; Tue, 12 Jul 2016 13:34:21 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id h129so23249207lfh.1 for ; Tue, 12 Jul 2016 13:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ljpQHpQ/NDZIRyC8tsWsxM4FjqN+YVg02ShpfZ1Mj3k=; b=cprjUlZfGopscOiV+8D9zSJrO07PMb+6XninugACB0K1paHSqEe3bwUWuDqphVU23F cdJZ71v+VFLCYG/JoIdTvrfoZcwTosobnpM0YKBnJwo8QMHfW5OY5I+CUDppIss3Ugiz jQDvGD1cL16qyRTogSRWm/XsaoEByYsSYOpDch0lFdCkFfOh4fVh6T/9Mljv1Hp2Rw+n 9B+XchcoNlkz8ol/iQEnSuEzOozHw2JorNj1q2Nq6CYoW3H/XQVF5PDQoI1IuRte7bxx 3l9kgJe1Nux4noKCnQfO1qSLAnDs7+CIRXj7bo5epvGQMl1R+V+5V9jypIRCMXhRSmSo h/Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ljpQHpQ/NDZIRyC8tsWsxM4FjqN+YVg02ShpfZ1Mj3k=; b=haM0MRPkwS6CAMR0U7/D4gpEVpZCXTIgA1ZmxNGn9wGnazzL8t/8ScqbjoDW5n9mCR BejhM/RgOG74RkwFypALxZ79SzDfQd8s/NN9vRtSBIokcKRWrURHDf2MV6ajfc7kZi7S jKD4J7WYFvzEu9XLw61IXBEU9A4ddM/gXWCc85HNtxmYsb/U8nrWGfiEIIgOD3Sdurbx InXpAePXBWdVMx9xwdk1zEvjeTnskzdifCy0nz+5l+7ynyEHYdRH0xBpLtRid6MJ9/xN HfbrNTlIIH3h6Q05BaJlwTP1CxW0gQsQwWfoICd/GtmDiWUlB5lwp2wgOuiDsWkokWqC m2+Q== X-Gm-Message-State: ALyK8tKq1GlafIkEaSpl+Tzu9Z/oxDAvgBqxUlWSWnkP7sBW5RQO9i6qvcvh4saFX+35QJ1jOlSCoQ1wqMtSFQ== X-Received: by 10.25.210.20 with SMTP id j20mr2302039lfg.139.1468355659573; Tue, 12 Jul 2016 13:34:19 -0700 (PDT) MIME-Version: 1.0 Sender: yi.jiazi@gmail.com Received: by 10.114.2.231 with HTTP; Tue, 12 Jul 2016 13:34:18 -0700 (PDT) In-Reply-To: References: From: Jiazi YI Date: Tue, 12 Jul 2016 22:34:18 +0200 X-Google-Sender-Auth: x0qdtyuKEKS8_mOeH18ztfz4vZU Message-ID: To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a114003c67e35b005377631b3 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 20:34:25 -0000 --001a114003c67e35b005377631b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK. Generally speaking, because the SR-OLSRv2 Router Set only servers for identifying the source-route enabled routers (which won't change frequently), the hold time of tuples in the set only need to be "reasonably long enough". To make it's more consistent with the OLSRv2 style, we will make the SR_time depend on the "validity time" from the TC message received (for example, current time + 10*validity time). Is that OK? best Jiazi On Tue, Jul 12, 2016 at 6:01 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > No, that=E2=80=99s missing the point. > > > > The pattern is parameter (e.g. T_HOLD_TIME) sets field in message > (validity time in TC message). Expiry times in Tuples are set from validi= ty > times in messages. > > > > Using a local parameter to set a hold time for received information is > broken. You=E2=80=99ll see that if the parameter values are different. (T= ry long > values at node A, short values at node B, and watch if you use B=E2=80=99= s > parameter than the information will expire before being refreshed.) > > > > This is a must change detail. > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > *From:* yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] *On Behalf Of *Jia= zi > YI > *Sent:* 12 July 2016 14:55 > *To:* Dearlove, Christopher (UK) > *Cc:* manet@ietf.org > *Subject:* Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 > > > > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > * Consider carefully whether you should click on any links, open any > attachments or reply. For information regarding **Red Flags** that you > can look out for in emails you receive, click here > .* > * If you feel the email is suspicious, please follow this process > .* > > Hi Chris, > > > > Thanks for your comments. On the issue related to section 8.2 first: > > > > On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > I haven=E2=80=99t got to the end yet, but there are some points to make a= s far as > I have got, and in order not to wait until finished. In particular I have= a > significant issue in Section 8.2. > > > > > > > > Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really careful t= o > allow routers to independently pick parameters - it=E2=80=99s why message= s have > validity times. This breaks that, by using a local SR+HOLD_TIME for the > validity time of remote information (SR_addr). This is not acceptable. Th= is > needs to be either the validity time of the HELLO or TC message or some > other mechanism. (I have not yet checked if there are any other such case= s.) > > > > Actually, the SR_HOLD_TIME depends on the TC_INTERVAL, which is not local > and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2? > > > > best > > > > Jiazi > > > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence Laboratories * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > ******************************************************************** > 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 > > > --001a114003c67e35b005377631b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK. Generally speaking, because the SR-OLSRv2 Router Set o= nly servers for identifying the source-route enabled routers (which won'= ;t change frequently), the hold time of tuples in the set only need to be &= quot;reasonably long enough".=C2=A0

To make it'= s more consistent with the OLSRv2 style, we will make the=C2=A0SR_time=C2=A0depend on the &quo= t;validity time" from the TC message received (for example, current ti= me + 10*validity time). Is that OK?

best
=

Jiazi

On Tue, Jul 12, 2016 at 6:01 PM, Dearlove, Christopher = (UK) <chris.dearlove@baesystems.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

No, that=E2=80=99s missin= g the point.

=C2=A0

The pattern is parameter = (e.g. T_HOLD_TIME) sets field in message (validity time in TC message). Exp= iry times in Tuples are set from validity times in messages.<= /span>

=C2=A0

Using a local parameter t= o set a hold time for received information is broken. You=E2=80=99ll see th= at if the parameter values are different. (Try long values at node A, short values at node B, and watch if you use B=E2=80=99s parameter than= the information will expire before being refreshed.)<= /p>

=C2=A0

This is a must change det= ail.

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chri= s.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 12 July 2016 14:55
To: Dearlove, Christopher (UK)
Cc: manet@ietf.o= rg
Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10<= u>

=C2=A0

=C2=A0

*** WARNING ***<= /b>

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.=

Hi Chris,=C2=A0

=C2=A0

Thanks for your comments. On the issue related to se= ction 8.2 first:

=C2=A0

On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christop= her (UK) <chris.dearlove@baesystems.com> wrote:

I haven=E2=80=99t got to the end yet, but there are = some points to make as far as I have got, and in order not to wait until fi= nished. In particular I have a significant issue in Section 8.2.

=C2=A0

<snip>=C2=A0

=C2=A0

Section 8.2 Everywhere in OLSRv2 (and NHDP) we have = been really careful to allow routers to independently pick parameters - it= =E2=80=99s why messages have validity times. This breaks that, by using a local SR+HOLD_TIME for the validity time of remote information = (SR_addr). This is not acceptable. This needs to be either the validity tim= e of the HELLO or TC message or some other mechanism. (I have not yet check= ed if there are any other such cases.)

=C2=A0

Actually, the SR_HOLD_TIME depends on the TC_INTERVA= L, which is not local and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?= =C2=A0

=C2=A0

best

=C2=A0

Jiazi

=C2=A0

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
_____________________________________________________= _____________________

T: =C2= =A0+44 (0)12= 45 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

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


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

=C2=A0


--001a114003c67e35b005377631b3-- From nobody Tue Jul 12 15:23:29 2016 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 E92E412D9B1 for ; Tue, 12 Jul 2016 15:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lezQDaLed3jE for ; Tue, 12 Jul 2016 15:23:25 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE90812DA68 for ; Tue, 12 Jul 2016 15:23:21 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id i5so43438730wmg.0 for ; Tue, 12 Jul 2016 15:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=8z8cMU9RNVbMGuN7w2nNsbaozfdfjuu9dt5179FXCS8=; b=clo3RQ2NoFjEIb4howCD18G3Ye8T5YQ8c301Ek9F2J1LFBNjyPWclIP8guQRgcebAf BA/+ihh4dprU0OXnXxVFif3cRbAg8ilnRJMh0NkGZ1Kdv7vxOYKCi37o81R4/feYpfNp bikDBfgoV2dPTwgoE8Wm103dU7DFWfwegVTRJC6C4i1l5EtfrQLSJ8g0LlNsYx33uoZp xJRTPs0YGEXGc740uAVQNjKNVX7sDAxupwqpGVDPhBL5LOXj6Zx3BhjggXFyC5VbBy/3 28Cosp9R1mrD0n+9ce4Ln/dqCDtQSQn1Ckz8NNQNg4vG+N8KCNy8aDYRaepK5QpIPyJN 711g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=8z8cMU9RNVbMGuN7w2nNsbaozfdfjuu9dt5179FXCS8=; b=nJHWAPXzMShTZe4zSgYna06UXc+xFDsSXgZLlAxTUG+k9VVsHD9ILF0rlnURowYSEF PCHvA5XUE70C8QvY/ipBpi422qbjiQ93/K3BdX7eAoyyI5EPVHwSqZ5dvI7D+CnperkP AHPO9TzqPTGDsOixc5NmmzYVAdaYdyiDSgBDQpK6MLkMhhNcbfw+5zlwCSfkn1wkP3Xe /5XUjNFXbtjFZjbIsRltpd5ddhPkLnn/RqQhU2CunCY04ir7WdcrhhFngu7nQIK3Qkwn EHmj2AEO1kIaRAjLvHMlsEysP/d18hSmgI0Fb+ch4vfTp+PdNj4DLXBj2pdsd3ESwwwb ariA== X-Gm-Message-State: ALyK8tKC58nHIbTvtltsdZfKijFnavWDUTR6MYkTkPUfuhE1KLKEn4GFaAf7vWXN/iMg0g== X-Received: by 10.28.50.199 with SMTP id y190mr18381504wmy.61.1468362200308; Tue, 12 Jul 2016 15:23:20 -0700 (PDT) Received: from [10.5.53.198] (82-132-244-6.dab.02.net. [82.132.244.6]) by smtp.gmail.com with ESMTPSA id d62sm3976088wmd.7.2016.07.12.15.23.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jul 2016 15:23:19 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-11A60DFC-D9C2-48B6-A396-487E924751A3 Content-Transfer-Encoding: 7bit Message-Id: <5AEA8058-0936-4EBF-A4C8-CA274EAC8045@gmail.com> X-Mailer: iPhone Mail (13F69) From: Christopher Dearlove Date: Tue, 12 Jul 2016 23:23:15 +0100 To: Jiazi YI Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 22:23:28 -0000 --Apple-Mail-11A60DFC-D9C2-48B6-A396-487E924751A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable No, I'm not happy with that, I don't like the arbitrary 10. It fails the car= eful design principles we have for OLSRv2, because the receiver is making as= sumptions about the transmitter that may not be appropriate - because it doe= sn't know. This needs more thought. I can think of some options, among them giving this= TLV a value field with a validity time 5497 style. But maybe someone has a b= etter idea. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 12 Jul 2016, at 21:34, Jiazi YI wrote: >=20 > OK. Generally speaking, because the SR-OLSRv2 Router Set only servers for i= dentifying the source-route enabled routers (which won't change frequently),= the hold time of tuples in the set only need to be "reasonably long enough"= .=20 >=20 > To make it's more consistent with the OLSRv2 style, we will make the SR_ti= me depend on the "validity time" from the TC message received (for example, c= urrent time + 10*validity time). Is that OK? >=20 > best >=20 > Jiazi >=20 >> On Tue, Jul 12, 2016 at 6:01 PM, Dearlove, Christopher (UK) wrote: >> No, that=E2=80=99s missing the point. >>=20 >> =20 >>=20 >> The pattern is parameter (e.g. T_HOLD_TIME) sets field in message (validi= ty time in TC message). Expiry times in Tuples are set from validity times i= n messages. >>=20 >> =20 >>=20 >> Using a local parameter to set a hold time for received information is br= oken. You=E2=80=99ll see that if the parameter values are different. (Try lo= ng values at node A, short values at node B, and watch if you use B=E2=80=99= s parameter than the information will expire before being refreshed.) >>=20 >> =20 >>=20 >> This is a must change detail. >>=20 >> =20 >>=20 >> -- >>=20 >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> _________________________________________________________________________= _ >>=20 >> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>=20 >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddo= w, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >>=20 >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >>=20 >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>=20 >> =20 >>=20 >> From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi Y= I >> Sent: 12 July 2016 14:55 >> To: Dearlove, Christopher (UK) >> Cc: manet@ietf.org >> Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 >>=20 >> =20 >>=20 >> =20 >>=20 >> *** WARNING *** >>=20 >> This message originates from outside our organisation, either from an ext= ernal partner or the internet. >> Consider carefully whether you should click on any links, open any attach= ments or reply. >> For information regarding Red Flags that you can look out for in emails y= ou receive, click here. >> If you feel the email is suspicious, please follow this process. >>=20 >> Hi Chris,=20 >>=20 >> =20 >>=20 >> Thanks for your comments. On the issue related to section 8.2 first: >>=20 >> =20 >>=20 >> On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christopher (UK) wrote: >>=20 >> I haven=E2=80=99t got to the end yet, but there are some points to make a= s far as I have got, and in order not to wait until finished. In particular I= have a significant issue in Section 8.2. >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really careful t= o allow routers to independently pick parameters - it=E2=80=99s why messages= have validity times. This breaks that, by using a local SR+HOLD_TIME for th= e validity time of remote information (SR_addr). This is not acceptable. Thi= s needs to be either the validity time of the HELLO or TC message or some ot= her mechanism. (I have not yet checked if there are any other such cases.) >>=20 >> =20 >>=20 >> Actually, the SR_HOLD_TIME depends on the TC_INTERVAL, which is not local= and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?=20 >>=20 >> =20 >>=20 >> best >>=20 >> =20 >>=20 >> Jiazi >>=20 >> =20 >>=20 >> =20 >>=20 >> -- >>=20 >> Christopher Dearlove >> Senior Principal Engineer >> BAE Systems Applied Intelligence Laboratories >> _________________________________________________________________________= _ >>=20 >> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>=20 >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddo= w, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >>=20 >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >>=20 >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>=20 >> =20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-11A60DFC-D9C2-48B6-A396-487E924751A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
No, I'm not happy with that, I don't l= ike the arbitrary 10. It fails the careful design principles we have for OLS= Rv2, because the receiver is making assumptions about the transmitter that m= ay not be appropriate - because it doesn't know.

Th= is needs more thought. I can think of some options, among them giving this T= LV a value field with a validity time 5497 style. But maybe someone has a be= tter idea.

--  
Christopher Dearlove

On 12 Jul 2016, at 21:= 34, Jiazi YI <ietf@jiaziyi.com>= ; wrote:

OK. Gener= ally speaking, because the SR-OLSRv2 Router Set only servers for identifying= the source-route enabled routers (which won't change frequently), the hold t= ime of tuples in the set only need to be "reasonably long enough". 
To make it's more consistent with the OLSRv2 style, we will m= ake the SR_time&= nbsp;depend on the "validity time" from the TC message received (for example= , current time + 10*validity time). Is that OK?

best

Jiazi
<= br>
On Tue, Jul 12, 2016 at 6:01 PM, Dearlove, Chr= istopher (UK) <chris.dearlove@baesystems.com> wrot= e:

No, that=E2=80=99s missing t= he point.

 =

The pattern is parameter (e= .g. T_HOLD_TIME) sets field in message (validity time in TC message). Expiry= times in Tuples are set from validity times in messages.

 =

Using a local parameter to s= et a hold time for received information is broken. You=E2=80=99ll see that i= f the parameter values are different. (Try long values at node A, short values at node B, and watch if you use B=E2=80=99s parameter than t= he information will expire before being refreshed.)

=

 =

This is a must change detai= l.

 =

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
______________________________________= ____________________________________

T:  = +44 (0)1245 242194  |  E: chris= .dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 =

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ,"sans-serif""> yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 12 July 2016 14:55
To: Dearlove, Christopher (UK)
Cc: manet@ietf.or= g
Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10

 

 

*** WARNING ***=

This message originates from outside our organis= ation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments o= r reply.
For= information regarding Red Flags= that you can look out for in emails you receive= , click here.
If y= ou feel the email is suspicious, please follow this process.

Hi Chris, 

 

Thanks for your comments. On the issue related to sec= tion 8.2 first:

 

On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:

I haven=E2=80=99t got to the end yet, but there are s= ome points to make as far as I have got, and in order not to wait until fini= shed. In particular I have a significant issue in Section 8.2.

 

<snip> 

 

Section 8.2 Everywhere in OLSRv2 (and NHDP) we have b= een really careful to allow routers to independently pick parameters - it=E2= =80=99s why messages have validity times. This breaks that, by using a local SR+HOLD_TIME for the validity time of remote information (= SR_addr). This is not acceptable. This needs to be either the validity time o= f the HELLO or TC message or some other mechanism. (I have not yet checked i= f there are any other such cases.)

 

Actually, the SR_HOLD_TIME depends on the TC_INTERVAL= , which is not local and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?&nbs= p;

 

best

 

Jiazi

 

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
_______________________________________________________= ___________________

T:  = +44 (0)1245 2= 42194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 

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


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet

 


____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-11A60DFC-D9C2-48B6-A396-487E924751A3-- From nobody Tue Jul 12 15:42:24 2016 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 2927112DAA4 for ; Tue, 12 Jul 2016 15:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiVwmoFVTmSd for ; Tue, 12 Jul 2016 15:42:19 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219CE12DA50 for ; Tue, 12 Jul 2016 15:42:19 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id f65so7264277wmi.0 for ; Tue, 12 Jul 2016 15:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=uor/12weO0mARZFZxkTkWJtWxwVp26WXUglMwPacNRI=; b=RX0AumdU5159Ek+MPpT4mVFlwlMVg6CvdZK/dj8FVUxGYZ5I9NEK4eX/nd4kRhfxAx 1lJ+fWqkj/xuBrxAWoDC8lBQ/5ssIs94IjkSoEoYBas/0q1CL1DYSppEAl2wSlMRTso7 8dnl5YLVXcqFVTKoNnMu460kCw8RqDrGvVCmeBASUbsIVBBmr+3Phe0bNsWGZvn9aicZ L0tohHbL5qmFcnhCnd8Q+T3TSdONp0kK8rkOg9N/dRm0JoQSqnmQORtGj3RStLjdxxvf Z2/TFBqhgdlT1lU1sM+z50pCZ3i/JUTRpMPzur63sfPng3eItc5+43Plh/OhQnvgozTK DTGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=uor/12weO0mARZFZxkTkWJtWxwVp26WXUglMwPacNRI=; b=A5CN1Z9uNblgtjkpVDjpw/73DjG913W7OwliUEKo5yqpQchQA+vSp6JufWhnmnELLI OD4H9uVBNX0yKUqPHoh/h3QD3u0t+7s2scsCSHpyZbYnvKwPcavOv5hNswqvH7kDrI7v gBzTRr+PJCqzgVoHaMQpWE5LtpU8eYMMQB1ArtC9tu7RNZ/O5NJYHB9gtvS+YuLt/iVt Bi8NpyOSX4qrPbvQOso1HfUl4V6vzKpOdwrq85c6QzO7RM3VPYlhp4Ep8+jciFEqn1Fs 1saGKnMDkE7h+mc+JUTSAk8dEWnG5z3SpPK91JeuOcLjiDoXAdgh0aF0gshtTa+61Arj 0npw== X-Gm-Message-State: ALyK8tJhWSRKk9jsop9u8Wpm1F5gzbdag7Ctq68ZPyf7lofdvtXwxBueYIPVtzK3dP0f0Q== X-Received: by 10.28.234.16 with SMTP id i16mr15565618wmh.76.1468363337572; Tue, 12 Jul 2016 15:42:17 -0700 (PDT) Received: from [10.5.53.198] (82-132-244-6.dab.02.net. [82.132.244.6]) by smtp.gmail.com with ESMTPSA id b130sm20021406wmg.3.2016.07.12.15.42.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jul 2016 15:42:16 -0700 (PDT) References: <5AEA8058-0936-4EBF-A4C8-CA274EAC8045@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5AEA8058-0936-4EBF-A4C8-CA274EAC8045@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-CD1E424C-0E68-49DC-9F70-33A354BB2436 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (13F69) From: Christopher Dearlove Date: Tue, 12 Jul 2016 23:42:12 +0100 To: Christopher Dearlove Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 22:42:23 -0000 --Apple-Mail-CD1E424C-0E68-49DC-9F70-33A354BB2436 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Slightly better idea (I think). Make the value field a multiplier of the val= idity time rather than a time itself. Still not totally happy, but I think b= etter. Unless someone can do better still. --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 12 Jul 2016, at 23:23, Christopher Dearlove wrote: >=20 > No, I'm not happy with that, I don't like the arbitrary 10. It fails the c= areful design principles we have for OLSRv2, because the receiver is making a= ssumptions about the transmitter that may not be appropriate - because it do= esn't know. >=20 > This needs more thought. I can think of some options, among them giving th= is TLV a value field with a validity time 5497 style. But maybe someone has a= better idea. >=20 > -- =20 > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) >=20 >> On 12 Jul 2016, at 21:34, Jiazi YI wrote: >>=20 >> OK. Generally speaking, because the SR-OLSRv2 Router Set only servers for= identifying the source-route enabled routers (which won't change frequently= ), the hold time of tuples in the set only need to be "reasonably long enoug= h".=20 >>=20 >> To make it's more consistent with the OLSRv2 style, we will make the SR_t= ime depend on the "validity time" from the TC message received (for example,= current time + 10*validity time). Is that OK? >>=20 >> best >>=20 >> Jiazi >>=20 >>> On Tue, Jul 12, 2016 at 6:01 PM, Dearlove, Christopher (UK) wrote: >>> No, that=E2=80=99s missing the point. >>>=20 >>> =20 >>>=20 >>> The pattern is parameter (e.g. T_HOLD_TIME) sets field in message (valid= ity time in TC message). Expiry times in Tuples are set from validity times i= n messages. >>>=20 >>> =20 >>>=20 >>> Using a local parameter to set a hold time for received information is b= roken. You=E2=80=99ll see that if the parameter values are different. (Try l= ong values at node A, short values at node B, and watch if you use B=E2=80=99= s parameter than the information will expire before being refreshed.) >>>=20 >>> =20 >>>=20 >>> This is a must change detail. >>>=20 >>> =20 >>>=20 >>> -- >>>=20 >>> Christopher Dearlove >>> Senior Principal Engineer >>> BAE Systems Applied Intelligence Laboratories >>> ________________________________________________________________________= __ >>>=20 >>> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>>=20 >>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Badd= ow, Chelmsford, Essex CM2 8HN. >>> www.baesystems.com/ai >>>=20 >>> BAE Systems Applied Intelligence Limited >>> Registered in England & Wales No: 01337451 >>>=20 >>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>=20 >>> =20 >>>=20 >>> From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi Y= I >>> Sent: 12 July 2016 14:55 >>> To: Dearlove, Christopher (UK) >>> Cc: manet@ietf.org >>> Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> *** WARNING *** >>>=20 >>> This message originates from outside our organisation, either from an ex= ternal partner or the internet. >>> Consider carefully whether you should click on any links, open any attac= hments or reply. >>> For information regarding Red Flags that you can look out for in emails y= ou receive, click here. >>> If you feel the email is suspicious, please follow this process. >>>=20 >>> Hi Chris,=20 >>>=20 >>> =20 >>>=20 >>> Thanks for your comments. On the issue related to section 8.2 first: >>>=20 >>> =20 >>>=20 >>> On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christopher (UK) wrote: >>>=20 >>> I haven=E2=80=99t got to the end yet, but there are some points to make a= s far as I have got, and in order not to wait until finished. In particular I= have a significant issue in Section 8.2. >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really careful t= o allow routers to independently pick parameters - it=E2=80=99s why messages= have validity times. This breaks that, by using a local SR+HOLD_TIME for th= e validity time of remote information (SR_addr). This is not acceptable. Thi= s needs to be either the validity time of the HELLO or TC message or some ot= her mechanism. (I have not yet checked if there are any other such cases.) >>>=20 >>> =20 >>>=20 >>> Actually, the SR_HOLD_TIME depends on the TC_INTERVAL, which is not loca= l and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?=20 >>>=20 >>> =20 >>>=20 >>> best >>>=20 >>> =20 >>>=20 >>> Jiazi >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> -- >>>=20 >>> Christopher Dearlove >>> Senior Principal Engineer >>> BAE Systems Applied Intelligence Laboratories >>> ________________________________________________________________________= __ >>>=20 >>> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>>=20 >>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Badd= ow, Chelmsford, Essex CM2 8HN. >>> www.baesystems.com/ai >>>=20 >>> BAE Systems Applied Intelligence Limited >>> Registered in England & Wales No: 01337451 >>>=20 >>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>=20 >>> =20 >>>=20 >>> ******************************************************************** >>> 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. >>> ******************************************************************** >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=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 --Apple-Mail-CD1E424C-0E68-49DC-9F70-33A354BB2436 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Slightly better idea (I think). Make t= he value field a multiplier of the validity time rather than a time itself. S= till not totally happy, but I think better.

Unless someone can do better st= ill.

-- 
Christopher Dearlove

On 12 Jul 2016, at 23:23, Christopher D= earlove <christopher.de= arlove@gmail.com> wrote:

= No, I'm not happy with that, I don't like the arbitrary 10. It fails the c= areful design principles we have for OLSRv2, because the receiver is making a= ssumptions about the transmitter that may not be appropriate - because it do= esn't know.

This needs more thought. I can think of= some options, among them giving this TLV a value field with a validity time= 5497 style. But maybe someone has a better idea.

--  
= Christopher Dearlove

On 12 Jul 2016, at 21:34, Jiazi YI <ietf@jiaziyi.com> wrote:

OK. Generally speaking, because the SR-OL= SRv2 Router Set only servers for identifying the source-route enabled router= s (which won't change frequently), the hold time of tuples in the set only n= eed to be "reasonably long enough". 

To make it's mo= re consistent with the OLSRv2 style, we will make the SR_time depend on the "validity t= ime" from the TC message received (for example, current time + 10*validity t= ime). Is that OK?

best

Jiazi

= On Tue, Jul 12, 2016 at 6:01 PM, Dearlove, Christopher (UK) <chr= is.dearlove@baesystems.com> wrote:

No, that=E2=80=99s missing t= he point.

 =

The pattern is parameter (e= .g. T_HOLD_TIME) sets field in message (validity time in TC message). Expiry= times in Tuples are set from validity times in messages.

 =

Using a local parameter to s= et a hold time for received information is broken. You=E2=80=99ll see that i= f the parameter values are different. (Try long values at node A, short values at node B, and watch if you use B=E2=80=99s parameter than t= he information will expire before being refreshed.)

=

 =

This is a must change detai= l.

 =

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
______________________________________= ____________________________________

T:  = +44 (0)1245 242194  |  E: chris= .dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 =

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ,"sans-serif""> yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 12 July 2016 14:55
To: Dearlove, Christopher (UK)
Cc: manet@ietf.or= g
Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10

 

 

*** WARNING ***=

This message originates from outside our organis= ation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments o= r reply.
For= information regarding Red Flags= that you can look out for in emails you receive= , click here.
If y= ou feel the email is suspicious, please follow this process.

Hi Chris, 

 

Thanks for your comments. On the issue related to sec= tion 8.2 first:

 

On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:

I haven=E2=80=99t got to the end yet, but there are s= ome points to make as far as I have got, and in order not to wait until fini= shed. In particular I have a significant issue in Section 8.2.

 

<snip> 

 

Section 8.2 Everywhere in OLSRv2 (and NHDP) we have b= een really careful to allow routers to independently pick parameters - it=E2= =80=99s why messages have validity times. This breaks that, by using a local SR+HOLD_TIME for the validity time of remote information (= SR_addr). This is not acceptable. This needs to be either the validity time o= f the HELLO or TC message or some other mechanism. (I have not yet checked i= f there are any other such cases.)

 

Actually, the SR_HOLD_TIME depends on the TC_INTERVAL= , which is not local and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?&nbs= p;

 

best

 

Jiazi

 

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
_______________________________________________________= ___________________

T:  = +44 (0)1245 2= 42194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 

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


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet

 


____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
___________________________________________= ____
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet=
= --Apple-Mail-CD1E424C-0E68-49DC-9F70-33A354BB2436-- From nobody Wed Jul 13 01:03:36 2016 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 13A3912B02D for ; Wed, 13 Jul 2016 01:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpgAgewcJhj6 for ; Wed, 13 Jul 2016 01:03:31 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B3F127058 for ; Wed, 13 Jul 2016 01:03:30 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id q132so32294825lfe.3 for ; Wed, 13 Jul 2016 01:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=biv0NSr0BSaQIVRLTbo7joOSTGovvp6nPWl30OAQrFs=; b=mS7/uf+joxwnLPcLTM95xdGVeiUM3rqWi4Mmalf/jyhsHjFdJAPrGExFRyWxaMD7ej 9ciA6249X+EMa4In9fsarL3qiMNbS/fzig1Ai8MhT8lckgrXLYLCVWmT3cv3nCOlsFkZ DoTcKpJxRxadPv3AIZVrsJdPDlc9E5MElolvINOVDUSRl1oCIbSEo7RXAmXY27VtKV1a GW+ZbFI/bG8vnnvTe9twjLouNe6SqS6tvQrg23E8gQzr/gVR6vAKMpjds4xeeF/H6MEP XX/SSG80xSA4QDYSdfZhcImYsE7oISY/3LIsnYyspGFtJO4DEFtIBWDY89HUA1JBrolB NfMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=biv0NSr0BSaQIVRLTbo7joOSTGovvp6nPWl30OAQrFs=; b=R/smp0m1rKk0/IVkoCatOiumqv1iXBOKFHo6yZ2+O0OIQP+lB3ZjLdXfCre+oGVD5v xzqBXjCDSF155JZX6kCWKX5XwrcUjwaM+NLFbsQz+VQt+d8T4wb8C26qhBfEB0skTZPW jGPc35CMYebTYmqZ8v2XwmimZguB/5lXrDOo8pCXErpf8rSKNatLov8l4r2ujRcsHr0Q o7krWqbUOWxe6HGH3DNpiievDg9lk/mG+/vMf2E+OrVejClVdcHjt7OcR/KXxvuaiDmu K/pa7lFmXqV36g6P5neOeGmBwve8NIT5XcjPvM41aV+IMWLmrDfgqnkuHqyYwQuQXJUa /6ww== X-Gm-Message-State: ALyK8tItH7sve4xNPTWRWWYPEv5nB2p/CS87Sj2YeTYQzSTlG086f5FtZAJjrH0INEpsQb5DilwDvy7bEEeB9Q== X-Received: by 10.25.15.84 with SMTP id e81mr3610470lfi.3.1468397008809; Wed, 13 Jul 2016 01:03:28 -0700 (PDT) MIME-Version: 1.0 Sender: yi.jiazi@gmail.com Received: by 10.114.2.231 with HTTP; Wed, 13 Jul 2016 01:03:27 -0700 (PDT) In-Reply-To: References: <5AEA8058-0936-4EBF-A4C8-CA274EAC8045@gmail.com> From: Jiazi YI Date: Wed, 13 Jul 2016 10:03:27 +0200 X-Google-Sender-Auth: 5KnyyrLh5ebQbJ1IlxnYlHW5T3s Message-ID: To: Christopher Dearlove Content-Type: multipart/alternative; boundary=001a113f20261973e205377fd23c Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 08:03:34 -0000 --001a113f20261973e205377fd23c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I prefer having a 1-octet multiplier value field for the SOURCE_ROUTE TLV. Jiazi On Wed, Jul 13, 2016 at 12:42 AM, Christopher Dearlove < christopher.dearlove@gmail.com> wrote: > Slightly better idea (I think). Make the value field a multiplier of the > validity time rather than a time itself. Still not totally happy, but I > think better. > > Unless someone can do better still. > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 12 Jul 2016, at 23:23, Christopher Dearlove < > christopher.dearlove@gmail.com> wrote: > > No, I'm not happy with that, I don't like the arbitrary 10. It fails the > careful design principles we have for OLSRv2, because the receiver is > making assumptions about the transmitter that may not be appropriate - > because it doesn't know. > > This needs more thought. I can think of some options, among them giving > this TLV a value field with a validity time 5497 style. But maybe someone > has a better idea. > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > On 12 Jul 2016, at 21:34, Jiazi YI wrote: > > OK. Generally speaking, because the SR-OLSRv2 Router Set only servers for > identifying the source-route enabled routers (which won't change > frequently), the hold time of tuples in the set only need to be "reasonab= ly > long enough". > > To make it's more consistent with the OLSRv2 style, we will make the > SR_time depend on the "validity time" from the TC message received (for > example, current time + 10*validity time). Is that OK? > > best > > Jiazi > > On Tue, Jul 12, 2016 at 6:01 PM, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > >> No, that=E2=80=99s missing the point. >> >> >> >> The pattern is parameter (e.g. T_HOLD_TIME) sets field in message >> (validity time in TC message). Expiry times in Tuples are set from valid= ity >> times in messages. >> >> >> >> Using a local parameter to set a hold time for received information is >> broken. You=E2=80=99ll see that if the parameter values are different. (= Try long >> values at node A, short values at node B, and watch if you use B=E2=80= =99s >> parameter than the information will expire before being refreshed.) >> >> >> >> This is a must change detail. >> >> >> >> *-- * >> >> >> >> >> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied >> Intelligence Laboratories * >> *_______________________________________________________________________= ___ >> * >> *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com >> >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great >> Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >> >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >> >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >> >> >> >> *From:* yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] *On Behalf Of *Ji= azi >> YI >> *Sent:* 12 July 2016 14:55 >> *To:* Dearlove, Christopher (UK) >> *Cc:* manet@ietf.org >> *Subject:* Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 >> >> >> >> >> >> **** WARNING **** >> >> *This message originates from outside our organisation, either from an >> external partner or the internet.* >> >> * Consider carefully whether you should click on any links, open any >> attachments or reply. For information regarding **Red Flags** that you >> can look out for in emails you receive, click here >> .* >> * If you feel the email is suspicious, please follow this process >> .* >> >> Hi Chris, >> >> >> >> Thanks for your comments. On the issue related to section 8.2 first: >> >> >> >> On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com> wrote: >> >> I haven=E2=80=99t got to the end yet, but there are some points to make = as far as >> I have got, and in order not to wait until finished. In particular I hav= e a >> significant issue in Section 8.2. >> >> >> >> >> >> >> >> Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really careful >> to allow routers to independently pick parameters - it=E2=80=99s why mes= sages have >> validity times. This breaks that, by using a local SR+HOLD_TIME for the >> validity time of remote information (SR_addr). This is not acceptable. T= his >> needs to be either the validity time of the HELLO or TC message or some >> other mechanism. (I have not yet checked if there are any other such cas= es.) >> >> >> >> Actually, the SR_HOLD_TIME depends on the TC_INTERVAL, which is not loca= l >> and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2? >> >> >> >> best >> >> >> >> Jiazi >> >> >> >> >> >> *-- * >> >> >> >> >> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied >> Intelligence Laboratories * >> *_______________________________________________________________________= ___ >> * >> *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com >> >> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great >> Baddow, Chelmsford, Essex CM2 8HN. >> www.baesystems.com/ai >> >> BAE Systems Applied Intelligence Limited >> Registered in England & Wales No: 01337451 >> >> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >> >> >> >> ******************************************************************** >> 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 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a113f20261973e205377fd23c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I prefer having a 1-octet multiplier value field for the S= OURCE_ROUTE TLV.=C2=A0

Jiazi


On Wed, Jul 13= , 2016 at 12:42 AM, Christopher Dearlove <christopher.dearlov= e@gmail.com> wrote:
Slightly better idea (I think). Make the value field a mult= iplier of the validity time rather than a time itself. Still not totally ha= ppy, but I think better.

Unless someone can do bet= ter still.

--=C2=A0
Christopher Dearlove
<= div>chr= istopher.dearlove@gmail.com (iPhone)

On 12 Jul 2016, at 2= 3:23, Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
No, I'm not happy with that, I don't like the arbitrary 10. It= fails the careful design principles we have for OLSRv2, because the receiv= er is making assumptions about the transmitter that may not be appropriate = - because it doesn't know.

This needs more tho= ught. I can think of some options, among them giving this TLV a value field= with a validity time 5497 style. But maybe someone has a better idea.
<= br>
-- =C2=A0
Christopher Dearlove

On 12 Jul 2016, at 21:34, Jiazi YI <ietf@jiaziyi.com> wrote:

OK. Generally speaking, because th= e SR-OLSRv2 Router Set only servers for identifying the source-route enable= d routers (which won't change frequently), the hold time of tuples in t= he set only need to be "reasonably long enough".=C2=A0

To make it's more consistent with the OLSRv2 style, we will ma= ke the=C2=A0SR_time= =C2=A0depend on the "validity time" from the TC message received = (for example, current time + 10*validity time). Is that OK?
<= br>
best

Jiazi

On Tue, Jul 12, 2016 at 6:01 PM= , Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

No, that=E2=80=99s missin= g the point.

=C2=A0

The pattern is parameter = (e.g. T_HOLD_TIME) sets field in message (validity time in TC message). Exp= iry times in Tuples are set from validity times in messages.<= /span>

=C2=A0

Using a local parameter t= o set a hold time for received information is broken. You=E2=80=99ll see th= at if the parameter values are different. (Try long values at node A, short values at node B, and watch if you use B=E2=80=99s parameter than= the information will expire before being refreshed.)<= /p>

=C2=A0

This is a must change det= ail.

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: =C2= =A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chri= s.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 12 July 2016 14:55
To: Dearlove, Christopher (UK)
Cc: manet@ietf.o= rg
Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10<= u>

=C2=A0

=C2=A0

*** WARNING ***<= /b>

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.=

Hi Chris,=C2=A0

=C2=A0

Thanks for your comments. On the issue related to se= ction 8.2 first:

=C2=A0

On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christop= her (UK) <chris.dearlove@baesystems.com> wrote:

I haven=E2=80=99t got to the end yet, but there are = some points to make as far as I have got, and in order not to wait until fi= nished. In particular I have a significant issue in Section 8.2.

=C2=A0

<snip>=C2=A0

=C2=A0

Section 8.2 Everywhere in OLSRv2 (and NHDP) we have = been really careful to allow routers to independently pick parameters - it= =E2=80=99s why messages have validity times. This breaks that, by using a local SR+HOLD_TIME for the validity time of remote information = (SR_addr). This is not acceptable. This needs to be either the validity tim= e of the HELLO or TC message or some other mechanism. (I have not yet check= ed if there are any other such cases.)

=C2=A0

Actually, the SR_HOLD_TIME depends on the TC_INTERVA= L, which is not local and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?= =C2=A0

=C2=A0

best

=C2=A0

Jiazi

=C2=A0

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
_____________________________________________________= _____________________

T: =C2= =A0+44 (0)12= 45 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

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


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

=C2=A0


___________________= ____________________________
manet mailing list
<= span>manet@ietf.org=
https://www.ietf.org/mailman/listinfo/manet
<= /div>
_= ______________________________________________
manet mailin= g list
= manet@ietf.org
https://www.ietf.org/mailman/listinfo/man= et
--001a113f20261973e205377fd23c-- From nobody Wed Jul 13 01:16:52 2016 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 6F53212D0E8 for ; Wed, 13 Jul 2016 01:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sbRfVr9Voy5 for ; Wed, 13 Jul 2016 01:16:48 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B5112D0C3 for ; Wed, 13 Jul 2016 01:16:48 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id o80so56144403wme.1 for ; Wed, 13 Jul 2016 01:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=9MqyjPRtaPBMGwJsS0UMsm+9bmDX3xyZ/JZ38B0r188=; b=G2CXCN64mgTm/PqKx5LEHQgIduBl5pekvUf6btcfOqbgrlEeNXS/7z/VPkNMbzCNeU 0DBXXeKVBfnG2pDYxLx7zO/D6fGJyXyAYXfEJ1i9eqvOsoQ1fM+XT6zo64I9ToHyEkMp xHl1hnwFUF633zcEn7ssEkvLGsKXt6YDU4xkXesbS9W1P8GRWc5NGHCfNJE6SI0gDebU UlZI1NKn9nUdZySz9YPPH8YIncnHx1LDc+5glhoymmXD0G8PBFErfZ2+8llcQr7kZ40e a5loT0HsvZEyohKDzL76MV1CWQ5/g7kcpy4mTwKmL6uT9idIXlzSAPat7bhfcTixjhS1 G8FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=9MqyjPRtaPBMGwJsS0UMsm+9bmDX3xyZ/JZ38B0r188=; b=OhkgToQ4jZ1fREdo/jcvEUk20l5D//oOpEzzesRp6/cW4IOm3Ck+G6IbbcefjZ8VvR 0v1vM4vBbArZgL4VTy4sllGo+zbz6nTgzczf6fXehDrc6RAGrI2+hPz1MeXh5zyfEFn4 5LbFjco4yxEwyO/CfjgZnI/mqoiNkab7iqHEN/B7h3qHU7tKlh8IseKCpa/Tszb4d/mS MPbgEUXhWnQP3sIzBbN1NwmGO0loWheJzTe1bA+4vlscPUJpVVA3d3i1Rtfm4RpfrO6C UfWDeF1GxpSgR2bSSl8y0SdAMc8mMTgOBWiNOxjhSY7Z1+RT+4khNYgY82FGAjcRHMfH Y7UQ== X-Gm-Message-State: ALyK8tL9cPSn+p1HcpbHZrcW8T21uqKGDXAQ8NIWXMlXFkpmTxMF+BdP54EjkpZ5E2pKFg== X-Received: by 10.28.54.229 with SMTP id y98mr23074085wmh.96.1468397806929; Wed, 13 Jul 2016 01:16:46 -0700 (PDT) Received: from [10.1.138.25] (82-132-235-184.dab.02.net. [82.132.235.184]) by smtp.gmail.com with ESMTPSA id e69sm7346578wma.2.2016.07.13.01.16.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Jul 2016 01:16:46 -0700 (PDT) References: <5AEA8058-0936-4EBF-A4C8-CA274EAC8045@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-067CD76E-37C6-474A-BB71-D91953FD38D6 Content-Transfer-Encoding: 7bit Message-Id: <9B257D0C-457F-438C-AAC3-A63685EE7590@gmail.com> X-Mailer: iPhone Mail (13F69) From: Christopher Dearlove Date: Wed, 13 Jul 2016 09:16:43 +0100 To: Jiazi YI Archived-At: Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 08:16:51 -0000 --Apple-Mail-067CD76E-37C6-474A-BB71-D91953FD38D6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 13 Jul 2016, at 09:03, Jiazi YI wrote: >=20 > I prefer having a 1-octet multiplier value field for the SOURCE_ROUTE TLV.= =20 >=20 > Jiazi >=20 >=20 >> On Wed, Jul 13, 2016 at 12:42 AM, Christopher Dearlove wrote: >> Slightly better idea (I think). Make the value field a multiplier of the v= alidity time rather than a time itself. Still not totally happy, but I think= better. >>=20 >> Unless someone can do better still. >>=20 >> --=20 >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >>=20 >>> On 12 Jul 2016, at 23:23, Christopher Dearlove wrote: >>>=20 >>> No, I'm not happy with that, I don't like the arbitrary 10. It fails the= careful design principles we have for OLSRv2, because the receiver is makin= g assumptions about the transmitter that may not be appropriate - because it= doesn't know. >>>=20 >>> This needs more thought. I can think of some options, among them giving t= his TLV a value field with a validity time 5497 style. But maybe someone has= a better idea. >>>=20 >>> -- =20 >>> Christopher Dearlove >>> christopher.dearlove@gmail.com (iPhone) >>> chris@mnemosyne.demon.co.uk (home) >>>=20 >>>> On 12 Jul 2016, at 21:34, Jiazi YI wrote: >>>>=20 >>>> OK. Generally speaking, because the SR-OLSRv2 Router Set only servers f= or identifying the source-route enabled routers (which won't change frequent= ly), the hold time of tuples in the set only need to be "reasonably long eno= ugh".=20 >>>>=20 >>>> To make it's more consistent with the OLSRv2 style, we will make the SR= _time depend on the "validity time" from the TC message received (for exampl= e, current time + 10*validity time). Is that OK? >>>>=20 >>>> best >>>>=20 >>>> Jiazi >>>>=20 >>>>> On Tue, Jul 12, 2016 at 6:01 PM, Dearlove, Christopher (UK) wrote: >>>>> No, that=E2=80=99s missing the point. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The pattern is parameter (e.g. T_HOLD_TIME) sets field in message (val= idity time in TC message). Expiry times in Tuples are set from validity time= s in messages. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Using a local parameter to set a hold time for received information is= broken. You=E2=80=99ll see that if the parameter values are different. (Try= long values at node A, short values at node B, and watch if you use B=E2=80= =99s parameter than the information will expire before being refreshed.) >>>>>=20 >>>>> =20 >>>>>=20 >>>>> This is a must change detail. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> Christopher Dearlove >>>>> Senior Principal Engineer >>>>> BAE Systems Applied Intelligence Laboratories >>>>> ______________________________________________________________________= ____ >>>>>=20 >>>>> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>>>>=20 >>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Ba= ddow, Chelmsford, Essex CM2 8HN. >>>>> www.baesystems.com/ai >>>>>=20 >>>>> BAE Systems Applied Intelligence Limited >>>>> Registered in England & Wales No: 01337451 >>>>>=20 >>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiaz= i YI >>>>> Sent: 12 July 2016 14:55 >>>>> To: Dearlove, Christopher (UK) >>>>> Cc: manet@ietf.org >>>>> Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> *** WARNING *** >>>>>=20 >>>>> This message originates from outside our organisation, either from an e= xternal partner or the internet. >>>>> Consider carefully whether you should click on any links, open any att= achments or reply. >>>>> For information regarding Red Flags that you can look out for in email= s you receive, click here. >>>>> If you feel the email is suspicious, please follow this process. >>>>>=20 >>>>> Hi Chris,=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thanks for your comments. On the issue related to section 8.2 first: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christopher (UK) wrote: >>>>>=20 >>>>> I haven=E2=80=99t got to the end yet, but there are some points to mak= e as far as I have got, and in order not to wait until finished. In particul= ar I have a significant issue in Section 8.2. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really carefu= l to allow routers to independently pick parameters - it=E2=80=99s why messa= ges have validity times. This breaks that, by using a local SR+HOLD_TIME for= the validity time of remote information (SR_addr). This is not acceptable. T= his needs to be either the validity time of the HELLO or TC message or some o= ther mechanism. (I have not yet checked if there are any other such cases.) >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Actually, the SR_HOLD_TIME depends on the TC_INTERVAL, which is not lo= cal and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> best >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Jiazi >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> Christopher Dearlove >>>>> Senior Principal Engineer >>>>> BAE Systems Applied Intelligence Laboratories >>>>> ______________________________________________________________________= ____ >>>>>=20 >>>>> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>>>>=20 >>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Ba= ddow, Chelmsford, Essex CM2 8HN. >>>>> www.baesystems.com/ai >>>>>=20 >>>>> BAE Systems Applied Intelligence Limited >>>>> Registered in England & Wales No: 01337451 >>>>>=20 >>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>>>=20 >>>>> =20 >>>>>=20 >>>>> ******************************************************************** >>>>> 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. >>>>> ******************************************************************** >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail-067CD76E-37C6-474A-BB71-D91953FD38D6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


--  
Christopher Dear= love

On 1= 3 Jul 2016, at 09:03, Jiazi YI <ietf@= jiaziyi.com> wrote:

I prefer having a 1-octet multiplier value field for the SOURCE_ROU= TE TLV. 

Jiazi


On Wed, Jul 13, 2016 at 1= 2:42 AM, Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
= Slightly better idea (I think). Make the value field a multiplier of the val= idity time rather than a time itself. Still not totally happy, but I think b= etter.

=

On 12 Jul 2016, at 23:23, Christopher Dearlo= ve <c= hristopher.dearlove@gmail.com> wrote:

No, I'm not happy with that, I don't like the arbitrary 10. It fails th= e careful design principles we have for OLSRv2, because the receiver is maki= ng assumptions about the transmitter that may not be appropriate - because i= t doesn't know.

This needs more thought. I can thin= k of some options, among them giving this TLV a value field with a validity t= ime 5497 style. But maybe someone has a better idea.

--  Christopher Dearlove
<= div>chris@m= nemosyne.demon.co.uk (home)

On 12 Jul 2016, at= 21:34, Jiazi YI <i= etf@jiaziyi.com> wrote:

<= div dir=3D"ltr">OK. Generally speaking, because the SR-OLSRv2 Router Set onl= y servers for identifying the source-route enabled routers (which won't chan= ge frequently), the hold time of tuples in the set only need to be "reasonab= ly long enough". 

To make it's more consistent with t= he OLSRv2 style, we will make the SR_time depend on the "validity time" from the TC mes= sage received (for example, current time + 10*validity time). Is that OK?

best

Jiazi

On Tue, Jul 12, 2016= at 6:01 PM, Dearlove, Christopher (UK) <chris.dearlove@baesyste= ms.com> wrote:

No, that=E2=80=99s missing t= he point.

 =

The pattern is parameter (e= .g. T_HOLD_TIME) sets field in message (validity time in TC message). Expiry= times in Tuples are set from validity times in messages.

 =

Using a local parameter to s= et a hold time for received information is broken. You=E2=80=99ll see that i= f the parameter values are different. (Try long values at node A, short values at node B, and watch if you use B=E2=80=99s parameter than t= he information will expire before being refreshed.)

=

 =

This is a must change detai= l.

 =

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
______________________________________= ____________________________________

T:  = +44 (0)1245 242194  |  E: chris= .dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 =

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ,"sans-serif""> yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 12 July 2016 14:55
To: Dearlove, Christopher (UK)
Cc: manet@ietf.or= g
Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10

 

 

*** WARNING ***=

This message originates from outside our organis= ation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments o= r reply.
For= information regarding Red Flags= that you can look out for in emails you receive= , click here.
If y= ou feel the email is suspicious, please follow this process.

Hi Chris, 

 

Thanks for your comments. On the issue related to sec= tion 8.2 first:

 

On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:

I haven=E2=80=99t got to the end yet, but there are s= ome points to make as far as I have got, and in order not to wait until fini= shed. In particular I have a significant issue in Section 8.2.

 

<snip> 

 

Section 8.2 Everywhere in OLSRv2 (and NHDP) we have b= een really careful to allow routers to independently pick parameters - it=E2= =80=99s why messages have validity times. This breaks that, by using a local SR+HOLD_TIME for the validity time of remote information (= SR_addr). This is not acceptable. This needs to be either the validity time o= f the HELLO or TC message or some other mechanism. (I have not yet checked i= f there are any other such cases.)

 

Actually, the SR_HOLD_TIME depends on the TC_INTERVAL= , which is not local and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?&nbs= p;

 

best

 

Jiazi

 

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
_______________________________________________________= ___________________

T:  = +44 (0)1245 2= 42194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 

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


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet

 


____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
=
_______= ________________________________________
manet mailing list<= /span>
manet@ie= tf.org
https://www.ietf.org/mailman/listinfo/manet

= --Apple-Mail-067CD76E-37C6-474A-BB71-D91953FD38D6-- From nobody Wed Jul 13 01:42:12 2016 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 EB9EB12B013 for ; Wed, 13 Jul 2016 01:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpvkDz0vNxRl for ; Wed, 13 Jul 2016 01:42:06 -0700 (PDT) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F338412B00A for ; Wed, 13 Jul 2016 01:42:05 -0700 (PDT) Received: by mail-lf0-f47.google.com with SMTP id b199so33391287lfe.0 for ; Wed, 13 Jul 2016 01:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-transfer-encoding:subject:references:from:mime-version :in-reply-to:message-id:date:cc:to; bh=kCmBbtKfjbf6kE4+eWWz15eLjqBMVcKl1jlRGFGRkvA=; b=DY0tX6AvRh5k4hBPCen4iEB6RIZ0cXhDLqiP50Eo2YUNvP+UdhVHDJwFfuow9X1lJz Ntc8PtDy+WwRgXnFSDL8Wk013LFpLYg+JXU+QJUHeDjN9G5IJ1Ps2u67ThG7f27Z307J cvL3vLWpseuaFU2WIxgX3BP4HYGmss17fCpMd9FAWE3knZ/pDANymKep2KPDW49/lagl 2h1Kga4FtjK56cUCjWeO6JXtwjTbIEST/99T2veUHmokZsSNwGXrSMCBXGNC6OKiMWnQ oqqwtpUFgqbuszndJDzJIjjifExF5C83tXpWFC4XmgN4U023JDNgrzo8rdroTkVkwpJt f0dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:subject:references :from:mime-version:in-reply-to:message-id:date:cc:to; bh=kCmBbtKfjbf6kE4+eWWz15eLjqBMVcKl1jlRGFGRkvA=; b=jecxJ2Tt2m6emQd7gp7ofaHjJ0Q4UG1rvn7GMrpn7lfs1yxg0ULbvMxWWesG9q9+Zx xigQzGIJJi+K+Rt4jzSeltdnQB4T7DkogH35wlgVo0WqCI/l5mI1/E8zY9MfuW6I5HI+ 3vnTa8k04gcsRCW56nE0JJ8j1zS/5Qso5uJnlYavYFGr1JvqwKal9sDsXhCl5E+3j3qN lxLU6GrCRLFptQ4wD2BJjNpoPo/3HuDTJGe4DrRcZPGhykYFIVtsvn0Q2hpKzaj2Agp8 PDpvAobXQSAKeD9Ic0sqHfFlNskD8UxuqCLf2Kj65lI6StczDVNugkSNZkdKvbNckpom gCag== X-Gm-Message-State: ALyK8tKjQH6e/jqbRuN3Ok0xT76kFa4t2JYSX67XLkPq4ucAxCcl+PBMKj66bIJ+9pLteg== X-Received: by 10.25.86.209 with SMTP id k200mr4073251lfb.65.1468399248970; Wed, 13 Jul 2016 01:40:48 -0700 (PDT) Received: from [10.1.138.25] (82-132-235-184.dab.02.net. [82.132.235.184]) by smtp.gmail.com with ESMTPSA id l19sm1557111lfi.24.2016.07.13.01.40.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Jul 2016 01:40:47 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-AD99C42C-938C-4155-A499-075CBA66E45F Content-Transfer-Encoding: 7bit References: <5AEA8058-0936-4EBF-A4C8-CA274EAC8045@gmail.com> From: Christopher Dearlove Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: Date: Wed, 13 Jul 2016 09:18:12 +0100 To: Jiazi YI X-Mailer: iPhone Mail (13F69) Archived-At: Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 08:42:12 -0000 --Apple-Mail-AD99C42C-938C-4155-A499-075CBA66E45F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So do I. (Open to anyone with a better idea of course.) [I might have accidentally sent an empty message before this one. If so, apo= logies.] --=20 Christopher Dearlove > On 13 Jul 2016, at 09:03, Jiazi YI wrote: >=20 > I prefer having a 1-octet multiplier value field for the SOURCE_ROUTE TLV.= =20 >=20 > Jiazi >=20 >=20 >> On Wed, Jul 13, 2016 at 12:42 AM, Christopher Dearlove wrote: >> Slightly better idea (I think). Make the value field a multiplier of the v= alidity time rather than a time itself. Still not totally happy, but I think= better. >>=20 >> Unless someone can do better still. >>=20 >> --=20 >> Christopher Dearlove >> christopher.dearlove@gmail.com (iPhone) >> chris@mnemosyne.demon.co.uk (home) >>=20 >>> On 12 Jul 2016, at 23:23, Christopher Dearlove wrote: >>>=20 >>> No, I'm not happy with that, I don't like the arbitrary 10. It fails the= careful design principles we have for OLSRv2, because the receiver is makin= g assumptions about the transmitter that may not be appropriate - because it= doesn't know. >>>=20 >>> This needs more thought. I can think of some options, among them giving t= his TLV a value field with a validity time 5497 style. But maybe someone has= a better idea. >>>=20 >>> -- =20 >>> Christopher Dearlove >>> christopher.dearlove@gmail.com (iPhone) >>> chris@mnemosyne.demon.co.uk (home) >>>=20 >>>> On 12 Jul 2016, at 21:34, Jiazi YI wrote: >>>>=20 >>>> OK. Generally speaking, because the SR-OLSRv2 Router Set only servers f= or identifying the source-route enabled routers (which won't change frequent= ly), the hold time of tuples in the set only need to be "reasonably long eno= ugh".=20 >>>>=20 >>>> To make it's more consistent with the OLSRv2 style, we will make the SR= _time depend on the "validity time" from the TC message received (for exampl= e, current time + 10*validity time). Is that OK? >>>>=20 >>>> best >>>>=20 >>>> Jiazi >>>>=20 >>>>> On Tue, Jul 12, 2016 at 6:01 PM, Dearlove, Christopher (UK) wrote: >>>>> No, that=E2=80=99s missing the point. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The pattern is parameter (e.g. T_HOLD_TIME) sets field in message (val= idity time in TC message). Expiry times in Tuples are set from validity time= s in messages. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Using a local parameter to set a hold time for received information is= broken. You=E2=80=99ll see that if the parameter values are different. (Try= long values at node A, short values at node B, and watch if you use B=E2=80= =99s parameter than the information will expire before being refreshed.) >>>>>=20 >>>>> =20 >>>>>=20 >>>>> This is a must change detail. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> Christopher Dearlove >>>>> Senior Principal Engineer >>>>> BAE Systems Applied Intelligence Laboratories >>>>> ______________________________________________________________________= ____ >>>>>=20 >>>>> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>>>>=20 >>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Ba= ddow, Chelmsford, Essex CM2 8HN. >>>>> www.baesystems.com/ai >>>>>=20 >>>>> BAE Systems Applied Intelligence Limited >>>>> Registered in England & Wales No: 01337451 >>>>>=20 >>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiaz= i YI >>>>> Sent: 12 July 2016 14:55 >>>>> To: Dearlove, Christopher (UK) >>>>> Cc: manet@ietf.org >>>>> Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> *** WARNING *** >>>>>=20 >>>>> This message originates from outside our organisation, either from an e= xternal partner or the internet. >>>>> Consider carefully whether you should click on any links, open any att= achments or reply. >>>>> For information regarding Red Flags that you can look out for in email= s you receive, click here. >>>>> If you feel the email is suspicious, please follow this process. >>>>>=20 >>>>> Hi Chris,=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thanks for your comments. On the issue related to section 8.2 first: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christopher (UK) wrote: >>>>>=20 >>>>> I haven=E2=80=99t got to the end yet, but there are some points to mak= e as far as I have got, and in order not to wait until finished. In particul= ar I have a significant issue in Section 8.2. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Section 8.2 Everywhere in OLSRv2 (and NHDP) we have been really carefu= l to allow routers to independently pick parameters - it=E2=80=99s why messa= ges have validity times. This breaks that, by using a local SR+HOLD_TIME for= the validity time of remote information (SR_addr). This is not acceptable. T= his needs to be either the validity time of the HELLO or TC message or some o= ther mechanism. (I have not yet checked if there are any other such cases.) >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Actually, the SR_HOLD_TIME depends on the TC_INTERVAL, which is not lo= cal and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> best >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Jiazi >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> Christopher Dearlove >>>>> Senior Principal Engineer >>>>> BAE Systems Applied Intelligence Laboratories >>>>> ______________________________________________________________________= ____ >>>>>=20 >>>>> T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>>>>=20 >>>>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Ba= ddow, Chelmsford, Essex CM2 8HN. >>>>> www.baesystems.com/ai >>>>>=20 >>>>> BAE Systems Applied Intelligence Limited >>>>> Registered in England & Wales No: 01337451 >>>>>=20 >>>>> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>>>>=20 >>>>> =20 >>>>>=20 >>>>> ******************************************************************** >>>>> 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. >>>>> ******************************************************************** >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail-AD99C42C-938C-4155-A499-075CBA66E45F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
So do I. (Open to anyone with a better= idea of course.)

[I might have accidentally sent an empty message before t= his one. If so, apologies.]

-- 
Christopher Dearlove

On 13 Jul 2016, at 09:03, Jiazi YI <ietf@jiaziyi.com> wrote:

I prefer having a 1-octet multiplier value field for= the SOURCE_ROUTE TLV. 

Jiazi


On Wed, Ju= l 13, 2016 at 12:42 AM, Christopher Dearlove <christopher.dearlo= ve@gmail.com> wrote:
Slightly better idea (I think). Make the value field a multip= lier of the validity time rather than a time itself. Still not totally happy= , but I think better.

Unless someone can do better s= till.

-- 
Christopher Dearlove
christophe= r.dearlove@gmail.com (iPhone)

On 12 Jul 2016, at 23:23, Chri= stopher Dearlove <christopher.dearlove@gmail.com> wrote:

No, I'm not happy with that, I don't like the arbitrary 10. It fails th= e careful design principles we have for OLSRv2, because the receiver is maki= ng assumptions about the transmitter that may not be appropriate - because i= t doesn't know.

This needs more thought. I can thin= k of some options, among them giving this TLV a value field with a validity t= ime 5497 style. But maybe someone has a better idea.

--  Christopher Dearlove
<= div>chris@m= nemosyne.demon.co.uk (home)

On 12 Jul 2016, at= 21:34, Jiazi YI <i= etf@jiaziyi.com> wrote:

<= div dir=3D"ltr">OK. Generally speaking, because the SR-OLSRv2 Router Set onl= y servers for identifying the source-route enabled routers (which won't chan= ge frequently), the hold time of tuples in the set only need to be "reasonab= ly long enough". 

To make it's more consistent with t= he OLSRv2 style, we will make the SR_time depend on the "validity time" from the TC mes= sage received (for example, current time + 10*validity time). Is that OK?

best

Jiazi

On Tue, Jul 12, 2016= at 6:01 PM, Dearlove, Christopher (UK) <chris.dearlove@baesyste= ms.com> wrote:

No, that=E2=80=99s missing t= he point.

 =

The pattern is parameter (e= .g. T_HOLD_TIME) sets field in message (validity time in TC message). Expiry= times in Tuples are set from validity times in messages.

 =

Using a local parameter to s= et a hold time for received information is broken. You=E2=80=99ll see that i= f the parameter values are different. (Try long values at node A, short values at node B, and watch if you use B=E2=80=99s parameter than t= he information will expire before being refreshed.)

=

 =

This is a must change detai= l.

 =

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
______________________________________= ____________________________________

T:  = +44 (0)1245 242194  |  E: chris= .dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 =

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ,"sans-serif""> yi.jiazi@gmail.com [mailto:yi.jiazi@gmail.com] On Behalf Of Jiazi YI
Sent: 12 July 2016 14:55
To: Dearlove, Christopher (UK)
Cc: manet@ietf.or= g
Subject: Re: [manet] Reviewing draft-ietf-manet-olsrv2-multipath-10

 

 

*** WARNING ***=

This message originates from outside our organis= ation, either from an external partner or the internet.
Con= sider carefully whether you should click on any links, open any attachments o= r reply.
For= information regarding Red Flags= that you can look out for in emails you receive= , click here.
If y= ou feel the email is suspicious, please follow this process.

Hi Chris, 

 

Thanks for your comments. On the issue related to sec= tion 8.2 first:

 

On Tue, Jul 12, 2016 at 11:56 AM, Dearlove, Christoph= er (UK) <chris.dearlove@baesystems.com> wrote:

I haven=E2=80=99t got to the end yet, but there are s= ome points to make as far as I have got, and in order not to wait until fini= shed. In particular I have a significant issue in Section 8.2.

 

<snip> 

 

Section 8.2 Everywhere in OLSRv2 (and NHDP) we have b= een really careful to allow routers to independently pick parameters - it=E2= =80=99s why messages have validity times. This breaks that, by using a local SR+HOLD_TIME for the validity time of remote information (= SR_addr). This is not acceptable. This needs to be either the validity time o= f the HELLO or TC message or some other mechanism. (I have not yet checked i= f there are any other such cases.)

 

Actually, the SR_HOLD_TIME depends on the TC_INTERVAL= , which is not local and similar to other foo_HOLD_TIMEs in NHDP/OLSRv2?&nbs= p;

 

best

 

Jiazi

 

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
_______________________________________________________= ___________________

T:  = +44 (0)1245 2= 42194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford T= echnology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligen= ce Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP<= u>

 

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


_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet

 


____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
=
_______= ________________________________________
manet mailing list<= /span>
manet@ie= tf.org
https://www.ietf.org/mailman/listinfo/manet

= --Apple-Mail-AD99C42C-938C-4155-A499-075CBA66E45F-- From nobody Mon Jul 18 13:38:22 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 294F512B061; Mon, 18 Jul 2016 13:38:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160718203817.18128.45801.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2016 13:38:17 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-23.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 20:38:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Shawn Jury Darryl Satterwhite Rick Taylor Bo Berry Filename : draft-ietf-manet-dlep-23.txt Pages : 64 Date : 2016-07-18 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-23 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 nobody Mon Jul 18 14:43:37 2016 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 B2D0312DA1B for ; Mon, 18 Jul 2016 14:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9VP_N-YR1o9 for ; Mon, 18 Jul 2016 14:43:32 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F2012D976 for ; Mon, 18 Jul 2016 14:43:32 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id q83so2937551iod.1 for ; Mon, 18 Jul 2016 14:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=F7p+M75kVQxEk0sZywIo7BRUSKav2mK1rnwddOMHDUw=; b=YgUMmxt1zmaUZAvzkBhzv647sSplw3rKjl7kPBcNjyUHlofwHplp4ozPQsE6DM3H6W TnawP18giVjbOhx25h9jUz+LYPblL4w+mxRyps9NPfgryly6wSUdiqTL0bE8scOk8hRY 4ITuSxGrfdWq4jyy3PDup/BbvKi97pq35vF2dsTSgxHtFaeByhMIRpbLfWajb2G8gma0 zwlJPMyXRsEwrIf2p6JZiJwMIzTn2jEukiMtpD3BnqN5IPvzoodtLS4haUUF/8tH+Bgp wDIHmY1ajqJThM28XXXVmM6jrMXNHhiQbUaNwf0Az7ZoVm3/mxuIlcV+j3jGjQYjOsYP gRZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=F7p+M75kVQxEk0sZywIo7BRUSKav2mK1rnwddOMHDUw=; b=IXAy1Q8oAMRKxa5wT8a6Us4A2niDiEEPZpLAKhgXlUL/ZITYX6gnd05lkhwc/z3GG4 z9geX3oqRkqAaP2O7db5M+E333+oIyXZ81305dPTDI5WbI+f/zlAB1b6raArwWUP5+s9 oPwvdXtseIJlyJu+MZKcdR5cc+f1oyUU1S5FwOFsWZ+80WPuIy4FWY57RSQTe7itE1C9 WGBQvM17jsTIKe0mJlKsjHVu/1Sq8T3IGsLNOjnmw5OMymrtT406fmg000xHnpBoaB/6 lAMqjQjP0rz4WkJEs/OZaZKKwqNMsgYibjQmdlszM94uoZ0ETdJqHkbNdjERFbCg9bE+ WUWQ== X-Gm-Message-State: ALyK8tJpfOGApNXRRDO80d7wGuevxqI5P+9cOAQEoWUc0ZlcgDNpQfnWVsZNDjgT5xSA74PngCJx0r7pgAh2Vg== X-Received: by 10.107.12.85 with SMTP id w82mr40194033ioi.182.1468878211759; Mon, 18 Jul 2016 14:43:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.84.65 with HTTP; Mon, 18 Jul 2016 14:43:31 -0700 (PDT) In-Reply-To: <20160718203817.18128.45801.idtracker@ietfa.amsl.com> References: <20160718203817.18128.45801.idtracker@ietfa.amsl.com> From: Stan Ratliff Date: Mon, 18 Jul 2016 17:43:31 -0400 Message-ID: To: MANET IETF Content-Type: multipart/alternative; boundary=001a113f9d7c07c65f0537efdca0 Archived-At: Subject: [manet] Fwd: I-D Action: draft-ietf-manet-dlep-23.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 21:43:36 -0000 --001a113f9d7c07c65f0537efdca0 Content-Type: text/plain; charset=UTF-8 Hello Working Group, As you can see, there is a DLEP-23 that was posted tonight. This version was prompted by comments received in the AD review. Most of the changes are editorial - the biggest change of the bunch is a requirement to implement RFC5082 (The Generalized TTL Security Mechanism, or GTSM). With GTSM, DLEP now requires all UDP-based signals to be sent with TTL=1. All TCP-based DLEP Messages are sent with TTL=255. The TTL values are checked on receipt, and the packets are discarded if the TTLs don't match-up. The use of GTSM is to mandate that DLEP run over 1 physical hop only - it enforces the requirement that we run on a single Layer 2 domain. Regards, Stan ---------- Forwarded message ---------- From: Date: Mon, Jul 18, 2016 at 4:38 PM Subject: [manet] I-D Action: draft-ietf-manet-dlep-23.txt To: i-d-announce@ietf.org Cc: manet@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Shawn Jury Darryl Satterwhite Rick Taylor Bo Berry Filename : draft-ietf-manet-dlep-23.txt Pages : 64 Date : 2016-07-18 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-23 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/ _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --001a113f9d7c07c65f0537efdca0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Working Group,=C2=A0

As you can s= ee, there is a DLEP-23 that was posted tonight. This version was prompted b= y comments received in the AD review. Most of the changes are editorial - t= he biggest change of the bunch is a requirement to implement RFC5082 (The G= eneralized TTL Security Mechanism, or GTSM). With GTSM, DLEP now requires a= ll UDP-based signals to be sent with TTL=3D1. All TCP-based DLEP Messages a= re sent with TTL=3D255. The TTL values are checked on receipt, and the pack= ets are discarded if the TTLs don't match-up. The use of GTSM is to man= date that DLEP run over 1 physical hop only - it enforces the requirement t= hat we run on a single Layer 2 domain.=C2=A0

Regar= ds,
Stan


= ---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Mon, Jul 18, 2016 at 4:38 = PM
Subject: [manet] I-D Action: draft-ietf-manet-dlep-23.txt
To: i-d-announce@ietf.org
Cc: manet@ietf.org



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 of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Dynamic Link Exchange Protocol (DLEP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Stan= Ratliff
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Shawn Jury
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Darryl Satterwhite
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Rick Taylor
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Bo Berry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-manet-dlep-23.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-07-18

Abstract:
=C2=A0 =C2=A0When routing devices rely on modems to effect communications o= ver
=C2=A0 =C2=A0wireless links, they need timely and accurate knowledge of the=
=C2=A0 =C2=A0characteristics of the link (speed, state, etc.) in order to m= ake
=C2=A0 =C2=A0routing decisions.=C2=A0 In mobile or other environments where= these
=C2=A0 =C2=A0characteristics change frequently, manual configurations or th= e
=C2=A0 =C2=A0inference of state through routing or transport protocols does= not
=C2=A0 =C2=A0allow the router to make the best decisions.=C2=A0 A bidirecti= onal, event-
=C2=A0 =C2=A0driven communication channel between the router and the modem = is
=C2=A0 =C2=A0necessary.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-m= anet-dlep/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-manet-dle= p-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-manet-dlep-23


Please note that it may take a couple of minutes from the time of submissio= n
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/

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

--001a113f9d7c07c65f0537efdca0-- From nobody Tue Jul 19 05:26:10 2016 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 B90CE12D63B for ; Tue, 19 Jul 2016 05:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQG-imO8ZSWL for ; Tue, 19 Jul 2016 05:26:06 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C6512D639 for ; Tue, 19 Jul 2016 05:26:06 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 19 Jul 2016 13:25:42 +0100 From: Rick Taylor To: "ratliffstan@gmail.com" , "manet@ietf.org" Thread-Topic: [manet] Fwd: I-D Action: draft-ietf-manet-dlep-23.txt Thread-Index: AQHR4T130hpfELphQkqtXkSVh4taGKAfnhWA Date: Tue, 19 Jul 2016 12:25:41 +0000 Message-ID: <1468931141.8956.13.camel@tropicalstormsoftware.com> References: <20160718203817.18128.45801.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <8cdd7907-8d73-4d1a-9861-ea9f2bb56be0> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Fwd: I-D Action: draft-ietf-manet-dlep-23.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 12:26:09 -0000 SGVsbG8gQWxsLA0KDQpVbmZvcnR1bmF0ZWx5LCBhbiBleHRyYSBlcnJvciBzdGF0dXMgY29kZSAo MTMzKSB3YXMgYWRkZWQgZHVyaW5nDQplZGl0aW5nLCBhbmQgbm90IHJlbW92ZWQgYWdhaW4gd2hl biBpdCB3YXMgZGlzY292ZXJlZCB0byBiZQ0KdW5uZWNlc3NhcnkuIMKgSXQgd2lsbCBiZSByZW1v dmVkLCBhbmQgYSBuZXcgZHJhZnQgaXNzdWVkLiDCoEhvd2V2ZXIsIHdlDQp3b3VsZCBsaWtlIHRv IGdpdmUgeW91IGFsbCBhIGNoYW5jZSB0byByZWFkIHRoaXMgZHJhZnQgYW5kIHJhaXNlIGFueQ0K b3RoZXIgaXNzdWVzIG5vdy4NCg0KQ2hlZXJzLA0KDQpSaWNrDQoNCk9uIE1vbiwgMjAxNi0wNy0x OCBhdCAxNzo0MyAtMDQwMCwgU3RhbiBSYXRsaWZmIHdyb3RlOg0KPiBIZWxsbyBXb3JraW5nIEdy b3VwLMKgDQo+IA0KPiBBcyB5b3UgY2FuIHNlZSwgdGhlcmUgaXMgYSBETEVQLTIzIHRoYXQgd2Fz IHBvc3RlZCB0b25pZ2h0LiBUaGlzDQo+IHZlcnNpb24gd2FzIHByb21wdGVkIGJ5IGNvbW1lbnRz IHJlY2VpdmVkIGluIHRoZSBBRCByZXZpZXcuIE1vc3Qgb2YNCj4gdGhlIGNoYW5nZXMgYXJlIGVk aXRvcmlhbCAtIHRoZSBiaWdnZXN0IGNoYW5nZSBvZiB0aGUgYnVuY2ggaXMgYQ0KPiByZXF1aXJl bWVudCB0byBpbXBsZW1lbnQgUkZDNTA4MiAoVGhlIEdlbmVyYWxpemVkIFRUTCBTZWN1cml0eQ0K PiBNZWNoYW5pc20sIG9yIEdUU00pLiBXaXRoIEdUU00sIERMRVAgbm93IHJlcXVpcmVzIGFsbCBV RFAtYmFzZWQNCj4gc2lnbmFscyB0byBiZSBzZW50IHdpdGggVFRMPTEuIEFsbCBUQ1AtYmFzZWQg RExFUCBNZXNzYWdlcyBhcmUgc2VudA0KPiB3aXRoIFRUTD0yNTUuIFRoZSBUVEwgdmFsdWVzIGFy ZSBjaGVja2VkIG9uIHJlY2VpcHQsIGFuZCB0aGUgcGFja2V0cw0KPiBhcmUgZGlzY2FyZGVkIGlm IHRoZSBUVExzIGRvbid0IG1hdGNoLXVwLiBUaGUgdXNlIG9mIEdUU00gaXMgdG8NCj4gbWFuZGF0 ZSB0aGF0IERMRVAgcnVuIG92ZXIgMSBwaHlzaWNhbCBob3Agb25seSAtIGl0IGVuZm9yY2VzIHRo ZQ0KPiByZXF1aXJlbWVudCB0aGF0IHdlIHJ1biBvbiBhIHNpbmdsZSBMYXllciAyIGRvbWFpbi7C oA0KPiANCj4gUmVnYXJkcywNCj4gU3Rhbg0KPiANCj4gDQo+IC0tLS0tLS0tLS0gRm9yd2FyZGVk IG1lc3NhZ2UgLS0tLS0tLS0tLQ0KPiBGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0K PiBEYXRlOiBNb24sIEp1bCAxOCwgMjAxNiBhdCA0OjM4IFBNDQo+IFN1YmplY3Q6IFttYW5ldF0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLTIzLnR4dA0KPiBUbzogaS1kLWFubm91 bmNlQGlldGYub3JnDQo+IENjOiBtYW5ldEBpZXRmLm9yZw0KPiANCj4gDQo+IA0KPiBBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMNCj4gZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE1v YmlsZSBBZC1ob2MgTmV0d29ya3Mgb2YgdGhlIElFVEYuDQo+IA0KPiDCoCDCoCDCoCDCoCBUaXRs ZcKgIMKgIMKgIMKgIMKgIMKgOiBEeW5hbWljIExpbmsgRXhjaGFuZ2UgUHJvdG9jb2wgKERMRVAp DQo+IMKgIMKgIMKgIMKgIEF1dGhvcnPCoCDCoCDCoCDCoCDCoDogU3RhbiBSYXRsaWZmDQo+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNoYXduIEp1cnkNCj4gwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgRGFycnlsIFNhdHRlcndoaXRlDQo+IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFJpY2sgVGF5bG9yDQo+IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEJvIEJlcnJ5DQo+IMKgIMKgIMKgIMKg IEZpbGVuYW1lwqAgwqAgwqAgwqAgOiBkcmFmdC1pZXRmLW1hbmV0LWRsZXAtMjMudHh0DQo+IMKg IMKgIMKgIMKgIFBhZ2VzwqAgwqAgwqAgwqAgwqAgwqA6IDY0DQo+IMKgIMKgIMKgIMKgIERhdGXC oCDCoCDCoCDCoCDCoCDCoCA6IDIwMTYtMDctMTgNCj4gDQo+IEFic3RyYWN0Og0KPiDCoCDCoFdo ZW4gcm91dGluZyBkZXZpY2VzIHJlbHkgb24gbW9kZW1zIHRvIGVmZmVjdCBjb21tdW5pY2F0aW9u cyBvdmVyDQo+IMKgIMKgd2lyZWxlc3MgbGlua3MsIHRoZXkgbmVlZCB0aW1lbHkgYW5kIGFjY3Vy YXRlIGtub3dsZWRnZSBvZiB0aGUNCj4gwqAgwqBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIGxpbmsg KHNwZWVkLCBzdGF0ZSwgZXRjLikgaW4gb3JkZXIgdG8gbWFrZQ0KPiDCoCDCoHJvdXRpbmcgZGVj aXNpb25zLsKgIEluIG1vYmlsZSBvciBvdGhlciBlbnZpcm9ubWVudHMgd2hlcmUgdGhlc2UNCj4g wqAgwqBjaGFyYWN0ZXJpc3RpY3MgY2hhbmdlIGZyZXF1ZW50bHksIG1hbnVhbCBjb25maWd1cmF0 aW9ucyBvciB0aGUNCj4gwqAgwqBpbmZlcmVuY2Ugb2Ygc3RhdGUgdGhyb3VnaCByb3V0aW5nIG9y IHRyYW5zcG9ydCBwcm90b2NvbHMgZG9lcyBub3QNCj4gwqAgwqBhbGxvdyB0aGUgcm91dGVyIHRv IG1ha2UgdGhlIGJlc3QgZGVjaXNpb25zLsKgIEEgYmlkaXJlY3Rpb25hbCwNCj4gZXZlbnQtDQo+ IMKgIMKgZHJpdmVuIGNvbW11bmljYXRpb24gY2hhbm5lbCBiZXR3ZWVuIHRoZSByb3V0ZXIgYW5k IHRoZSBtb2RlbSBpcw0KPiDCoCDCoG5lY2Vzc2FyeS4NCj4gDQo+IA0KPiBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLw0KPiANCj4gVGhlcmUncyBh bHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LWRsZXAtMjMNCj4gDQo+IEEgZGlmZiBmcm9tIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbWFuZXQtZGxlcC0yMw0KPiANCj4gDQo+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mDQo+IHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiBtYW5ldEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBt YWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tYW5ldA== From nobody Tue Jul 19 14:23:24 2016 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 1D79012D897 for ; Tue, 19 Jul 2016 14:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeqkrg582QBC for ; Tue, 19 Jul 2016 14:23:19 -0700 (PDT) Received: from OTTMGC002.GDCAN.COM (smtp5.gdcanada.com [209.29.4.48]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F55E12D8FE for ; Tue, 19 Jul 2016 14:23:18 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5700,7163,8231"; a="3230520" Received: from unknown (HELO gdcanada.com) ([172.16.7.198]) by OTTMGC002.GDCAN.COM with ESMTP/TLS/AES256-SHA; 19 Jul 2016 17:23:15 -0400 Received: from OTTSVW202.gdcan.com ([fe80::a454:7fac:ec41:17aa]) by ottsvw198.gdcan.com ([::1]) with mapi id 14.03.0279.002; Tue, 19 Jul 2016 17:23:15 -0400 From: "Viberg, Neil" To: "manet@ietf.org" Thread-Topic: [manet] DLEP-23 addition of RFC 5082 requirement Thread-Index: AdHiA545z2sVZebcS7SzOvfAbZvLHg== Date: Tue, 19 Jul 2016 21:23:14 +0000 Message-ID: <4380A22D88B79C47883D0026E2CD55148C1194F6@ottsvw202.gdcan.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.164.53] x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22462.003 x-tm-as-result: No--52.531700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_4380A22D88B79C47883D0026E2CD55148C1194F6ottsvw202gdcanc_" MIME-Version: 1.0 Archived-At: Subject: [manet] DLEP-23 addition of RFC 5082 requirement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:23:22 -0000 --_000_4380A22D88B79C47883D0026E2CD55148C1194F6ottsvw202gdcanc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I'm confused and I'm hoping someone can help me out. 1. The update includes a requirement to implement RFC 5082 and then i= ndicates that UDP-based signals shall have a TTL of 1. RFC 5082 never talks= about a TTL of 1, it only refers to a TTL of 255. Seems that being complia= nt with DLEP and RFC 5082 at the same time will be difficult. In addition, = the only way to see the TTL from a socket call is to use raw sockets AFAIK.= Is that the correct? Is that the intent? 2. DLEP-23 requires that all messages have a TTL of 255. The problem = is that a DLEP message is a logical construction received over a TCP byte s= tream and the byte stream doesn't inherently have a TTL. How does that work= ? RFC 5082 seems more logical, all packets received as part of the TCP sess= ion must have a TTL of 255. That is clear. How does a programmer, using soc= kets, determine that each of the TCP packets has a TTL of 255? There doesn'= t appear to be any sockopts that can set that requirement and I doubt many = people are going to write their own TCP stack or mangle an existing one to = get that done. Again, how is that supposed to work? Hopefully I'm missing something because the intent of the requirement is cl= ear and laudable but the practicality of it seems suspect. Cheers, Neil >> Date: Mon, 18 Jul 2016 17:43:31 -0400 >> From: Stan Ratliff > >> To: MANET IETF > >> Subject: [manet] Fwd: I-D Action: draft-ietf-manet-dlep-23.txt >> Message-ID: >> > >> Content-Type: text/plain; charset=3D"utf-8" >> >> Hello Working Group, >> >> As you can see, there is a DLEP-23 that was posted tonight. This version= was prompted by comments received in the AD review. Most of the changes ar= e editorial - the biggest change of the bunch is a requirement to implement >> RFC5082 (The Generalized TTL Security Mechanism, or GTSM). With GTSM, DL= EP now requires all UDP-based signals to be sent with TTL=3D1. All TCP-base= d DLEP Messages are sent with TTL=3D255. The TTL values are checked on rece= ipt, and the packets are >> discarded if the TTLs don't match-up. The use o= f GTSM is to mandate that DLEP run over 1 physical hop only - it enforces t= he requirement that we run on a single Layer 2 domain. >> >> Regards, >> Stan --_000_4380A22D88B79C47883D0026E2CD55148C1194F6ottsvw202gdcanc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I’m confused and I’m hoping someone c= an help me out.

 

1.       The update includes a requirement to implement RFC = 5082 and then indicates that UDP-based signals shall have a TTL of 1. RFC 5= 082 never talks about a TTL of 1, it only refers to a TTL of 255. Seems tha= t being compliant with DLEP and RFC 5082 at the same time will be difficult. In addition, the only way to = see the TTL from a socket call is to use raw sockets AFAIK. Is that the cor= rect? Is that the intent?

 

2.       DLEP-23 requires that all messages have a TTL of 25= 5. The problem is that a DLEP message is a logical construction received ov= er a TCP byte stream and the byte stream doesn’t inherently have a TT= L. How does that work? RFC 5082 seems more logical, all packets received as part of the TCP session must have a = TTL of 255. That is clear. How does a programmer, using sockets, determine = that each of the TCP packets has a TTL of 255? There doesn’t appear t= o be any sockopts that can set that requirement and I doubt many people are going to write their own TCP stack or mangle a= n existing one to get that done. Again, how is that supposed to work?<= /o:p>

 

Hopefully I’m missing something because the= intent of the requirement is clear and laudable but the practicality of it= seems suspect.

 

Cheers,

Neil

 

>> Date: Mon, 18 Jul 2016 17:43:31 -0400

>> From: Stan Ratliff <ratliffstan@gmail.com>

>> To: MANET IETF <manet@ietf.org>

>> Subject: [manet] Fwd:  I-D Action: = draft-ietf-manet-dlep-23.txt

>> Message-ID:

>>       = ;    <CALtoyo=3DR+71Jak7qKvpTphP= yTtP8OkESFxQvmkU+V9W04rimcw@mail.gmail.com>

>> Content-Type: text/plain; charset=3D&quo= t;utf-8"

>> 

>> Hello Working Group,

>> 

>> As you can see, there is a DLEP-23 that = was posted tonight. This version was prompted by comments received in the A= D review. Most of the changes are editorial - the biggest change of the bun= ch is a requirement to implement

>> RFC5082 (The Generalized TTL Security Me= chanism, or GTSM). With GTSM, DLEP now requires all UDP-based signals to be= sent with TTL=3D1. All TCP-based DLEP Messages are sent with TTL=3D255. Th= e TTL values are checked on receipt, and the packets are >> discarded if the TTLs don't match-up. The use of GTSM= is to mandate that DLEP run over 1 physical hop only - it enforces the req= uirement that we run on a single Layer 2 domain.

>> 

>> Regards,

>> Stan

 

 

--_000_4380A22D88B79C47883D0026E2CD55148C1194F6ottsvw202gdcanc_-- From nobody Tue Jul 19 14:57:07 2016 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 A84AF12D97B for ; Tue, 19 Jul 2016 14:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRRBK3sl1Ir3 for ; Tue, 19 Jul 2016 14:57:01 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF7412D995 for ; Tue, 19 Jul 2016 14:56:59 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 19 Jul 2016 22:56:18 +0100 From: Rick Taylor To: "manet@ietf.org" , "Neil.Viberg@gd-ms.ca" Thread-Topic: [manet] DLEP-23 addition of RFC 5082 requirement Thread-Index: AdHiA545z2sVZebcS7SzOvfAbZvLHv//+L4A Date: Tue, 19 Jul 2016 21:56:16 +0000 Message-ID: <1468965376.8956.77.camel@tropicalstormsoftware.com> References: <4380A22D88B79C47883D0026E2CD55148C1194F6@ottsvw202.gdcan.com> In-Reply-To: <4380A22D88B79C47883D0026E2CD55148C1194F6@ottsvw202.gdcan.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP-23 addition of RFC 5082 requirement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:57:04 -0000 T24gVHVlLCAyMDE2LTA3LTE5IGF0IDIxOjIzICswMDAwLCBWaWJlcmcsIE5laWwgd3JvdGU6DQo+ IEZvbGtzLA0KDQpIaSBOZWlsLA0KDQpDb21tZW50cyBpbmxpbmUuLi4NCg0KPiDCoA0KPiBJ4oCZ bSBjb25mdXNlZCBhbmQgSeKAmW0gaG9waW5nIHNvbWVvbmUgY2FuIGhlbHAgbWUgb3V0Lg0KPiDC oA0KPiAxLsKgwqDCoMKgwqDCoCBUaGUgdXBkYXRlIGluY2x1ZGVzIGEgcmVxdWlyZW1lbnQgdG8g aW1wbGVtZW50IFJGQyA1MDgyIGFuZA0KPiB0aGVuIGluZGljYXRlcyB0aGF0IFVEUC1iYXNlZCBz aWduYWxzIHNoYWxsIGhhdmUgYSBUVEwgb2YgMS4gUkZDIDUwODINCj4gbmV2ZXIgdGFsa3MgYWJv dXQgYSBUVEwgb2YgMSwgaXQgb25seSByZWZlcnMgdG8gYSBUVEwgb2YgMjU1LiBTZWVtcw0KPiB0 aGF0IGJlaW5nIGNvbXBsaWFudCB3aXRoIERMRVAgYW5kIFJGQyA1MDgyIGF0IHRoZSBzYW1lIHRp bWUgd2lsbCBiZQ0KPiBkaWZmaWN1bHQuIEluIGFkZGl0aW9uLCB0aGUgb25seSB3YXkgdG8gc2Vl IHRoZSBUVEwgZnJvbSBhIHNvY2tldA0KPiBjYWxsIGlzIHRvIHVzZSByYXcgc29ja2V0cyBBRkFJ Sy4gSXMgdGhhdCB0aGUgY29ycmVjdD8gSXMgdGhhdCB0aGUNCj4gaW50ZW50Pw0KDQpUaGF0IGlz IHRoZSBpbnRlbnQuIMKgVXNpbmcgVURQIFRUTCBvZiAxIGlzIHRvIHByZXZlbnQgbXVsdGlob3AN CmRpc2NvdmVyeSBtZXNzYWdlcyBmcm9tIGV2ZW4gcmVhY2hpbmcgdGhlIG1vZGVtLiDCoFdvcmtp bmcgaXQgdGhyb3VnaCwNCml0IHdvdWxkIGJlIHBvc3NpYmxlIGZvciBhICdiYWQnIGltcGxlbWVu dGF0aW9uIHRvIGZvcmNlIGRpc2NvdmVyeQ0KbWVzc2FnZXMgdG8gdHJhdmVyc2UgbXVsdGlwbGUg aG9wcywgd2l0aCB0aGUgcmVjZWl2ZXIgc2VlaW5nIGEgVFRMIG9mDQoxLCBidXQgdGhhdCBpcyBj YXVnaHQgYnkgdGhlIFRUTCAyNTUgcmVxdWlyZW1lbnQgb24gdGhlIGNvbm5lY3Rpb24uIMKgDQoN CkEgd2VsbC1iZWhhdmVkIGltcGxlbWVudGF0aW9uIHdpbGwgc2V0IGEgVFRMIG9mIDEgcHJldmVu dGluZw0KdW5uZWNlc3Nhcnkgcm91dGluZyBvZiBwYWNrZXRzIGV2ZW4gaWYgdXNpbmcgYSBub24t bGluay1sb2NhbCBhZGRyZXNzLsKgDQoNClRoaXMgaXMgbm90IFJGQyA1MDgyIGJlaGF2aW91ciBi dXQgYSBtZWNoYW5pc20gdG8gcHJldmVudCBtdWx0aS1ob3ANCmRpc2NvdmVyeS4NCg0KVXNpbmcg VFRMIDI1NSBmb3IgdGhlIFRDUCBjb25uZWN0aW9uIGlzIHRvIGRldGVjdCBhbmQgZ3VhcmFudGVl IHRoYXQNCnRoZSBUQ1AgcGVlciBpcyBvbmx5IG9uZSBob3AgYXdheSwgYXMgZGVmaW5lZCBieSBS RkMgNTA4Mi4NCg0KPiDCoA0KPiAyLsKgwqDCoMKgwqDCoCBETEVQLTIzIHJlcXVpcmVzIHRoYXQg YWxsIG1lc3NhZ2VzIGhhdmUgYSBUVEwgb2YgMjU1LiBUaGUNCj4gcHJvYmxlbSBpcyB0aGF0IGEg RExFUCBtZXNzYWdlIGlzIGEgbG9naWNhbCBjb25zdHJ1Y3Rpb24gcmVjZWl2ZWQNCj4gb3ZlciBh IFRDUCBieXRlIHN0cmVhbSBhbmQgdGhlIGJ5dGUgc3RyZWFtIGRvZXNu4oCZdCBpbmhlcmVudGx5 IGhhdmUgYQ0KPiBUVEwuIEhvdyBkb2VzIHRoYXQgd29yaz8gUkZDIDUwODIgc2VlbXMgbW9yZSBs b2dpY2FsLCBhbGwgcGFja2V0cw0KPiByZWNlaXZlZCBhcyBwYXJ0IG9mIHRoZSBUQ1Agc2Vzc2lv biBtdXN0IGhhdmUgYSBUVEwgb2YgMjU1LiBUaGF0IGlzDQo+IGNsZWFyLiBIb3cgZG9lcyBhIHBy b2dyYW1tZXIsIHVzaW5nIHNvY2tldHMsIGRldGVybWluZSB0aGF0IGVhY2ggb2YNCj4gdGhlIFRD UCBwYWNrZXRzIGhhcyBhIFRUTCBvZiAyNTU/IFRoZXJlIGRvZXNu4oCZdCBhcHBlYXIgdG8gYmUg YW55DQo+IHNvY2tvcHRzIHRoYXQgY2FuIHNldCB0aGF0IHJlcXVpcmVtZW50IGFuZCBJIGRvdWJ0 IG1hbnkgcGVvcGxlIGFyZQ0KPiBnb2luZyB0byB3cml0ZSB0aGVpciBvd24gVENQIHN0YWNrIG9y IG1hbmdsZSBhbiBleGlzdGluZyBvbmUgdG8gZ2V0DQo+IHRoYXQgZG9uZS4gQWdhaW4sIGhvdyBp cyB0aGF0IHN1cHBvc2VkIHRvIHdvcms/DQoNCkkga25vdyBhIHJlYXNvbmFibHkgbW9kZXJuIExp bnV4IGhhcyBhIHVzZXItbW9kZSBzb2NrZXQgaW9jdGwNCihJUF9NSU5UVEwgLcKgaHR0cHM6Ly9s d24ubmV0L0FydGljbGVzLzM3OTA3MC8pIHRvIHJlc3RyaWN0IHRoZSBUVEwgb24gYQ0Kc29ja2V0 LCBhbmQgaW9jdGwoSVBfVFRMKSBjYW4gYmUgdXNlZCB3aXRoIFVEUCB0byBnZXQgdGhlIGRhdGFn cmFtIFRUTC4NCsKgT3RoZXIgb3BlcmF0aW5nIHN5c3RlbXMgbWF5IGhhdmUgc2ltaWxhciBiZWhh dmlvdXIuDQoNCj4gwqANCj4gSG9wZWZ1bGx5IEnigJltIG1pc3Npbmcgc29tZXRoaW5nIGJlY2F1 c2UgdGhlIGludGVudCBvZiB0aGUgcmVxdWlyZW1lbnQNCj4gaXMgY2xlYXIgYW5kIGxhdWRhYmxl IGJ1dCB0aGUgcHJhY3RpY2FsaXR5IG9mIGl0IHNlZW1zIHN1c3BlY3QuDQoNClRoZSBpbnRlbnQg aXMgdG8gZW5mb3JjZSB0aGUgc2luZ2xlIGxheWVyLTIgY29ubmVjdGl2aXR5IHJlcXVpcmVtZW50 LA0KcHJldmVudGluZzogYSkgVGhlIGRpc2NvdmVyeSBvZiBtb2RlbXMgbW9yZSB0aGFuIDEgaG9w IGF3YXksIGFuZCBiKQ0KZXN0YWJsaXNoaW5nIGEgVENQIGNvbm5lY3Rpb24gdG8gYSBtb2RlbSBt b3JlIHRoYW4gMSBob3AgYXdheS4NCg0KSG9wZSB0aGF0IGhlbHBzLA0KDQpSaWNrDQoNCj4gwqAN Cj4gQ2hlZXJzLA0KPiBOZWlsDQo+IMKgDQo+ID4+IERhdGU6IE1vbiwgMTggSnVsIDIwMTYgMTc6 NDM6MzEgLTA0MDANCj4gPj4gRnJvbTogU3RhbiBSYXRsaWZmIDxyYXRsaWZmc3RhbkBnbWFpbC5j b20+DQo+ID4+IFRvOiBNQU5FVCBJRVRGIDxtYW5ldEBpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDog W21hbmV0XSBGd2Q6wqAgSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLTIzLnR4dA0K PiA+PiBNZXNzYWdlLUlEOg0KPiA+PsKgwqDCoMKgwqDCoMKgwqDCoMKgIDxDQUx0b3lvPVIrNzFK YWs3cUt2cFRwaFB5VHRQOE9rRVNGeFF2bWtVK1Y5VzA0cmltY3dAbWFpDQo+IGwuZ21haWwuY29t Pg0KPiA+PiBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InV0Zi04Ig0KPiA+PsKg DQo+ID4+IEhlbGxvIFdvcmtpbmcgR3JvdXAsDQo+ID4+wqANCj4gPj4gQXMgeW91IGNhbiBzZWUs IHRoZXJlIGlzIGEgRExFUC0yMyB0aGF0IHdhcyBwb3N0ZWQgdG9uaWdodC4gVGhpcw0KPiB2ZXJz aW9uIHdhcyBwcm9tcHRlZCBieSBjb21tZW50cyByZWNlaXZlZCBpbiB0aGUgQUQgcmV2aWV3LiBN b3N0IG9mDQo+IHRoZSBjaGFuZ2VzIGFyZSBlZGl0b3JpYWwgLSB0aGUgYmlnZ2VzdCBjaGFuZ2Ug b2YgdGhlIGJ1bmNoIGlzIGENCj4gcmVxdWlyZW1lbnQgdG8gaW1wbGVtZW50DQo+ID4+IFJGQzUw ODIgKFRoZSBHZW5lcmFsaXplZCBUVEwgU2VjdXJpdHkgTWVjaGFuaXNtLCBvciBHVFNNKS4gV2l0 aA0KPiBHVFNNLCBETEVQIG5vdyByZXF1aXJlcyBhbGwgVURQLWJhc2VkIHNpZ25hbHMgdG8gYmUg c2VudCB3aXRoIFRUTD0xLg0KPiBBbGwgVENQLWJhc2VkIERMRVAgTWVzc2FnZXMgYXJlIHNlbnQg d2l0aCBUVEw9MjU1LiBUaGUgVFRMIHZhbHVlcyBhcmUNCj4gY2hlY2tlZCBvbiByZWNlaXB0LCBh bmQgdGhlIHBhY2tldHMgYXJlID4+IGRpc2NhcmRlZCBpZiB0aGUgVFRMcw0KPiBkb24ndCBtYXRj aC11cC4gVGhlIHVzZSBvZiBHVFNNIGlzIHRvIG1hbmRhdGUgdGhhdCBETEVQIHJ1biBvdmVyIDEN Cj4gcGh5c2ljYWwgaG9wIG9ubHkgLSBpdCBlbmZvcmNlcyB0aGUgcmVxdWlyZW1lbnQgdGhhdCB3 ZSBydW4gb24gYQ0KPiBzaW5nbGUgTGF5ZXIgMiBkb21haW4uDQo+ID4+wqANCj4gPj4gUmVnYXJk cywNCj4gPj4gU3Rhbg0KPiDCoA0KPiDCoA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBtYW5ldCBtYWlsaW5nIGxpc3QNCj4gbWFuZXRAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA== From nobody Tue Jul 19 16:59:19 2016 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 1A6AD12D9C1 for ; Tue, 19 Jul 2016 16:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B1k-cnTHN0U for ; Tue, 19 Jul 2016 16:59:15 -0700 (PDT) Received: from OTTMGC001.GDCAN.COM (smtp4.gdcanada.com [209.29.4.47]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58FE312D98E for ; Tue, 19 Jul 2016 16:59:14 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5700,7163,8231"; a="3985098" Received: from unknown (HELO gdcanada.com) ([172.16.7.221]) by OTTMGC001.GDCAN.COM with ESMTP/TLS/AES256-SHA; 19 Jul 2016 19:59:13 -0400 Received: from OTTSVW202.gdcan.com ([fe80::a454:7fac:ec41:17aa]) by ottsvw200.gdcan.com ([::1]) with mapi id 14.03.0279.002; Tue, 19 Jul 2016 19:59:11 -0400 From: "Viberg, Neil" To: Rick Taylor Thread-Topic: [manet] DLEP-23 addition of RFC 5082 requirement Thread-Index: AQHR4ghwyWZ2TRm1Bk+PuQE/YC4FZ6AgVbuA Date: Tue, 19 Jul 2016 23:59:10 +0000 Message-ID: <4380A22D88B79C47883D0026E2CD55148C11954D@ottsvw202.gdcan.com> References: <4380A22D88B79C47883D0026E2CD55148C1194F6@ottsvw202.gdcan.com> <1468965376.8956.77.camel@tropicalstormsoftware.com> In-Reply-To: <1468965376.8956.77.camel@tropicalstormsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.164.53] x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22462.001 x-tm-as-result: No--51.227200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-23 addition of RFC 5082 requirement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 23:59:18 -0000 VGhhbmtzIFJpY2ssDQoNCkkgdW5kZXJzdG9vZCB0aGUgcHVycG9zZSBvZiB0aGUgcmVxdWlyZW1l bnRzIGFuZCBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIHRoZSBpbnRlbnQgb2YgaXQgYWxsLg0KDQpZ b3UndmUgY2xlYXJlZCB1cCBteSBxdWVzdGlvbiBvbiBUQ1AuIEkgd2FzIGxvb2tpbmcgYXQgc29j a29wdHMgbm90IGlvY3Rscywgc28sIHRoYW5rIHlvdSBmb3IgdGhhdCBpbmZvcm1hdGlvbi4gWW91 ciBsaW5lIGFib3V0ICJPdGhlciBvcGVyYXRpbmcgc3lzdGVtcyBtYXkgaGF2ZSBzaW1pbGFyIGJl aGF2aW91ciIgbWF5IGJlIGEgbGl0dGxlIHdvcnJ5aW5nIHRvIHRob3NlIHRoYXQgZG9uJ3QgdXNl IExpbnV4IGJ1dCBwcmVzdW1hYmx5IHRoZXkgd2lsbCB3ZWlnaCBpbiBpZiBpdCBpcyBhbiBpc3N1 ZS4NCg0KSSB1bmRlcnN0YW5kIHdoYXQgeW91J3ZlIHNhaWQgYWJvdXQgdGhlIFVEUCBUVEwgb2Yg MSBhbmQgeW91J3ZlIGluZGljYXRlZCBob3cgdG8gZ2V0IHRoYXQuIFRoYXQncyBncmVhdC4NCg0K TXkgY29uZnVzaW9uIGFib3V0IFVEUCBUVExzIGFyb3NlIGJlY2F1c2UgdGhlIHBhcmFncmFwaDoN Cg0KICAgICAgICAgIFRvIGVuZm9yY2UgdGhlIHNpbmdsZSBMYXllciAyIGRvbWFpbiwgaW1wbGVt ZW50YXRpb25zIE1VU1Qgc3VwcG9ydCB0aGUgR2VuZXJhbGl6ZWQgVFRMIFNlY3VyaXR5IE1lY2hh bmlzbSBbUkZDNTA4Ml0uDQoNCm1ha2VzIGEgYmxhbmtldCBzdGF0ZW1lbnQgd2l0aG91dCBjb25z dHJhaW50IHRvIFVEUCBvciBUQ1AuIEkgd291bGQgbm9ybWFsbHkgaW50ZXJwcmV0IGl0IGFzIGFw cGx5aW5nIHRvIGFsbCBkYXRhIGV4Y2hhbmdlcyBzaW5jZSB0aGUgUkZDIGNhbiBhcHBseSB0byBi b3RoIFRDUCBhbmQgVURQLg0KDQpJdCBtYXkgY2xlYXJlciBpZjoNCg0KICAgRExFUCBNVVNUIGJl IGltcGxlbWVudGVkIG9uIGEgc2luZ2xlIExheWVyIDIgZG9tYWluLiAgVGhlIHByb3RvY29sDQog ICBpZGVudGlmaWVzIG5leHQtaG9wIGRlc3RpbmF0aW9ucyBieSB1c2luZyB0aGUgTUFDIGFkZHJl c3MgZm9yDQogICBkZWxpdmVyaW5nIGRhdGEgdHJhZmZpYy4gIE5vIG1hbmlwdWxhdGlvbiBvciBz dWJzdGl0dXRpb24gaXMNCiAgIHBlcmZvcm1lZDsgdGhlIE1BQyBhZGRyZXNzIHN1cHBsaWVkIGlu IGFsbCBETEVQIE1lc3NhZ2VzIGlzIHVzZWQgYXMNCiAgIHRoZSBEZXN0aW5hdGlvbiBNQUMgYWRk cmVzcyBmb3IgZnJhbWVzIGVtaXR0ZWQgYnkgdGhlIHBhcnRpY2lwYXRpbmcNCiAgIHJvdXRlci4g IE1BQyBhZGRyZXNzZXMgTVVTVCBiZSB1bmlxdWUgd2l0aGluIHRoZSBjb250ZXh0IG9mIHJvdXRl ci0NCiAgIG1vZGVtIHNlc3Npb24uDQoNCiAgIFRvIGVuZm9yY2UgdGhlIHNpbmdsZSBMYXllciAy IGRvbWFpbiwgaW1wbGVtZW50YXRpb25zIE1VU1Qgc3VwcG9ydA0KICAgVGhlIEdlbmVyYWxpemVk IFRUTCBTZWN1cml0eSBNZWNoYW5pc20gW1JGQzUwODJdLg0KDQogICBETEVQIHNwZWNpZmllcyBV RFAgbXVsdGljYXN0IGZvciBzaW5nbGUtaG9wIGRpc2NvdmVyeSBzaWduYWxpbmcsIGFuZA0KICAg VENQIGZvciB0cmFuc3BvcnQgb2YgdGhlIE1lc3NhZ2VzLiAgTW9kZW1zIGFuZCByb3V0ZXJzIHBh cnRpY2lwYXRpbmcNCiAgIGluIERMRVAgc2Vzc2lvbnMgTVVTVCBoYXZlIHRvcG9sb2dpY2FsbHkg Y29uc2lzdGVudCBJUCBhZGRyZXNzZXMNCiAgIGFzc2lnbmVkLiAgSXQgaXMgUkVDT01NRU5ERUQg dGhhdCBETEVQIGltcGxlbWVudGF0aW9ucyB1dGlsaXplIElQdjYNCiAgIGxpbmstbG9jYWwgYWRk cmVzc2VzIHRvIHJlZHVjZSB0aGUgYWRtaW5pc3RyYXRpdmUgYnVyZGVuIG9mIGFkZHJlc3MNCiAg IGFzc2lnbm1lbnQuICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBhZGhlcmUgdG8gdGhlIHByb2NlZHVy ZSBkb2N1bWVudGVkDQogICBpbiBbUkZDNTA4Ml0gZm9yIGFsbCBETEVQIE1lc3NhZ2VzIChUQ1Ag dHJhZmZpYykuDQoNCiAgIEluIG9yZGVyIHRvIGtlZXAgdGhlIERMRVAgZGlzY292ZXJ5IFNpZ25h bHMsIHdoaWNoIGFyZSBtdWx0aWNhc3QgVURQLQ0KICAgYmFzZWQsIGxpbWl0ZWQgdG8gdGhlIHNh bWUgTGF5ZXIgMiBkb21haW4sIGltcGxlbWVudGF0aW9ucyBNVVNUIHNldA0KICAgdGhlIFRUTCBv ZiBhbGwgRExFUCBTaWduYWxzIHRvIDEsIGFuZCBNVVNUIGNoZWNrIGZvciBUVEwgPSAxIG9uDQog ICByZWNlaXB0IG9mIERMRVAgU2lnbmFscy4gIEFueSBzaWduYWwgcmVjZWl2ZWQgd2l0aCBhIFRU TCBub3QgZXF1YWwgdG8NCiAgIDEgTVVTVCBiZSBkaXNjYXJkZWQuDQoNCndhcyByZXBsYWNlZCB3 aXRoIHNvbWV0aGluZyBsaWtlOg0KIA0KICAgRExFUCBNVVNUIGJlIGltcGxlbWVudGVkIG9uIGEg c2luZ2xlIExheWVyIDIgZG9tYWluLiAgVGhlIHByb3RvY29sDQogICBpZGVudGlmaWVzIG5leHQt aG9wIGRlc3RpbmF0aW9ucyBieSB1c2luZyB0aGUgTUFDIGFkZHJlc3MgZm9yDQogICBkZWxpdmVy aW5nIGRhdGEgdHJhZmZpYy4gIE5vIG1hbmlwdWxhdGlvbiBvciBzdWJzdGl0dXRpb24gaXMNCiAg IHBlcmZvcm1lZDsgdGhlIE1BQyBhZGRyZXNzIHN1cHBsaWVkIGluIGFsbCBETEVQIE1lc3NhZ2Vz IGlzIHVzZWQgYXMNCiAgIHRoZSBEZXN0aW5hdGlvbiBNQUMgYWRkcmVzcyBmb3IgZnJhbWVzIGVt aXR0ZWQgYnkgdGhlIHBhcnRpY2lwYXRpbmcNCiAgIHJvdXRlci4gIE1BQyBhZGRyZXNzZXMgTVVT VCBiZSB1bmlxdWUgd2l0aGluIHRoZSBjb250ZXh0IG9mIHJvdXRlci0NCiAgIG1vZGVtIHNlc3Np b24uDQoNCiAgIERMRVAgc3BlY2lmaWVzIFVEUCBtdWx0aWNhc3QgZm9yIHNpbmdsZS1ob3AgZGlz Y292ZXJ5IHNpZ25hbGluZywgYW5kDQogICBUQ1AgZm9yIHRyYW5zcG9ydCBvZiB0aGUgTWVzc2Fn ZXMuICBNb2RlbXMgYW5kIHJvdXRlcnMgcGFydGljaXBhdGluZw0KICAgaW4gRExFUCBzZXNzaW9u cyBNVVNUIGhhdmUgdG9wb2xvZ2ljYWxseSBjb25zaXN0ZW50IElQIGFkZHJlc3Nlcw0KICAgYXNz aWduZWQuICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IERMRVAgaW1wbGVtZW50YXRpb25zIHV0aWxp emUgSVB2Ng0KICAgbGluay1sb2NhbCBhZGRyZXNzZXMgdG8gcmVkdWNlIHRoZSBhZG1pbmlzdHJh dGl2ZSBidXJkZW4gb2YgYWRkcmVzcw0KICAgYXNzaWdubWVudC4NCg0KICAgVG8gZW5mb3JjZSB0 aGUgc2luZ2xlIExheWVyIDIgZG9tYWluIGZvciBETEVQIE1lc3NhZ2VzIChUQ1AgdHJhZmZpYyks DQogICBpbXBsZW1lbnRhdGlvbnMgTVVTVCBhZGhlcmUgdG8gdGhlIEdlbmVyYWxpemVkIFRUTCBT ZWN1cml0eSBNZWNoYW5pc20NCiAgIGRvY3VtZW50ZWQgaW4gW1JGQzUwODJdIGZvciBhbGwgRExF UCBNZXNzYWdlcy4NCg0KICAgSW4gb3JkZXIgdG8ga2VlcCB0aGUgRExFUCBkaXNjb3ZlcnkgU2ln bmFscywgd2hpY2ggYXJlIG11bHRpY2FzdCBVRFAtDQogICBiYXNlZCwgbGltaXRlZCB0byB0aGUg c2FtZSBMYXllciAyIGRvbWFpbiwgaW1wbGVtZW50YXRpb25zIE1VU1Qgc2V0DQogICB0aGUgVFRM IG9mIGFsbCBETEVQIFNpZ25hbHMgdG8gMSwgYW5kIE1VU1QgY2hlY2sgZm9yIFRUTCA9IDEgb24N CiAgIHJlY2VpcHQgb2YgRExFUCBTaWduYWxzLiAgQW55IHNpZ25hbCByZWNlaXZlZCB3aXRoIGEg VFRMIG5vdCBlcXVhbCB0bw0KICAgMSBNVVNUIGJlIGRpc2NhcmRlZC4NCgkNCkNoZWVycywNCk5l aWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJpY2sgVGF5bG9yIFttYWls dG86cmlja0B0cm9waWNhbHN0b3Jtc29mdHdhcmUuY29tXSANClNlbnQ6IFR1ZXNkYXksIEp1bHkg MTksIDIwMTYgMzo1NiBQTQ0KVG86IG1hbmV0QGlldGYub3JnOyBWaWJlcmcsIE5laWwNClN1Ympl Y3Q6IFJlOiBbbWFuZXRdIERMRVAtMjMgYWRkaXRpb24gb2YgUkZDIDUwODIgcmVxdWlyZW1lbnQN Cg0KT24gVHVlLCAyMDE2LTA3LTE5IGF0IDIxOjIzICswMDAwLCBWaWJlcmcsIE5laWwgd3JvdGU6 DQo+IEZvbGtzLA0KDQpIaSBOZWlsLA0KDQpDb21tZW50cyBpbmxpbmUuLi4NCg0KPiDCoA0KPiBJ 4oCZbSBjb25mdXNlZCBhbmQgSeKAmW0gaG9waW5nIHNvbWVvbmUgY2FuIGhlbHAgbWUgb3V0Lg0K PiDCoA0KPiAxLsKgwqDCoMKgwqDCoCBUaGUgdXBkYXRlIGluY2x1ZGVzIGEgcmVxdWlyZW1lbnQg dG8gaW1wbGVtZW50IFJGQyA1MDgyIGFuZCANCj4gdGhlbiBpbmRpY2F0ZXMgdGhhdCBVRFAtYmFz ZWQgc2lnbmFscyBzaGFsbCBoYXZlIGEgVFRMIG9mIDEuIFJGQyA1MDgyIA0KPiBuZXZlciB0YWxr cyBhYm91dCBhIFRUTCBvZiAxLCBpdCBvbmx5IHJlZmVycyB0byBhIFRUTCBvZiAyNTUuIFNlZW1z IA0KPiB0aGF0IGJlaW5nIGNvbXBsaWFudCB3aXRoIERMRVAgYW5kIFJGQyA1MDgyIGF0IHRoZSBz YW1lIHRpbWUgd2lsbCBiZSANCj4gZGlmZmljdWx0LiBJbiBhZGRpdGlvbiwgdGhlIG9ubHkgd2F5 IHRvIHNlZSB0aGUgVFRMIGZyb20gYSBzb2NrZXQgY2FsbCANCj4gaXMgdG8gdXNlIHJhdyBzb2Nr ZXRzIEFGQUlLLiBJcyB0aGF0IHRoZSBjb3JyZWN0PyBJcyB0aGF0IHRoZSBpbnRlbnQ/DQoNClRo YXQgaXMgdGhlIGludGVudC4gwqBVc2luZyBVRFAgVFRMIG9mIDEgaXMgdG8gcHJldmVudCBtdWx0 aWhvcCBkaXNjb3ZlcnkgbWVzc2FnZXMgZnJvbSBldmVuIHJlYWNoaW5nIHRoZSBtb2RlbS4gwqBX b3JraW5nIGl0IHRocm91Z2gsIGl0IHdvdWxkIGJlIHBvc3NpYmxlIGZvciBhICdiYWQnIGltcGxl bWVudGF0aW9uIHRvIGZvcmNlIGRpc2NvdmVyeSBtZXNzYWdlcyB0byB0cmF2ZXJzZSBtdWx0aXBs ZSBob3BzLCB3aXRoIHRoZSByZWNlaXZlciBzZWVpbmcgYSBUVEwgb2YgMSwgYnV0IHRoYXQgaXMg Y2F1Z2h0IGJ5IHRoZSBUVEwgMjU1IHJlcXVpcmVtZW50IG9uIHRoZSBjb25uZWN0aW9uLiDCoA0K DQpBIHdlbGwtYmVoYXZlZCBpbXBsZW1lbnRhdGlvbiB3aWxsIHNldCBhIFRUTCBvZiAxIHByZXZl bnRpbmcgdW5uZWNlc3Nhcnkgcm91dGluZyBvZiBwYWNrZXRzIGV2ZW4gaWYgdXNpbmcgYSBub24t bGluay1sb2NhbCBhZGRyZXNzLsKgDQoNClRoaXMgaXMgbm90IFJGQyA1MDgyIGJlaGF2aW91ciBi dXQgYSBtZWNoYW5pc20gdG8gcHJldmVudCBtdWx0aS1ob3AgZGlzY292ZXJ5Lg0KDQpVc2luZyBU VEwgMjU1IGZvciB0aGUgVENQIGNvbm5lY3Rpb24gaXMgdG8gZGV0ZWN0IGFuZCBndWFyYW50ZWUg dGhhdCB0aGUgVENQIHBlZXIgaXMgb25seSBvbmUgaG9wIGF3YXksIGFzIGRlZmluZWQgYnkgUkZD IDUwODIuDQoNCj4gwqANCj4gMi7CoMKgwqDCoMKgwqAgRExFUC0yMyByZXF1aXJlcyB0aGF0IGFs bCBtZXNzYWdlcyBoYXZlIGEgVFRMIG9mIDI1NS4gVGhlIA0KPiBwcm9ibGVtIGlzIHRoYXQgYSBE TEVQIG1lc3NhZ2UgaXMgYSBsb2dpY2FsIGNvbnN0cnVjdGlvbiByZWNlaXZlZCBvdmVyIA0KPiBh IFRDUCBieXRlIHN0cmVhbSBhbmQgdGhlIGJ5dGUgc3RyZWFtIGRvZXNu4oCZdCBpbmhlcmVudGx5 IGhhdmUgYSBUVEwuIA0KPiBIb3cgZG9lcyB0aGF0IHdvcms/IFJGQyA1MDgyIHNlZW1zIG1vcmUg bG9naWNhbCwgYWxsIHBhY2tldHMgcmVjZWl2ZWQgDQo+IGFzIHBhcnQgb2YgdGhlIFRDUCBzZXNz aW9uIG11c3QgaGF2ZSBhIFRUTCBvZiAyNTUuIFRoYXQgaXMgY2xlYXIuIEhvdyANCj4gZG9lcyBh IHByb2dyYW1tZXIsIHVzaW5nIHNvY2tldHMsIGRldGVybWluZSB0aGF0IGVhY2ggb2YgdGhlIFRD UCANCj4gcGFja2V0cyBoYXMgYSBUVEwgb2YgMjU1PyBUaGVyZSBkb2VzbuKAmXQgYXBwZWFyIHRv IGJlIGFueSBzb2Nrb3B0cyB0aGF0IA0KPiBjYW4gc2V0IHRoYXQgcmVxdWlyZW1lbnQgYW5kIEkg ZG91YnQgbWFueSBwZW9wbGUgYXJlIGdvaW5nIHRvIHdyaXRlIA0KPiB0aGVpciBvd24gVENQIHN0 YWNrIG9yIG1hbmdsZSBhbiBleGlzdGluZyBvbmUgdG8gZ2V0IHRoYXQgZG9uZS4gQWdhaW4sIA0K PiBob3cgaXMgdGhhdCBzdXBwb3NlZCB0byB3b3JrPw0KDQpJIGtub3cgYSByZWFzb25hYmx5IG1v ZGVybiBMaW51eCBoYXMgYSB1c2VyLW1vZGUgc29ja2V0IGlvY3RsIChJUF9NSU5UVEwgLcKgaHR0 cHM6Ly9sd24ubmV0L0FydGljbGVzLzM3OTA3MC8pIHRvIHJlc3RyaWN0IHRoZSBUVEwgb24gYSBz b2NrZXQsIGFuZCBpb2N0bChJUF9UVEwpIGNhbiBiZSB1c2VkIHdpdGggVURQIHRvIGdldCB0aGUg ZGF0YWdyYW0gVFRMLg0KwqBPdGhlciBvcGVyYXRpbmcgc3lzdGVtcyBtYXkgaGF2ZSBzaW1pbGFy IGJlaGF2aW91ci4NCg0KPiDCoA0KPiBIb3BlZnVsbHkgSeKAmW0gbWlzc2luZyBzb21ldGhpbmcg YmVjYXVzZSB0aGUgaW50ZW50IG9mIHRoZSByZXF1aXJlbWVudCANCj4gaXMgY2xlYXIgYW5kIGxh dWRhYmxlIGJ1dCB0aGUgcHJhY3RpY2FsaXR5IG9mIGl0IHNlZW1zIHN1c3BlY3QuDQoNClRoZSBp bnRlbnQgaXMgdG8gZW5mb3JjZSB0aGUgc2luZ2xlIGxheWVyLTIgY29ubmVjdGl2aXR5IHJlcXVp cmVtZW50LA0KcHJldmVudGluZzogYSkgVGhlIGRpc2NvdmVyeSBvZiBtb2RlbXMgbW9yZSB0aGFu IDEgaG9wIGF3YXksIGFuZCBiKSBlc3RhYmxpc2hpbmcgYSBUQ1AgY29ubmVjdGlvbiB0byBhIG1v ZGVtIG1vcmUgdGhhbiAxIGhvcCBhd2F5Lg0KDQpIb3BlIHRoYXQgaGVscHMsDQoNClJpY2sNCg0K From nobody Tue Jul 19 22:51:13 2016 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 753F712DA85 for ; Tue, 19 Jul 2016 22:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-jEw7fB-0So for ; Tue, 19 Jul 2016 22:51:10 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA8B12D1A9 for ; Tue, 19 Jul 2016 22:51:09 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id x1so36083683qkb.3 for ; Tue, 19 Jul 2016 22:51: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:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zRZeQxtFoSIKHyVSGo4hYXnneQm2PiBsvrKI3P0HfTs=; b=MCs+16wJb7pxIXKn3Z+Kgcv738dGxAKBFKz1pneJKMTw6XAIOISAn7ipBYmYgyxjWp Iun0yTlZM+ll0qST6G05Sa/mNmsUHynpjgBdjsmm0A328xOqDlFmXqo58U28DT47BOzx k3ZPgagWVHdZo7M3xjH2wgieAMDhlUEbrHy2bc0CGuWlTfCbUSop+Z6b5pj+WKJ6uE5O PnaS4ryxMxcqV79CCKP1izsUV0dA9RaPiPE3ZA5h71OK5xH480i7WT78BL1xrnBDCalZ PoCLOMbWS6oCmlAcIE1g7keYc8AjfUGOwlKMB1xPN91bQZaXDoH7f/J9BVhDDwTjjjiv DjfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zRZeQxtFoSIKHyVSGo4hYXnneQm2PiBsvrKI3P0HfTs=; b=Yc0JSktVFER2qqQMVuw2yxXUKgSSA37fzQHoVeo4ZAMnYT/JHOLow7wsgOjkbN8Jct OZ1335ytGpiZ8FLqPEOAkz+lyvzw/HGbYffFWcGkyBWG9kG8z1yTueW2V9hR3/StPgYW CKNUU/0H7Hh49VeKuE7t6IZ4zYgLZL9HtDvYet+h4vPUJKgykkvPl8cmAsa261qitQTS UmtnTpYH64VWWICIiy1iMc3mqqMoTipljnAAL6Ey3vZfzcYnQ9KY6WlVWjBW8QU1f7KS p5AMIvMj0ogzeYc98xXjQxNSiZA4ZzaiPXrSikSK2yudAOYstyJoxnz0qYRoWUW16Da+ Ocgg== X-Gm-Message-State: ALyK8tK/lrTlxCMEpH+vgblqDDgHpTqxPWYknARjBJ4xp1FKyfd6c8sTHTvAYAzEErhnjnaVSE+Dn3M90vAyMQ== X-Received: by 10.55.82.2 with SMTP id g2mr17801620qkb.168.1468993868898; Tue, 19 Jul 2016 22:51:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.46.102 with HTTP; Tue, 19 Jul 2016 22:50:39 -0700 (PDT) In-Reply-To: <4380A22D88B79C47883D0026E2CD55148C11954D@ottsvw202.gdcan.com> References: <4380A22D88B79C47883D0026E2CD55148C1194F6@ottsvw202.gdcan.com> <1468965376.8956.77.camel@tropicalstormsoftware.com> <4380A22D88B79C47883D0026E2CD55148C11954D@ottsvw202.gdcan.com> From: Henning Rogge Date: Wed, 20 Jul 2016 07:50:39 +0200 Message-ID: To: "Viberg, Neil" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-23 addition of RFC 5082 requirement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 05:51:12 -0000 Quote from "man 7 ip": IP_RECVTTL (since Linux 2.2) When this flag is set, pass a IP_TTL control message with the time-to-live field of the received packet as a byte. Not supported for SOCK_STREAM sockets. So we cannot easily check the TTL value on the TCP streams ( because we don't receive them per packet). Doing crazy things with the TTL is unnecessary anyways if you stick with linklocal addresses. If they get forwarded, your intermediate routers are defect. Henning On Wed, Jul 20, 2016 at 1:59 AM, Viberg, Neil wrote: > Thanks Rick, > > I understood the purpose of the requirements and I have no problem with t= he intent of it all. > > You've cleared up my question on TCP. I was looking at sockopts not ioctl= s, so, thank you for that information. Your line about "Other operating sys= tems may have similar behaviour" may be a little worrying to those that don= 't use Linux but presumably they will weigh in if it is an issue. > > I understand what you've said about the UDP TTL of 1 and you've indicated= how to get that. That's great. > > My confusion about UDP TTLs arose because the paragraph: > > To enforce the single Layer 2 domain, implementations MUST supp= ort the Generalized TTL Security Mechanism [RFC5082]. > > makes a blanket statement without constraint to UDP or TCP. I would norma= lly interpret it as applying to all data exchanges since the RFC can apply = to both TCP and UDP. > > It may clearer if: > > DLEP MUST be implemented on a single Layer 2 domain. The protocol > identifies next-hop destinations by using the MAC address for > delivering data traffic. No manipulation or substitution is > performed; the MAC address supplied in all DLEP Messages is used as > the Destination MAC address for frames emitted by the participating > router. MAC addresses MUST be unique within the context of router- > modem session. > > To enforce the single Layer 2 domain, implementations MUST support > The Generalized TTL Security Mechanism [RFC5082]. > > DLEP specifies UDP multicast for single-hop discovery signaling, and > TCP for transport of the Messages. Modems and routers participating > in DLEP sessions MUST have topologically consistent IP addresses > assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 > link-local addresses to reduce the administrative burden of address > assignment. Implementations MUST adhere to the procedure documented > in [RFC5082] for all DLEP Messages (TCP traffic). > > In order to keep the DLEP discovery Signals, which are multicast UDP- > based, limited to the same Layer 2 domain, implementations MUST set > the TTL of all DLEP Signals to 1, and MUST check for TTL =3D 1 on > receipt of DLEP Signals. Any signal received with a TTL not equal to > 1 MUST be discarded. > > was replaced with something like: > > DLEP MUST be implemented on a single Layer 2 domain. The protocol > identifies next-hop destinations by using the MAC address for > delivering data traffic. No manipulation or substitution is > performed; the MAC address supplied in all DLEP Messages is used as > the Destination MAC address for frames emitted by the participating > router. MAC addresses MUST be unique within the context of router- > modem session. > > DLEP specifies UDP multicast for single-hop discovery signaling, and > TCP for transport of the Messages. Modems and routers participating > in DLEP sessions MUST have topologically consistent IP addresses > assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 > link-local addresses to reduce the administrative burden of address > assignment. > > To enforce the single Layer 2 domain for DLEP Messages (TCP traffic), > implementations MUST adhere to the Generalized TTL Security Mechanism > documented in [RFC5082] for all DLEP Messages. > > In order to keep the DLEP discovery Signals, which are multicast UDP- > based, limited to the same Layer 2 domain, implementations MUST set > the TTL of all DLEP Signals to 1, and MUST check for TTL =3D 1 on > receipt of DLEP Signals. Any signal received with a TTL not equal to > 1 MUST be discarded. > > Cheers, > Neil > > -----Original Message----- > From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] > Sent: Tuesday, July 19, 2016 3:56 PM > To: manet@ietf.org; Viberg, Neil > Subject: Re: [manet] DLEP-23 addition of RFC 5082 requirement > > On Tue, 2016-07-19 at 21:23 +0000, Viberg, Neil wrote: >> Folks, > > Hi Neil, > > Comments inline... > >> >> I=E2=80=99m confused and I=E2=80=99m hoping someone can help me out. >> >> 1. The update includes a requirement to implement RFC 5082 and >> then indicates that UDP-based signals shall have a TTL of 1. RFC 5082 >> never talks about a TTL of 1, it only refers to a TTL of 255. Seems >> that being compliant with DLEP and RFC 5082 at the same time will be >> difficult. In addition, the only way to see the TTL from a socket call >> is to use raw sockets AFAIK. Is that the correct? Is that the intent? > > That is the intent. Using UDP TTL of 1 is to prevent multihop discovery = messages from even reaching the modem. Working it through, it would be pos= sible for a 'bad' implementation to force discovery messages to traverse mu= ltiple hops, with the receiver seeing a TTL of 1, but that is caught by the= TTL 255 requirement on the connection. > > A well-behaved implementation will set a TTL of 1 preventing unnecessary = routing of packets even if using a non-link-local address. > > This is not RFC 5082 behaviour but a mechanism to prevent multi-hop disco= very. > > Using TTL 255 for the TCP connection is to detect and guarantee that the = TCP peer is only one hop away, as defined by RFC 5082. > >> >> 2. DLEP-23 requires that all messages have a TTL of 255. The >> problem is that a DLEP message is a logical construction received over >> a TCP byte stream and the byte stream doesn=E2=80=99t inherently have a = TTL. >> How does that work? RFC 5082 seems more logical, all packets received >> as part of the TCP session must have a TTL of 255. That is clear. How >> does a programmer, using sockets, determine that each of the TCP >> packets has a TTL of 255? There doesn=E2=80=99t appear to be any sockopt= s that >> can set that requirement and I doubt many people are going to write >> their own TCP stack or mangle an existing one to get that done. Again, >> how is that supposed to work? > > I know a reasonably modern Linux has a user-mode socket ioctl (IP_MINTTL = - https://lwn.net/Articles/379070/) to restrict the TTL on a socket, and io= ctl(IP_TTL) can be used with UDP to get the datagram TTL. > Other operating systems may have similar behaviour. > >> >> Hopefully I=E2=80=99m missing something because the intent of the requir= ement >> is clear and laudable but the practicality of it seems suspect. > > The intent is to enforce the single layer-2 connectivity requirement, > preventing: a) The discovery of modems more than 1 hop away, and b) estab= lishing a TCP connection to a modem more than 1 hop away. > > Hope that helps, > > Rick > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed Jul 20 01:16:31 2016 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 3D022127078 for ; Wed, 20 Jul 2016 01:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz2pA9RF-ajA for ; Wed, 20 Jul 2016 01:16:26 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6501E12B004 for ; Wed, 20 Jul 2016 01:16:25 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 20 Jul 2016 09:15:43 +0100 From: Rick Taylor To: "hrogge@gmail.com" , "Neil.Viberg@gd-ms.ca" Thread-Topic: [manet] DLEP-23 addition of RFC 5082 requirement Thread-Index: AQHR4kq6exn2Yvso7UqCg9f7HEYlKaAg6HcA Date: Wed, 20 Jul 2016 08:15:42 +0000 Message-ID: <1469002542.28151.3.camel@tropicalstormsoftware.com> References: <4380A22D88B79C47883D0026E2CD55148C1194F6@ottsvw202.gdcan.com> <1468965376.8956.77.camel@tropicalstormsoftware.com> <4380A22D88B79C47883D0026E2CD55148C11954D@ottsvw202.gdcan.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-23 addition of RFC 5082 requirement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 08:16:29 -0000 SGVubmluZywNCg0KRm9yIFRDUCBzb2NrZXRzOiBJUF9NSU5UVEwgbm90IElQX1JFQ1ZUVEwuIMKg VW5mb3J0dW5hdGVseSBJUF9NSU5UVEwNCmRvZXMgbm90IHNlZW0gdG8gaGF2ZSBtYWRlIGl0IGlu dG8gdGhlIG1hbiBpcCg3KSBpbmZvLiDCoEl0IHdhcyBkZXNpZ25lZA0KdG8gc29sdmUgdGhlIHBy b2JsZW0gZm9yIEJHUCBpbXBsZW1lbnRhdGlvbnMsIGFuZCBkZWZpbml0ZWx5IHdvcmtzIGZvcg0K VENQOiBzZWXCoGh0dHBzOi8vbHduLm5ldC9BcnRpY2xlcy8zNzkwNzAvDQoNCkkgYmVsaWV2ZSB0 aGUgSVBfTUlOVFRMIGlkZWEgY2FtZSBmcm9tIChGcmVlPylCU0QsIHNvIEJTRCdzIG1vc3QgbGlr ZWx5DQpoYXZlIGl0Lg0KDQpDaGVlcnMsDQoNClJpY2sNCg0KDQpPbiBXZWQsIDIwMTYtMDctMjAg YXQgMDc6NTAgKzAyMDAsIEhlbm5pbmcgUm9nZ2Ugd3JvdGU6DQo+IFF1b3RlIGZyb20gIm1hbiA3 IGlwIjoNCj4gDQo+IMKgwqDCoMKgwqDCoMKgSVBfUkVDVlRUTCAoc2luY2UgTGludXggMi4yKQ0K PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoFdoZW4gdGhpcyBmbGFnIGlzIHNldCwgcGFzcyBh IElQX1RUTCBjb250cm9sIG1lc3NhZ2UNCj4gd2l0aA0KPiB0aGUgdGltZS10by1saXZlIGZpZWxk IG9mIHRoZSByZWNlaXZlZMKgwqBwYWNrZXTCoMKgYXPCoMKgYcKgwqBieXRlLsKgwqDCoE5vdA0K PiBzdXBwb3J0ZWTCoMKgZm9yDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgU09DS19TVFJF QU0gc29ja2V0cy4NCj4gDQo+IFNvIHdlIGNhbm5vdCBlYXNpbHkgY2hlY2sgdGhlIFRUTCB2YWx1 ZSBvbiB0aGUgVENQIHN0cmVhbXMgKCBiZWNhdXNlDQo+IHdlIGRvbid0IHJlY2VpdmUgdGhlbSBw ZXIgcGFja2V0KS4NCj4gDQo+IERvaW5nIGNyYXp5IHRoaW5ncyB3aXRoIHRoZSBUVEwgaXMgdW5u ZWNlc3NhcnkgYW55d2F5cyBpZiB5b3Ugc3RpY2sNCj4gd2l0aCBsaW5rbG9jYWwgYWRkcmVzc2Vz LiBJZiB0aGV5IGdldCBmb3J3YXJkZWQsIHlvdXIgaW50ZXJtZWRpYXRlDQo+IHJvdXRlcnMgYXJl IGRlZmVjdC4NCj4gDQo+IEhlbm5pbmcNCj4gDQo+IA0KPiANCj4gT24gV2VkLCBKdWwgMjAsIDIw MTYgYXQgMTo1OSBBTSwgVmliZXJnLCBOZWlsIDxOZWlsLlZpYmVyZ0BnZC1tcy5jYT4NCj4gd3Jv dGU6DQo+ID4gDQo+ID4gVGhhbmtzIFJpY2ssDQo+ID4gDQo+ID4gSSB1bmRlcnN0b29kIHRoZSBw dXJwb3NlIG9mIHRoZSByZXF1aXJlbWVudHMgYW5kIEkgaGF2ZSBubyBwcm9ibGVtDQo+ID4gd2l0 aCB0aGUgaW50ZW50IG9mIGl0IGFsbC4NCj4gPiANCj4gPiBZb3UndmUgY2xlYXJlZCB1cCBteSBx dWVzdGlvbiBvbiBUQ1AuIEkgd2FzIGxvb2tpbmcgYXQgc29ja29wdHMgbm90DQo+ID4gaW9jdGxz LCBzbywgdGhhbmsgeW91IGZvciB0aGF0IGluZm9ybWF0aW9uLiBZb3VyIGxpbmUgYWJvdXQgIk90 aGVyDQo+ID4gb3BlcmF0aW5nIHN5c3RlbXMgbWF5IGhhdmUgc2ltaWxhciBiZWhhdmlvdXIiIG1h eSBiZSBhIGxpdHRsZQ0KPiA+IHdvcnJ5aW5nIHRvIHRob3NlIHRoYXQgZG9uJ3QgdXNlIExpbnV4 IGJ1dCBwcmVzdW1hYmx5IHRoZXkgd2lsbA0KPiA+IHdlaWdoIGluIGlmIGl0IGlzIGFuIGlzc3Vl Lg0KPiA+IA0KPiA+IEkgdW5kZXJzdGFuZCB3aGF0IHlvdSd2ZSBzYWlkIGFib3V0IHRoZSBVRFAg VFRMIG9mIDEgYW5kIHlvdSd2ZQ0KPiA+IGluZGljYXRlZCBob3cgdG8gZ2V0IHRoYXQuIFRoYXQn cyBncmVhdC4NCj4gPiANCj4gPiBNeSBjb25mdXNpb24gYWJvdXQgVURQIFRUTHMgYXJvc2UgYmVj YXVzZSB0aGUgcGFyYWdyYXBoOg0KPiA+IA0KPiA+IMKgwqDCoMKgwqDCoMKgwqDCoMKgVG8gZW5m b3JjZSB0aGUgc2luZ2xlIExheWVyIDIgZG9tYWluLCBpbXBsZW1lbnRhdGlvbnMNCj4gPiBNVVNU IHN1cHBvcnQgdGhlIEdlbmVyYWxpemVkIFRUTCBTZWN1cml0eSBNZWNoYW5pc20gW1JGQzUwODJd Lg0KPiA+IA0KPiA+IG1ha2VzIGEgYmxhbmtldCBzdGF0ZW1lbnQgd2l0aG91dCBjb25zdHJhaW50 IHRvIFVEUCBvciBUQ1AuIEkgd291bGQNCj4gPiBub3JtYWxseSBpbnRlcnByZXQgaXQgYXMgYXBw bHlpbmcgdG8gYWxsIGRhdGEgZXhjaGFuZ2VzIHNpbmNlIHRoZQ0KPiA+IFJGQyBjYW4gYXBwbHkg dG8gYm90aCBUQ1AgYW5kIFVEUC4NCj4gPiANCj4gPiBJdCBtYXkgY2xlYXJlciBpZjoNCj4gPiAN Cj4gPiDCoMKgwqBETEVQIE1VU1QgYmUgaW1wbGVtZW50ZWQgb24gYSBzaW5nbGUgTGF5ZXIgMiBk b21haW4uwqDCoFRoZQ0KPiA+IHByb3RvY29sDQo+ID4gwqDCoMKgaWRlbnRpZmllcyBuZXh0LWhv cCBkZXN0aW5hdGlvbnMgYnkgdXNpbmcgdGhlIE1BQyBhZGRyZXNzIGZvcg0KPiA+IMKgwqDCoGRl bGl2ZXJpbmcgZGF0YSB0cmFmZmljLsKgwqBObyBtYW5pcHVsYXRpb24gb3Igc3Vic3RpdHV0aW9u IGlzDQo+ID4gwqDCoMKgcGVyZm9ybWVkOyB0aGUgTUFDIGFkZHJlc3Mgc3VwcGxpZWQgaW4gYWxs IERMRVAgTWVzc2FnZXMgaXMgdXNlZA0KPiA+IGFzDQo+ID4gwqDCoMKgdGhlIERlc3RpbmF0aW9u IE1BQyBhZGRyZXNzIGZvciBmcmFtZXMgZW1pdHRlZCBieSB0aGUNCj4gPiBwYXJ0aWNpcGF0aW5n DQo+ID4gwqDCoMKgcm91dGVyLsKgwqBNQUMgYWRkcmVzc2VzIE1VU1QgYmUgdW5pcXVlIHdpdGhp biB0aGUgY29udGV4dCBvZg0KPiA+IHJvdXRlci0NCj4gPiDCoMKgwqBtb2RlbSBzZXNzaW9uLg0K PiA+IA0KPiA+IMKgwqDCoFRvIGVuZm9yY2UgdGhlIHNpbmdsZSBMYXllciAyIGRvbWFpbiwgaW1w bGVtZW50YXRpb25zIE1VU1QNCj4gPiBzdXBwb3J0DQo+ID4gwqDCoMKgVGhlIEdlbmVyYWxpemVk IFRUTCBTZWN1cml0eSBNZWNoYW5pc20gW1JGQzUwODJdLg0KPiA+IA0KPiA+IMKgwqDCoERMRVAg c3BlY2lmaWVzIFVEUCBtdWx0aWNhc3QgZm9yIHNpbmdsZS1ob3AgZGlzY292ZXJ5IHNpZ25hbGlu ZywNCj4gPiBhbmQNCj4gPiDCoMKgwqBUQ1AgZm9yIHRyYW5zcG9ydCBvZiB0aGUgTWVzc2FnZXMu wqDCoE1vZGVtcyBhbmQgcm91dGVycw0KPiA+IHBhcnRpY2lwYXRpbmcNCj4gPiDCoMKgwqBpbiBE TEVQIHNlc3Npb25zIE1VU1QgaGF2ZSB0b3BvbG9naWNhbGx5IGNvbnNpc3RlbnQgSVAgYWRkcmVz c2VzDQo+ID4gwqDCoMKgYXNzaWduZWQuwqDCoEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgRExFUCBp bXBsZW1lbnRhdGlvbnMgdXRpbGl6ZQ0KPiA+IElQdjYNCj4gPiDCoMKgwqBsaW5rLWxvY2FsIGFk ZHJlc3NlcyB0byByZWR1Y2UgdGhlIGFkbWluaXN0cmF0aXZlIGJ1cmRlbiBvZg0KPiA+IGFkZHJl c3MNCj4gPiDCoMKgwqBhc3NpZ25tZW50LsKgwqBJbXBsZW1lbnRhdGlvbnMgTVVTVCBhZGhlcmUg dG8gdGhlIHByb2NlZHVyZQ0KPiA+IGRvY3VtZW50ZWQNCj4gPiDCoMKgwqBpbiBbUkZDNTA4Ml0g Zm9yIGFsbCBETEVQIE1lc3NhZ2VzIChUQ1AgdHJhZmZpYykuDQo+ID4gDQo+ID4gwqDCoMKgSW4g b3JkZXIgdG8ga2VlcCB0aGUgRExFUCBkaXNjb3ZlcnkgU2lnbmFscywgd2hpY2ggYXJlIG11bHRp Y2FzdA0KPiA+IFVEUC0NCj4gPiDCoMKgwqBiYXNlZCwgbGltaXRlZCB0byB0aGUgc2FtZSBMYXll ciAyIGRvbWFpbiwgaW1wbGVtZW50YXRpb25zIE1VU1QNCj4gPiBzZXQNCj4gPiDCoMKgwqB0aGUg VFRMIG9mIGFsbCBETEVQIFNpZ25hbHMgdG8gMSwgYW5kIE1VU1QgY2hlY2sgZm9yIFRUTCA9IDEg b24NCj4gPiDCoMKgwqByZWNlaXB0IG9mIERMRVAgU2lnbmFscy7CoMKgQW55IHNpZ25hbCByZWNl aXZlZCB3aXRoIGEgVFRMIG5vdA0KPiA+IGVxdWFsIHRvDQo+ID4gwqDCoMKgMSBNVVNUIGJlIGRp c2NhcmRlZC4NCj4gPiANCj4gPiB3YXMgcmVwbGFjZWQgd2l0aCBzb21ldGhpbmcgbGlrZToNCj4g PiANCj4gPiDCoMKgwqBETEVQIE1VU1QgYmUgaW1wbGVtZW50ZWQgb24gYSBzaW5nbGUgTGF5ZXIg MiBkb21haW4uwqDCoFRoZQ0KPiA+IHByb3RvY29sDQo+ID4gwqDCoMKgaWRlbnRpZmllcyBuZXh0 LWhvcCBkZXN0aW5hdGlvbnMgYnkgdXNpbmcgdGhlIE1BQyBhZGRyZXNzIGZvcg0KPiA+IMKgwqDC oGRlbGl2ZXJpbmcgZGF0YSB0cmFmZmljLsKgwqBObyBtYW5pcHVsYXRpb24gb3Igc3Vic3RpdHV0 aW9uIGlzDQo+ID4gwqDCoMKgcGVyZm9ybWVkOyB0aGUgTUFDIGFkZHJlc3Mgc3VwcGxpZWQgaW4g YWxsIERMRVAgTWVzc2FnZXMgaXMgdXNlZA0KPiA+IGFzDQo+ID4gwqDCoMKgdGhlIERlc3RpbmF0 aW9uIE1BQyBhZGRyZXNzIGZvciBmcmFtZXMgZW1pdHRlZCBieSB0aGUNCj4gPiBwYXJ0aWNpcGF0 aW5nDQo+ID4gwqDCoMKgcm91dGVyLsKgwqBNQUMgYWRkcmVzc2VzIE1VU1QgYmUgdW5pcXVlIHdp dGhpbiB0aGUgY29udGV4dCBvZg0KPiA+IHJvdXRlci0NCj4gPiDCoMKgwqBtb2RlbSBzZXNzaW9u Lg0KPiA+IA0KPiA+IMKgwqDCoERMRVAgc3BlY2lmaWVzIFVEUCBtdWx0aWNhc3QgZm9yIHNpbmds ZS1ob3AgZGlzY292ZXJ5IHNpZ25hbGluZywNCj4gPiBhbmQNCj4gPiDCoMKgwqBUQ1AgZm9yIHRy YW5zcG9ydCBvZiB0aGUgTWVzc2FnZXMuwqDCoE1vZGVtcyBhbmQgcm91dGVycw0KPiA+IHBhcnRp Y2lwYXRpbmcNCj4gPiDCoMKgwqBpbiBETEVQIHNlc3Npb25zIE1VU1QgaGF2ZSB0b3BvbG9naWNh bGx5IGNvbnNpc3RlbnQgSVAgYWRkcmVzc2VzDQo+ID4gwqDCoMKgYXNzaWduZWQuwqDCoEl0IGlz IFJFQ09NTUVOREVEIHRoYXQgRExFUCBpbXBsZW1lbnRhdGlvbnMgdXRpbGl6ZQ0KPiA+IElQdjYN Cj4gPiDCoMKgwqBsaW5rLWxvY2FsIGFkZHJlc3NlcyB0byByZWR1Y2UgdGhlIGFkbWluaXN0cmF0 aXZlIGJ1cmRlbiBvZg0KPiA+IGFkZHJlc3MNCj4gPiDCoMKgwqBhc3NpZ25tZW50Lg0KPiA+IA0K PiA+IMKgwqDCoFRvIGVuZm9yY2UgdGhlIHNpbmdsZSBMYXllciAyIGRvbWFpbiBmb3IgRExFUCBN ZXNzYWdlcyAoVENQDQo+ID4gdHJhZmZpYyksDQo+ID4gwqDCoMKgaW1wbGVtZW50YXRpb25zIE1V U1QgYWRoZXJlIHRvIHRoZSBHZW5lcmFsaXplZCBUVEwgU2VjdXJpdHkNCj4gPiBNZWNoYW5pc20N Cj4gPiDCoMKgwqBkb2N1bWVudGVkIGluIFtSRkM1MDgyXSBmb3IgYWxsIERMRVAgTWVzc2FnZXMu DQo+ID4gDQo+ID4gwqDCoMKgSW4gb3JkZXIgdG8ga2VlcCB0aGUgRExFUCBkaXNjb3ZlcnkgU2ln bmFscywgd2hpY2ggYXJlIG11bHRpY2FzdA0KPiA+IFVEUC0NCj4gPiDCoMKgwqBiYXNlZCwgbGlt aXRlZCB0byB0aGUgc2FtZSBMYXllciAyIGRvbWFpbiwgaW1wbGVtZW50YXRpb25zIE1VU1QNCj4g PiBzZXQNCj4gPiDCoMKgwqB0aGUgVFRMIG9mIGFsbCBETEVQIFNpZ25hbHMgdG8gMSwgYW5kIE1V U1QgY2hlY2sgZm9yIFRUTCA9IDEgb24NCj4gPiDCoMKgwqByZWNlaXB0IG9mIERMRVAgU2lnbmFs cy7CoMKgQW55IHNpZ25hbCByZWNlaXZlZCB3aXRoIGEgVFRMIG5vdA0KPiA+IGVxdWFsIHRvDQo+ ID4gwqDCoMKgMSBNVVNUIGJlIGRpc2NhcmRlZC4NCj4gPiANCj4gPiBDaGVlcnMsDQo+ID4gTmVp bA0KPiA+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogUmljayBU YXlsb3IgW21haWx0bzpyaWNrQHRyb3BpY2Fsc3Rvcm1zb2Z0d2FyZS5jb21dDQo+ID4gU2VudDog VHVlc2RheSwgSnVseSAxOSwgMjAxNiAzOjU2IFBNDQo+ID4gVG86IG1hbmV0QGlldGYub3JnOyBW aWJlcmcsIE5laWwNCj4gPiBTdWJqZWN0OiBSZTogW21hbmV0XSBETEVQLTIzIGFkZGl0aW9uIG9m IFJGQyA1MDgyIHJlcXVpcmVtZW50DQo+ID4gDQo+ID4gT24gVHVlLCAyMDE2LTA3LTE5IGF0IDIx OjIzICswMDAwLCBWaWJlcmcsIE5laWwgd3JvdGU6DQo+ID4gPiANCj4gPiA+IEZvbGtzLA0KPiA+ IEhpIE5laWwsDQo+ID4gDQo+ID4gQ29tbWVudHMgaW5saW5lLi4uDQo+ID4gDQo+ID4gPiANCj4g PiA+IA0KPiA+ID4gSeKAmW0gY29uZnVzZWQgYW5kIEnigJltIGhvcGluZyBzb21lb25lIGNhbiBo ZWxwIG1lIG91dC4NCj4gPiA+IA0KPiA+ID4gMS7CoMKgwqDCoMKgwqDCoFRoZSB1cGRhdGUgaW5j bHVkZXMgYSByZXF1aXJlbWVudCB0byBpbXBsZW1lbnQgUkZDIDUwODINCj4gPiA+IGFuZA0KPiA+ ID4gdGhlbiBpbmRpY2F0ZXMgdGhhdCBVRFAtYmFzZWQgc2lnbmFscyBzaGFsbCBoYXZlIGEgVFRM IG9mIDEuIFJGQw0KPiA+ID4gNTA4Mg0KPiA+ID4gbmV2ZXIgdGFsa3MgYWJvdXQgYSBUVEwgb2Yg MSwgaXQgb25seSByZWZlcnMgdG8gYSBUVEwgb2YgMjU1Lg0KPiA+ID4gU2VlbXMNCj4gPiA+IHRo YXQgYmVpbmcgY29tcGxpYW50IHdpdGggRExFUCBhbmQgUkZDIDUwODIgYXQgdGhlIHNhbWUgdGlt ZSB3aWxsDQo+ID4gPiBiZQ0KPiA+ID4gZGlmZmljdWx0LiBJbiBhZGRpdGlvbiwgdGhlIG9ubHkg d2F5IHRvIHNlZSB0aGUgVFRMIGZyb20gYSBzb2NrZXQNCj4gPiA+IGNhbGwNCj4gPiA+IGlzIHRv IHVzZSByYXcgc29ja2V0cyBBRkFJSy4gSXMgdGhhdCB0aGUgY29ycmVjdD8gSXMgdGhhdCB0aGUN Cj4gPiA+IGludGVudD8NCj4gPiBUaGF0IGlzIHRoZSBpbnRlbnQuwqDCoFVzaW5nIFVEUCBUVEwg b2YgMSBpcyB0byBwcmV2ZW50IG11bHRpaG9wDQo+ID4gZGlzY292ZXJ5IG1lc3NhZ2VzIGZyb20g ZXZlbiByZWFjaGluZyB0aGUgbW9kZW0uwqDCoFdvcmtpbmcgaXQNCj4gPiB0aHJvdWdoLCBpdCB3 b3VsZCBiZSBwb3NzaWJsZSBmb3IgYSAnYmFkJyBpbXBsZW1lbnRhdGlvbiB0byBmb3JjZQ0KPiA+ IGRpc2NvdmVyeSBtZXNzYWdlcyB0byB0cmF2ZXJzZSBtdWx0aXBsZSBob3BzLCB3aXRoIHRoZSBy ZWNlaXZlcg0KPiA+IHNlZWluZyBhIFRUTCBvZiAxLCBidXQgdGhhdCBpcyBjYXVnaHQgYnkgdGhl IFRUTCAyNTUgcmVxdWlyZW1lbnQgb24NCj4gPiB0aGUgY29ubmVjdGlvbi4NCj4gPiANCj4gPiBB IHdlbGwtYmVoYXZlZCBpbXBsZW1lbnRhdGlvbiB3aWxsIHNldCBhIFRUTCBvZiAxIHByZXZlbnRp bmcNCj4gPiB1bm5lY2Vzc2FyeSByb3V0aW5nIG9mIHBhY2tldHMgZXZlbiBpZiB1c2luZyBhIG5v bi1saW5rLWxvY2FsDQo+ID4gYWRkcmVzcy4NCj4gPiANCj4gPiBUaGlzIGlzIG5vdCBSRkMgNTA4 MiBiZWhhdmlvdXIgYnV0IGEgbWVjaGFuaXNtIHRvIHByZXZlbnQgbXVsdGktaG9wIA0KPiA+IGRp c2NvdmVyeS4NCj4gPiANCj4gPiBVc2luZyBUVEwgMjU1IGZvciB0aGUgVENQIGNvbm5lY3Rpb24g aXMgdG8gZGV0ZWN0IGFuZCBndWFyYW50ZWUNCj4gPiB0aGF0IHRoZSBUQ1AgcGVlciBpcyBvbmx5 IG9uZSBob3AgYXdheSwgYXMgZGVmaW5lZCBieSBSRkMgNTA4Mi4NCj4gPiANCj4gPiA+IA0KPiA+ ID4gDQo+ID4gPiAyLsKgwqDCoMKgwqDCoMKgRExFUC0yMyByZXF1aXJlcyB0aGF0IGFsbCBtZXNz YWdlcyBoYXZlIGEgVFRMIG9mIDI1NS4NCj4gPiA+IFRoZQ0KPiA+ID4gcHJvYmxlbSBpcyB0aGF0 IGEgRExFUCBtZXNzYWdlIGlzIGEgbG9naWNhbCBjb25zdHJ1Y3Rpb24gcmVjZWl2ZWQNCj4gPiA+ IG92ZXINCj4gPiA+IGEgVENQIGJ5dGUgc3RyZWFtIGFuZCB0aGUgYnl0ZSBzdHJlYW0gZG9lc27i gJl0IGluaGVyZW50bHkgaGF2ZSBhDQo+ID4gPiBUVEwuDQo+ID4gPiBIb3cgZG9lcyB0aGF0IHdv cms/IFJGQyA1MDgyIHNlZW1zIG1vcmUgbG9naWNhbCwgYWxsIHBhY2tldHMNCj4gPiA+IHJlY2Vp dmVkDQo+ID4gPiBhcyBwYXJ0IG9mIHRoZSBUQ1Agc2Vzc2lvbiBtdXN0IGhhdmUgYSBUVEwgb2Yg MjU1LiBUaGF0IGlzIGNsZWFyLg0KPiA+ID4gSG93DQo+ID4gPiBkb2VzIGEgcHJvZ3JhbW1lciwg dXNpbmcgc29ja2V0cywgZGV0ZXJtaW5lIHRoYXQgZWFjaCBvZiB0aGUgVENQDQo+ID4gPiBwYWNr ZXRzIGhhcyBhIFRUTCBvZiAyNTU/IFRoZXJlIGRvZXNu4oCZdCBhcHBlYXIgdG8gYmUgYW55IHNv Y2tvcHRzDQo+ID4gPiB0aGF0DQo+ID4gPiBjYW4gc2V0IHRoYXQgcmVxdWlyZW1lbnQgYW5kIEkg ZG91YnQgbWFueSBwZW9wbGUgYXJlIGdvaW5nIHRvDQo+ID4gPiB3cml0ZQ0KPiA+ID4gdGhlaXIg b3duIFRDUCBzdGFjayBvciBtYW5nbGUgYW4gZXhpc3Rpbmcgb25lIHRvIGdldCB0aGF0IGRvbmUu DQo+ID4gPiBBZ2FpbiwNCj4gPiA+IGhvdyBpcyB0aGF0IHN1cHBvc2VkIHRvIHdvcms/DQo+ID4g SSBrbm93IGEgcmVhc29uYWJseSBtb2Rlcm4gTGludXggaGFzIGEgdXNlci1tb2RlIHNvY2tldCBp b2N0bA0KPiA+IChJUF9NSU5UVEwgLSBodHRwczovL2x3bi5uZXQvQXJ0aWNsZXMvMzc5MDcwLykg dG8gcmVzdHJpY3QgdGhlIFRUTA0KPiA+IG9uIGEgc29ja2V0LCBhbmQgaW9jdGwoSVBfVFRMKSBj YW4gYmUgdXNlZCB3aXRoIFVEUCB0byBnZXQgdGhlDQo+ID4gZGF0YWdyYW0gVFRMLg0KPiA+IMKg T3RoZXIgb3BlcmF0aW5nIHN5c3RlbXMgbWF5IGhhdmUgc2ltaWxhciBiZWhhdmlvdXIuDQo+ID4g DQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gSG9wZWZ1bGx5IEnigJltIG1pc3Npbmcgc29tZXRoaW5n IGJlY2F1c2UgdGhlIGludGVudCBvZiB0aGUNCj4gPiA+IHJlcXVpcmVtZW50DQo+ID4gPiBpcyBj bGVhciBhbmQgbGF1ZGFibGUgYnV0IHRoZSBwcmFjdGljYWxpdHkgb2YgaXQgc2VlbXMgc3VzcGVj dC4NCj4gPiBUaGUgaW50ZW50IGlzIHRvIGVuZm9yY2UgdGhlIHNpbmdsZSBsYXllci0yIGNvbm5l Y3Rpdml0eQ0KPiA+IHJlcXVpcmVtZW50LA0KPiA+IHByZXZlbnRpbmc6IGEpIFRoZSBkaXNjb3Zl cnkgb2YgbW9kZW1zIG1vcmUgdGhhbiAxIGhvcCBhd2F5LCBhbmQgYikNCj4gPiBlc3RhYmxpc2hp bmcgYSBUQ1AgY29ubmVjdGlvbiB0byBhIG1vZGVtIG1vcmUgdGhhbiAxIGhvcCBhd2F5Lg0KPiA+ IA0KPiA+IEhvcGUgdGhhdCBoZWxwcywNCj4gPiANCj4gPiBSaWNrDQo+ID4gDQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtYW5ldCBtYWls aW5nIGxpc3QNCj4gPiBtYW5ldEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWFuZXQ= From nobody Wed Jul 20 03:20:07 2016 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 1CEC112D0B9 for ; Wed, 20 Jul 2016 03:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOWtxeXGDf-e for ; Wed, 20 Jul 2016 03:20:02 -0700 (PDT) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FC012D0A5 for ; Wed, 20 Jul 2016 03:20:01 -0700 (PDT) Received: by mail-qk0-x241.google.com with SMTP id p126so3623941qke.1 for ; Wed, 20 Jul 2016 03:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N8LzUPm+e1KkDzUZB+szTDJ42CSNoKqkntr2GCyZh+I=; b=gh84i+06bOFSMYOLj9UdzuJZ9iMRHDUXI1EpW4eL9rdNPeROOGEID/lykCllF6ENmY knvJAUKl9g4xVSNjoEma+ZVANpLeHDFRuplnR2ofgqQpEtDbuYgpKzA85ggtT8DBZz4G NBocGAM01eJg/IUpFz6mwKhsTf/UMlrmeKepwSKc57WdJzDnzd5roub4NQ3mNlyigqwV iv/S1XNfer0ie2qVjAefU0VSaHsm8M7xe+lmW7v4QTxPqqV2gXMgoEp5wYitmHmlCfhf x5tPL+v89RfX4f2VvjK2VbGzDliNdbQfDg0tEoA6fsvw4YNYcmx93tp4sRUWiccsTRbT 6h2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N8LzUPm+e1KkDzUZB+szTDJ42CSNoKqkntr2GCyZh+I=; b=JavupzuGQx1GdgeAd3mYVAcDYEC4rc73zLT0irWy1qWyWwV6T6l5CERFE0LJkcOwBr C2duyDZ8e/3nrgObGHH7395lcafMXqREap1LkehX7CuXubloTbZ/SefcTotpy+OZGD/e RAZy/vaJEK7mnvdny/j59LRY9LkiW/oodVG2aEMB4Ew3WS2n25dvlj1LDr/kIGaXuWf6 cyBbLtlicd1DgcGZ9d8bzlB5D3+JhWmSpBSvkEbNDrZE+jqL/5fqGZZNZlYRVMWTg494 EeXL/IX36tMsZfN1pD4bu9m/iapC1qVmsVL7H3fnvSrgFTP0kwvf+LZYZWglTu0VbECY aVyQ== X-Gm-Message-State: ALyK8tJFrT4g9+epR/cw82e8N6xD7u9I2PcaEWOVIjQrOAO7Hdq5ab6h1oS7Dt7BucpBuuWMwdaD6n2qrxFV4Q== X-Received: by 10.55.22.30 with SMTP id g30mr57846452qkh.29.1469010000884; Wed, 20 Jul 2016 03:20:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.46.102 with HTTP; Wed, 20 Jul 2016 03:19:31 -0700 (PDT) In-Reply-To: <1469002542.28151.3.camel@tropicalstormsoftware.com> References: <4380A22D88B79C47883D0026E2CD55148C1194F6@ottsvw202.gdcan.com> <1468965376.8956.77.camel@tropicalstormsoftware.com> <4380A22D88B79C47883D0026E2CD55148C11954D@ottsvw202.gdcan.com> <1469002542.28151.3.camel@tropicalstormsoftware.com> From: Henning Rogge Date: Wed, 20 Jul 2016 12:19:31 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "manet@ietf.org" , "Neil.Viberg@gd-ms.ca" Subject: Re: [manet] DLEP-23 addition of RFC 5082 requirement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 10:20:04 -0000 On Wed, Jul 20, 2016 at 10:15 AM, Rick Taylor wrote: > Henning, > > For TCP sockets: IP_MINTTL not IP_RECVTTL. Unfortunately IP_MINTTL > does not seem to have made it into the man ip(7) info. It was designed > to solve the problem for BGP implementations, and definitely works for > TCP: see https://lwn.net/Articles/379070/ *reading the article* > I believe the IP_MINTTL idea came from (Free?)BSD, so BSD's most likely > have it. It seems Linux never implemented IPV6_MINHOPLIMIT, which means we cannot use this strategy for IPv6. I checked the current "linux stable" tree. Henning From nobody Fri Jul 22 16:17:16 2016 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 0E6ED12E16D; Fri, 22 Jul 2016 16:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5KN-ahBNsh7; Fri, 22 Jul 2016 16:17:12 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8AD512E16C; Fri, 22 Jul 2016 16:17:11 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u6MNH981008973; Sat, 23 Jul 2016 01:17:09 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C74A661F9D; Sat, 23 Jul 2016 01:17:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id UXqL42TuGLCy; Sat, 23 Jul 2016 01:17:08 +0200 (CEST) Received: from ijon.pps.univ-paris-diderot.fr (unknown [80.156.72.98]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8164561FA2; Sat, 23 Jul 2016 01:17:06 +0200 (CEST) Date: Sat, 23 Jul 2016 01:17:13 +0200 Message-ID: <87r3al5kli.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: manet@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 23 Jul 2016 01:17:09 +0200 (CEST) X-Miltered: at korolev with ID 5792A975.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5792A975.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5792A975.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: homenet@ietf.org Subject: [manet] Manet address assignment X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 23:17:14 -0000 This message is being sent to the manet mailing list, with homenet in CC. I took to the microphone during this week's manet meeting to remind people that Homenet has designed HNCP (RFC 7788), a protocol for autonomous configuration of multilink home networks, and that it would be a terrible missed opportunity if a protocol for manet autoconfiguration were standardised that did not interoperate with HNCP. We at Babel Towers are currently experimenting with HNCP in a small mesh network. The results are encouraging: up to some minor bugs in the current implementation, HNCP is able to configure a (non-mobile) mesh network with no operator intervention. We are planning to spend some time working on shncpd, our implementation of HNCP, until it is able to work well in our mesh network: - change the link sensing mechanism to work better on persistently lossy links; - add the ability to configure just a single /128 on loopback (shncpd is already able to configure a /128 on each interface, which is useful for mesh networks but out-of-spec -- HNCP requires a /64). If this works out, the plan is then to implement an HNCP protocol extension that allows it to scale better in large and mobile mesh networks; this will necessarily involve some tradeoffs, such as being restricted to allocating /128. I'll let you know more when I have code to show. Note that HNCP only does address configuration and naming; it does not negotiate routing protocol parameters nor provide monitoring facilities. Thus, it is not a complete solution for a MANET management protocol, and I believe it does not conflict with the management work being done within MANET. Regards, -- Juliusz From nobody Sat Jul 23 01:22:19 2016 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 3EE4212D115 for ; Sat, 23 Jul 2016 01:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2XkjsI4cLJb for ; Sat, 23 Jul 2016 01:22:15 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CA112B01B for ; Sat, 23 Jul 2016 01:22:14 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Sat, 23 Jul 2016 09:21:29 +0100 From: Rick Taylor To: Henning Rogge , "Viberg, Neil" Thread-Topic: [manet] DLEP-23 addition of RFC 5082 requirement Thread-Index: AQHR4kq6exn2Yvso7UqCg9f7HEYlKaAlr0uQ Date: Sat, 23 Jul 2016 08:21:27 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801C3AA5BBE@tss-server1.home.tropicalstormsoftware.com> References: <4380A22D88B79C47883D0026E2CD55148C1194F6@ottsvw202.gdcan.com> <1468965376.8956.77.camel@tropicalstormsoftware.com> <4380A22D88B79C47883D0026E2CD55148C11954D@ottsvw202.gdcan.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-23 addition of RFC 5082 requirement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 08:22:18 -0000 QWxsLA0KDQpUaGVyZSB3aWxsIGJlIGFuIHVwZGF0ZSB0byBETEVQIHRvIGluY2x1ZGUgTmVpbOKA mXMgc3VnZ2VzdGVkIHRleHQsIHBvaW50aW5nIG91dCB0aGF0IFJGQyA1MDI4IChUTEwgMjU1KSBp cyBvbmx5IGFwcGxpZWQgdG8gdGhlIFRDUCBjb25uZWN0aW9uLCBhbmQgVFRMIDEgaXMgcmVxdWly ZWQgZm9yIHRoZSBVRFAgZGlzY292ZXJ5IHBoYXNlLCB1bmxlc3MgSVB2NiBsaW5rLWxvY2FsIGFk ZHJlc3NpbmcgaXMgaW4gdXNlLg0KDQpBZnRlciBzb21lIGZ1cnRoZXIgaW52ZXN0aWdhdGlvbiwg Zm9yIHRob3NlIHVzaW5nIExpbnV4LCB0aGVyZSBhcmUgc29ja2V0IG9wdGlvbnMgKHNldHNvY2tv cHQpIGZvciBib3RoIElQdjQgYW5kIElQdjYgbm9uLXJvb3QgdXNlci1tb2RlIHNvY2tldHMgdG8g aGFuZGxlIGFsbCB0aGVzZSBjYXNlczoNCg0KSVBfUkVDVlRUTCAtIFRvIGNoZWNrIHRoZSBUVEwg PT0gMSBvbiBVRFAgcGFja2V0cy4NCklQX01JTlRUTCAtIFRvIGVuZm9yY2UgdGhlIFRUTCA9PSAy NTUgb24gVENQL0lQdjQgc29ja2V0cy4NCklQVjZfTUlOSE9QQ09VTlQgLSBUbyBlbmZvcmNlIHRo ZSBUVEwgPT0gMjU1IG9uIFRDUC9JUHY2IHNvY2tldHMuDQoNCkhvcGVmdWxseSwgdGhlc2UgY2hh bmdlcyBhbmQgdGhpcyBjcm9zcyByZWZlcmVuY2Ugc2hvdWxkIGhlbHAuDQoNClJlZ2FyZHMsDQoN ClJpY2sNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIZW5uaW5nIFJv Z2dlIFttYWlsdG86aHJvZ2dlQGdtYWlsLmNvbV0gDQpTZW50OiAyMCBKdWx5IDIwMTYgMDY6NTEN ClRvOiBWaWJlcmcsIE5laWwNCkNjOiBSaWNrIFRheWxvcjsgbWFuZXRAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbbWFuZXRdIERMRVAtMjMgYWRkaXRpb24gb2YgUkZDIDUwODIgcmVxdWlyZW1lbnQN Cg0KUXVvdGUgZnJvbSAibWFuIDcgaXAiOg0KDQogICAgICAgSVBfUkVDVlRUTCAoc2luY2UgTGlu dXggMi4yKQ0KICAgICAgICAgICAgIFdoZW4gdGhpcyBmbGFnIGlzIHNldCwgcGFzcyBhIElQX1RU TCBjb250cm9sIG1lc3NhZ2Ugd2l0aA0KdGhlIHRpbWUtdG8tbGl2ZSBmaWVsZCBvZiB0aGUgcmVj ZWl2ZWQgIHBhY2tldCAgYXMgIGEgIGJ5dGUuICAgTm90DQpzdXBwb3J0ZWQgIGZvcg0KICAgICAg ICAgICAgIFNPQ0tfU1RSRUFNIHNvY2tldHMuDQoNClNvIHdlIGNhbm5vdCBlYXNpbHkgY2hlY2sg dGhlIFRUTCB2YWx1ZSBvbiB0aGUgVENQIHN0cmVhbXMgKCBiZWNhdXNlIHdlIGRvbid0IHJlY2Vp dmUgdGhlbSBwZXIgcGFja2V0KS4NCg0KRG9pbmcgY3JhenkgdGhpbmdzIHdpdGggdGhlIFRUTCBp cyB1bm5lY2Vzc2FyeSBhbnl3YXlzIGlmIHlvdSBzdGljayB3aXRoIGxpbmtsb2NhbCBhZGRyZXNz ZXMuIElmIHRoZXkgZ2V0IGZvcndhcmRlZCwgeW91ciBpbnRlcm1lZGlhdGUgcm91dGVycyBhcmUg ZGVmZWN0Lg0KDQpIZW5uaW5nDQoNCg0KDQpPbiBXZWQsIEp1bCAyMCwgMjAxNiBhdCAxOjU5IEFN LCBWaWJlcmcsIE5laWwgPE5laWwuVmliZXJnQGdkLW1zLmNhPiB3cm90ZToNCj4gVGhhbmtzIFJp Y2ssDQo+DQo+IEkgdW5kZXJzdG9vZCB0aGUgcHVycG9zZSBvZiB0aGUgcmVxdWlyZW1lbnRzIGFu ZCBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIHRoZSBpbnRlbnQgb2YgaXQgYWxsLg0KPg0KPiBZb3Un dmUgY2xlYXJlZCB1cCBteSBxdWVzdGlvbiBvbiBUQ1AuIEkgd2FzIGxvb2tpbmcgYXQgc29ja29w dHMgbm90IGlvY3Rscywgc28sIHRoYW5rIHlvdSBmb3IgdGhhdCBpbmZvcm1hdGlvbi4gWW91ciBs aW5lIGFib3V0ICJPdGhlciBvcGVyYXRpbmcgc3lzdGVtcyBtYXkgaGF2ZSBzaW1pbGFyIGJlaGF2 aW91ciIgbWF5IGJlIGEgbGl0dGxlIHdvcnJ5aW5nIHRvIHRob3NlIHRoYXQgZG9uJ3QgdXNlIExp bnV4IGJ1dCBwcmVzdW1hYmx5IHRoZXkgd2lsbCB3ZWlnaCBpbiBpZiBpdCBpcyBhbiBpc3N1ZS4N Cj4NCj4gSSB1bmRlcnN0YW5kIHdoYXQgeW91J3ZlIHNhaWQgYWJvdXQgdGhlIFVEUCBUVEwgb2Yg MSBhbmQgeW91J3ZlIGluZGljYXRlZCBob3cgdG8gZ2V0IHRoYXQuIFRoYXQncyBncmVhdC4NCj4N Cj4gTXkgY29uZnVzaW9uIGFib3V0IFVEUCBUVExzIGFyb3NlIGJlY2F1c2UgdGhlIHBhcmFncmFw aDoNCj4NCj4gICAgICAgICAgIFRvIGVuZm9yY2UgdGhlIHNpbmdsZSBMYXllciAyIGRvbWFpbiwg aW1wbGVtZW50YXRpb25zIE1VU1Qgc3VwcG9ydCB0aGUgR2VuZXJhbGl6ZWQgVFRMIFNlY3VyaXR5 IE1lY2hhbmlzbSBbUkZDNTA4Ml0uDQo+DQo+IG1ha2VzIGEgYmxhbmtldCBzdGF0ZW1lbnQgd2l0 aG91dCBjb25zdHJhaW50IHRvIFVEUCBvciBUQ1AuIEkgd291bGQgbm9ybWFsbHkgaW50ZXJwcmV0 IGl0IGFzIGFwcGx5aW5nIHRvIGFsbCBkYXRhIGV4Y2hhbmdlcyBzaW5jZSB0aGUgUkZDIGNhbiBh cHBseSB0byBib3RoIFRDUCBhbmQgVURQLg0KPg0KPiBJdCBtYXkgY2xlYXJlciBpZjoNCj4NCj4g ICAgRExFUCBNVVNUIGJlIGltcGxlbWVudGVkIG9uIGEgc2luZ2xlIExheWVyIDIgZG9tYWluLiAg VGhlIHByb3RvY29sDQo+ICAgIGlkZW50aWZpZXMgbmV4dC1ob3AgZGVzdGluYXRpb25zIGJ5IHVz aW5nIHRoZSBNQUMgYWRkcmVzcyBmb3INCj4gICAgZGVsaXZlcmluZyBkYXRhIHRyYWZmaWMuICBO byBtYW5pcHVsYXRpb24gb3Igc3Vic3RpdHV0aW9uIGlzDQo+ICAgIHBlcmZvcm1lZDsgdGhlIE1B QyBhZGRyZXNzIHN1cHBsaWVkIGluIGFsbCBETEVQIE1lc3NhZ2VzIGlzIHVzZWQgYXMNCj4gICAg dGhlIERlc3RpbmF0aW9uIE1BQyBhZGRyZXNzIGZvciBmcmFtZXMgZW1pdHRlZCBieSB0aGUgcGFy dGljaXBhdGluZw0KPiAgICByb3V0ZXIuICBNQUMgYWRkcmVzc2VzIE1VU1QgYmUgdW5pcXVlIHdp dGhpbiB0aGUgY29udGV4dCBvZiByb3V0ZXItDQo+ICAgIG1vZGVtIHNlc3Npb24uDQo+DQo+ICAg IFRvIGVuZm9yY2UgdGhlIHNpbmdsZSBMYXllciAyIGRvbWFpbiwgaW1wbGVtZW50YXRpb25zIE1V U1Qgc3VwcG9ydA0KPiAgICBUaGUgR2VuZXJhbGl6ZWQgVFRMIFNlY3VyaXR5IE1lY2hhbmlzbSBb UkZDNTA4Ml0uDQo+DQo+ICAgIERMRVAgc3BlY2lmaWVzIFVEUCBtdWx0aWNhc3QgZm9yIHNpbmds ZS1ob3AgZGlzY292ZXJ5IHNpZ25hbGluZywgYW5kDQo+ICAgIFRDUCBmb3IgdHJhbnNwb3J0IG9m IHRoZSBNZXNzYWdlcy4gIE1vZGVtcyBhbmQgcm91dGVycyBwYXJ0aWNpcGF0aW5nDQo+ICAgIGlu IERMRVAgc2Vzc2lvbnMgTVVTVCBoYXZlIHRvcG9sb2dpY2FsbHkgY29uc2lzdGVudCBJUCBhZGRy ZXNzZXMNCj4gICAgYXNzaWduZWQuICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IERMRVAgaW1wbGVt ZW50YXRpb25zIHV0aWxpemUgSVB2Ng0KPiAgICBsaW5rLWxvY2FsIGFkZHJlc3NlcyB0byByZWR1 Y2UgdGhlIGFkbWluaXN0cmF0aXZlIGJ1cmRlbiBvZiBhZGRyZXNzDQo+ICAgIGFzc2lnbm1lbnQu ICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBhZGhlcmUgdG8gdGhlIHByb2NlZHVyZSBkb2N1bWVudGVk DQo+ICAgIGluIFtSRkM1MDgyXSBmb3IgYWxsIERMRVAgTWVzc2FnZXMgKFRDUCB0cmFmZmljKS4N Cj4NCj4gICAgSW4gb3JkZXIgdG8ga2VlcCB0aGUgRExFUCBkaXNjb3ZlcnkgU2lnbmFscywgd2hp Y2ggYXJlIG11bHRpY2FzdCBVRFAtDQo+ICAgIGJhc2VkLCBsaW1pdGVkIHRvIHRoZSBzYW1lIExh eWVyIDIgZG9tYWluLCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzZXQNCj4gICAgdGhlIFRUTCBvZiBh bGwgRExFUCBTaWduYWxzIHRvIDEsIGFuZCBNVVNUIGNoZWNrIGZvciBUVEwgPSAxIG9uDQo+ICAg IHJlY2VpcHQgb2YgRExFUCBTaWduYWxzLiAgQW55IHNpZ25hbCByZWNlaXZlZCB3aXRoIGEgVFRM IG5vdCBlcXVhbCB0bw0KPiAgICAxIE1VU1QgYmUgZGlzY2FyZGVkLg0KPg0KPiB3YXMgcmVwbGFj ZWQgd2l0aCBzb21ldGhpbmcgbGlrZToNCj4NCj4gICAgRExFUCBNVVNUIGJlIGltcGxlbWVudGVk IG9uIGEgc2luZ2xlIExheWVyIDIgZG9tYWluLiAgVGhlIHByb3RvY29sDQo+ICAgIGlkZW50aWZp ZXMgbmV4dC1ob3AgZGVzdGluYXRpb25zIGJ5IHVzaW5nIHRoZSBNQUMgYWRkcmVzcyBmb3INCj4g ICAgZGVsaXZlcmluZyBkYXRhIHRyYWZmaWMuICBObyBtYW5pcHVsYXRpb24gb3Igc3Vic3RpdHV0 aW9uIGlzDQo+ICAgIHBlcmZvcm1lZDsgdGhlIE1BQyBhZGRyZXNzIHN1cHBsaWVkIGluIGFsbCBE TEVQIE1lc3NhZ2VzIGlzIHVzZWQgYXMNCj4gICAgdGhlIERlc3RpbmF0aW9uIE1BQyBhZGRyZXNz IGZvciBmcmFtZXMgZW1pdHRlZCBieSB0aGUgcGFydGljaXBhdGluZw0KPiAgICByb3V0ZXIuICBN QUMgYWRkcmVzc2VzIE1VU1QgYmUgdW5pcXVlIHdpdGhpbiB0aGUgY29udGV4dCBvZiByb3V0ZXIt DQo+ICAgIG1vZGVtIHNlc3Npb24uDQo+DQo+ICAgIERMRVAgc3BlY2lmaWVzIFVEUCBtdWx0aWNh c3QgZm9yIHNpbmdsZS1ob3AgZGlzY292ZXJ5IHNpZ25hbGluZywgYW5kDQo+ICAgIFRDUCBmb3Ig dHJhbnNwb3J0IG9mIHRoZSBNZXNzYWdlcy4gIE1vZGVtcyBhbmQgcm91dGVycyBwYXJ0aWNpcGF0 aW5nDQo+ICAgIGluIERMRVAgc2Vzc2lvbnMgTVVTVCBoYXZlIHRvcG9sb2dpY2FsbHkgY29uc2lz dGVudCBJUCBhZGRyZXNzZXMNCj4gICAgYXNzaWduZWQuICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0 IERMRVAgaW1wbGVtZW50YXRpb25zIHV0aWxpemUgSVB2Ng0KPiAgICBsaW5rLWxvY2FsIGFkZHJl c3NlcyB0byByZWR1Y2UgdGhlIGFkbWluaXN0cmF0aXZlIGJ1cmRlbiBvZiBhZGRyZXNzDQo+ICAg IGFzc2lnbm1lbnQuDQo+DQo+ICAgIFRvIGVuZm9yY2UgdGhlIHNpbmdsZSBMYXllciAyIGRvbWFp biBmb3IgRExFUCBNZXNzYWdlcyAoVENQIHRyYWZmaWMpLA0KPiAgICBpbXBsZW1lbnRhdGlvbnMg TVVTVCBhZGhlcmUgdG8gdGhlIEdlbmVyYWxpemVkIFRUTCBTZWN1cml0eSBNZWNoYW5pc20NCj4g ICAgZG9jdW1lbnRlZCBpbiBbUkZDNTA4Ml0gZm9yIGFsbCBETEVQIE1lc3NhZ2VzLg0KPg0KPiAg ICBJbiBvcmRlciB0byBrZWVwIHRoZSBETEVQIGRpc2NvdmVyeSBTaWduYWxzLCB3aGljaCBhcmUg bXVsdGljYXN0IFVEUC0NCj4gICAgYmFzZWQsIGxpbWl0ZWQgdG8gdGhlIHNhbWUgTGF5ZXIgMiBk b21haW4sIGltcGxlbWVudGF0aW9ucyBNVVNUIHNldA0KPiAgICB0aGUgVFRMIG9mIGFsbCBETEVQ IFNpZ25hbHMgdG8gMSwgYW5kIE1VU1QgY2hlY2sgZm9yIFRUTCA9IDEgb24NCj4gICAgcmVjZWlw dCBvZiBETEVQIFNpZ25hbHMuICBBbnkgc2lnbmFsIHJlY2VpdmVkIHdpdGggYSBUVEwgbm90IGVx dWFsIHRvDQo+ICAgIDEgTVVTVCBiZSBkaXNjYXJkZWQuDQo+DQo+IENoZWVycywNCj4gTmVpbA0K Pg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSaWNrIFRheWxvciBbbWFp bHRvOnJpY2tAdHJvcGljYWxzdG9ybXNvZnR3YXJlLmNvbV0NCj4gU2VudDogVHVlc2RheSwgSnVs eSAxOSwgMjAxNiAzOjU2IFBNDQo+IFRvOiBtYW5ldEBpZXRmLm9yZzsgVmliZXJnLCBOZWlsDQo+ IFN1YmplY3Q6IFJlOiBbbWFuZXRdIERMRVAtMjMgYWRkaXRpb24gb2YgUkZDIDUwODIgcmVxdWly ZW1lbnQNCj4NCj4gT24gVHVlLCAyMDE2LTA3LTE5IGF0IDIxOjIzICswMDAwLCBWaWJlcmcsIE5l aWwgd3JvdGU6DQo+PiBGb2xrcywNCj4NCj4gSGkgTmVpbCwNCj4NCj4gQ29tbWVudHMgaW5saW5l Li4uDQo+DQo+Pg0KPj4gSeKAmW0gY29uZnVzZWQgYW5kIEnigJltIGhvcGluZyBzb21lb25lIGNh biBoZWxwIG1lIG91dC4NCj4+DQo+PiAxLiAgICAgICBUaGUgdXBkYXRlIGluY2x1ZGVzIGEgcmVx dWlyZW1lbnQgdG8gaW1wbGVtZW50IFJGQyA1MDgyIGFuZA0KPj4gdGhlbiBpbmRpY2F0ZXMgdGhh dCBVRFAtYmFzZWQgc2lnbmFscyBzaGFsbCBoYXZlIGEgVFRMIG9mIDEuIFJGQyA1MDgyIA0KPj4g bmV2ZXIgdGFsa3MgYWJvdXQgYSBUVEwgb2YgMSwgaXQgb25seSByZWZlcnMgdG8gYSBUVEwgb2Yg MjU1LiBTZWVtcyANCj4+IHRoYXQgYmVpbmcgY29tcGxpYW50IHdpdGggRExFUCBhbmQgUkZDIDUw ODIgYXQgdGhlIHNhbWUgdGltZSB3aWxsIGJlIA0KPj4gZGlmZmljdWx0LiBJbiBhZGRpdGlvbiwg dGhlIG9ubHkgd2F5IHRvIHNlZSB0aGUgVFRMIGZyb20gYSBzb2NrZXQgDQo+PiBjYWxsIGlzIHRv IHVzZSByYXcgc29ja2V0cyBBRkFJSy4gSXMgdGhhdCB0aGUgY29ycmVjdD8gSXMgdGhhdCB0aGUg aW50ZW50Pw0KPg0KPiBUaGF0IGlzIHRoZSBpbnRlbnQuICBVc2luZyBVRFAgVFRMIG9mIDEgaXMg dG8gcHJldmVudCBtdWx0aWhvcCBkaXNjb3ZlcnkgbWVzc2FnZXMgZnJvbSBldmVuIHJlYWNoaW5n IHRoZSBtb2RlbS4gIFdvcmtpbmcgaXQgdGhyb3VnaCwgaXQgd291bGQgYmUgcG9zc2libGUgZm9y IGEgJ2JhZCcgaW1wbGVtZW50YXRpb24gdG8gZm9yY2UgZGlzY292ZXJ5IG1lc3NhZ2VzIHRvIHRy YXZlcnNlIG11bHRpcGxlIGhvcHMsIHdpdGggdGhlIHJlY2VpdmVyIHNlZWluZyBhIFRUTCBvZiAx LCBidXQgdGhhdCBpcyBjYXVnaHQgYnkgdGhlIFRUTCAyNTUgcmVxdWlyZW1lbnQgb24gdGhlIGNv bm5lY3Rpb24uDQo+DQo+IEEgd2VsbC1iZWhhdmVkIGltcGxlbWVudGF0aW9uIHdpbGwgc2V0IGEg VFRMIG9mIDEgcHJldmVudGluZyB1bm5lY2Vzc2FyeSByb3V0aW5nIG9mIHBhY2tldHMgZXZlbiBp ZiB1c2luZyBhIG5vbi1saW5rLWxvY2FsIGFkZHJlc3MuDQo+DQo+IFRoaXMgaXMgbm90IFJGQyA1 MDgyIGJlaGF2aW91ciBidXQgYSBtZWNoYW5pc20gdG8gcHJldmVudCBtdWx0aS1ob3AgZGlzY292 ZXJ5Lg0KPg0KPiBVc2luZyBUVEwgMjU1IGZvciB0aGUgVENQIGNvbm5lY3Rpb24gaXMgdG8gZGV0 ZWN0IGFuZCBndWFyYW50ZWUgdGhhdCB0aGUgVENQIHBlZXIgaXMgb25seSBvbmUgaG9wIGF3YXks IGFzIGRlZmluZWQgYnkgUkZDIDUwODIuDQo+DQo+Pg0KPj4gMi4gICAgICAgRExFUC0yMyByZXF1 aXJlcyB0aGF0IGFsbCBtZXNzYWdlcyBoYXZlIGEgVFRMIG9mIDI1NS4gVGhlDQo+PiBwcm9ibGVt IGlzIHRoYXQgYSBETEVQIG1lc3NhZ2UgaXMgYSBsb2dpY2FsIGNvbnN0cnVjdGlvbiByZWNlaXZl ZCANCj4+IG92ZXIgYSBUQ1AgYnl0ZSBzdHJlYW0gYW5kIHRoZSBieXRlIHN0cmVhbSBkb2VzbuKA mXQgaW5oZXJlbnRseSBoYXZlIGEgVFRMLg0KPj4gSG93IGRvZXMgdGhhdCB3b3JrPyBSRkMgNTA4 MiBzZWVtcyBtb3JlIGxvZ2ljYWwsIGFsbCBwYWNrZXRzIHJlY2VpdmVkIA0KPj4gYXMgcGFydCBv ZiB0aGUgVENQIHNlc3Npb24gbXVzdCBoYXZlIGEgVFRMIG9mIDI1NS4gVGhhdCBpcyBjbGVhci4g SG93IA0KPj4gZG9lcyBhIHByb2dyYW1tZXIsIHVzaW5nIHNvY2tldHMsIGRldGVybWluZSB0aGF0 IGVhY2ggb2YgdGhlIFRDUCANCj4+IHBhY2tldHMgaGFzIGEgVFRMIG9mIDI1NT8gVGhlcmUgZG9l c27igJl0IGFwcGVhciB0byBiZSBhbnkgc29ja29wdHMgDQo+PiB0aGF0IGNhbiBzZXQgdGhhdCBy ZXF1aXJlbWVudCBhbmQgSSBkb3VidCBtYW55IHBlb3BsZSBhcmUgZ29pbmcgdG8gDQo+PiB3cml0 ZSB0aGVpciBvd24gVENQIHN0YWNrIG9yIG1hbmdsZSBhbiBleGlzdGluZyBvbmUgdG8gZ2V0IHRo YXQgZG9uZS4gDQo+PiBBZ2FpbiwgaG93IGlzIHRoYXQgc3VwcG9zZWQgdG8gd29yaz8NCj4NCj4g SSBrbm93IGEgcmVhc29uYWJseSBtb2Rlcm4gTGludXggaGFzIGEgdXNlci1tb2RlIHNvY2tldCBp b2N0bCAoSVBfTUlOVFRMIC0gaHR0cHM6Ly9sd24ubmV0L0FydGljbGVzLzM3OTA3MC8pIHRvIHJl c3RyaWN0IHRoZSBUVEwgb24gYSBzb2NrZXQsIGFuZCBpb2N0bChJUF9UVEwpIGNhbiBiZSB1c2Vk IHdpdGggVURQIHRvIGdldCB0aGUgZGF0YWdyYW0gVFRMLg0KPiAgT3RoZXIgb3BlcmF0aW5nIHN5 c3RlbXMgbWF5IGhhdmUgc2ltaWxhciBiZWhhdmlvdXIuDQo+DQo+Pg0KPj4gSG9wZWZ1bGx5IEni gJltIG1pc3Npbmcgc29tZXRoaW5nIGJlY2F1c2UgdGhlIGludGVudCBvZiB0aGUgcmVxdWlyZW1l bnQgDQo+PiBpcyBjbGVhciBhbmQgbGF1ZGFibGUgYnV0IHRoZSBwcmFjdGljYWxpdHkgb2YgaXQg c2VlbXMgc3VzcGVjdC4NCj4NCj4gVGhlIGludGVudCBpcyB0byBlbmZvcmNlIHRoZSBzaW5nbGUg bGF5ZXItMiBjb25uZWN0aXZpdHkgcmVxdWlyZW1lbnQsDQo+IHByZXZlbnRpbmc6IGEpIFRoZSBk aXNjb3Zlcnkgb2YgbW9kZW1zIG1vcmUgdGhhbiAxIGhvcCBhd2F5LCBhbmQgYikgZXN0YWJsaXNo aW5nIGEgVENQIGNvbm5lY3Rpb24gdG8gYSBtb2RlbSBtb3JlIHRoYW4gMSBob3AgYXdheS4NCj4N Cj4gSG9wZSB0aGF0IGhlbHBzLA0KPg0KPiBSaWNrDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiBtYW5l dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0 DQo= From nobody Sat Jul 23 01:25:00 2016 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 3312D12D67A for ; Sat, 23 Jul 2016 01:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqh7tlCbBEiy for ; Sat, 23 Jul 2016 01:24:56 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B22912D5AE for ; Sat, 23 Jul 2016 01:24:56 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id x25so73778513qtx.2 for ; Sat, 23 Jul 2016 01:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=N/087M/p6nO3w44KFtH9vIpw2/SqbwcE2rXaTj+0uw0=; b=I6lrRoqGzY+vWr9k6+u9xZZ/2Cleibv3HpP8aa+eilMi44Ja7mcGaFZcQ1+YFYKriw gJ75NS1pDrGbfGTNwvnDU3PCB/z2LdUU5em3Q7e0GWQOK1l7pS1I56DSgBX9HdqEnX3W zr3Goy3gwg7QMNQ2QBDptDoPtW4SZmN95RIcSha7ELgDU5g6cGvmPT2GvJQMAhTWWxU8 DrFLnRIZapULG1ebzBwCdPVC5HUP9JVP4dv9UdgPXZWQDgSVY/9OnrxjCXX1ashp4OPc hxB8XxSLlpW7l5jyX7kvqiddFcSsyY/kbjGFZ5nERZVYxsE1Y2mZ6ZuqkZ1PYFVNvHy0 SWFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=N/087M/p6nO3w44KFtH9vIpw2/SqbwcE2rXaTj+0uw0=; b=F6mnY+6VEdY2LGxu5TgGXkwI4VXOijV9wxLqGD9vPV/n1LwRiWMl7TklJaq2ROH/o0 xS4kjxlnrDT0HCgFGaRiZdw7BnguBr1r4eMWdRWOPzkcOVfackxNuZImzO2knmaDXOTz S1jL+Lkyulc4hCWuc5pIzYCG7L5GELdJoeLH3RoKmrdnHT94MQwMEtzGIGh2F46BBu4C MuBeezjBB8fYeGRYLMincrxbFdgfwH74GeQqfNYb7USK3plV02dsEp1miol9V4M7awKo M+iUf2CgJHu971evnYXb9RXuXUbMkAUwdSRM1npXu3LGlHRSEdWFQFGvlAdIbfklGeuZ 9FBA== X-Gm-Message-State: AEkoouvl2cR3Gj0C7sJsndBH57y4VJq7osUo9XcCZINNC3oIn3hn0pq726HsaDjgiAc2C48p+VzyarcqQIpJwA== X-Received: by 10.200.55.137 with SMTP id d9mr12967630qtc.46.1469262295790; Sat, 23 Jul 2016 01:24:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.46.102 with HTTP; Sat, 23 Jul 2016 01:24:26 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801C3AA5BBE@tss-server1.home.tropicalstormsoftware.com> References: <4380A22D88B79C47883D0026E2CD55148C1194F6@ottsvw202.gdcan.com> <1468965376.8956.77.camel@tropicalstormsoftware.com> <4380A22D88B79C47883D0026E2CD55148C11954D@ottsvw202.gdcan.com> <38A5475DE83986499AEACD2CFAFC3F9801C3AA5BBE@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Sat, 23 Jul 2016 10:24:26 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" , "Viberg, Neil" Subject: Re: [manet] DLEP-23 addition of RFC 5082 requirement X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 08:24:58 -0000 On Sat, Jul 23, 2016 at 10:21 AM, Rick Taylor wrote: > All, > > There will be an update to DLEP to include Neil=E2=80=99s suggested text,= pointing out that RFC 5028 (TLL 255) is only applied to the TCP connection= , and TTL 1 is required for the UDP discovery phase, unless IPv6 link-local= addressing is in use. > > After some further investigation, for those using Linux, there are socket= options (setsockopt) for both IPv4 and IPv6 non-root user-mode sockets to = handle all these cases: > > IP_RECVTTL - To check the TTL =3D=3D 1 on UDP packets. > IP_MINTTL - To enforce the TTL =3D=3D 255 on TCP/IPv4 sockets. > IPV6_MINHOPCOUNT - To enforce the TTL =3D=3D 255 on TCP/IPv6 sockets. We should put these into an appendix, they are a pain to find unless you know them already. Maybe also put the necessary socket options to SET the TTL on posix systems. Henning Rogge From nobody Sat Jul 23 01:27:22 2016 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 CED6212D67A; Sat, 23 Jul 2016 01:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnegetzrEJHc; Sat, 23 Jul 2016 01:27:15 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE8512D5AE; Sat, 23 Jul 2016 01:27:14 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id x1so120004430qkb.3; Sat, 23 Jul 2016 01:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NCyK5h18g/mzLIPR4W1kj1+PDUmMX+JV5Ek8Gj1F4NQ=; b=KcLfhSOBwfH5zMR76rmsjgjHw5K4/Chu5PUVr6tnT9UOVhbtt4E9igWP2dXgF2BiI+ 0nQYZYgSU1bWdtcKlIRrEn7hpNApz42pnB4WgR8rWK8aOa25QNP3FgAs69zogFKnMs++ T4pS7+5DGhWXdx3icHzhwaUGJ4i1sTrs5RqJD2EeaR8fB38zK6sScgynQzxoT42G5VcU 542e1+Pp4/YBFzVod2nV+FsksrI7bSU5vRhi4ubrurBONQqsY+emTGJ6vvHoglKPyHq7 Ry/pmGH5vaVoO2K8HxluyK/j3s4AHWfVDbTPu4ql92aailNo0qe0y7z+0wYrlcXU7Jne smnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NCyK5h18g/mzLIPR4W1kj1+PDUmMX+JV5Ek8Gj1F4NQ=; b=hzLO2F3uQsmz14O3abl8Y64ymMujYLfdQ3TWBfTBXl7X2WLqURDlo15KKfUyltIZyP ppYXUufCRpNihwG/YUBMC9IllpslJqCfELeyE7fdQXoM+uwlTxzLjhljNIpylMrqRaBd XU+Oqy02iDIJzCqoVg0gZv1W1wP8CkBYTyEEm7uBQwwa3dRo28wiODyvzJmFX5WIobSv 1FY9C6rRbXn0x9zszV+VvV1mR0eVAO3uriYM79OzMqwoIW1TIWNn2KKaUPa+OhVagVZe IhG2t8SsBkPoK217PDkh786fXhqdsnVbjdH7y4hPgrCb8wOerUMGXc3qfZMv0xbLxyvo V8og== X-Gm-Message-State: AEkoousRmoDEeJOGp4RXyU5ZxQRk8KpTp0Uu5B4Jo4i5Dklg/GHybdZK6JpwL9PcXVLtXZEVhtvX2ZzuFTp62A== X-Received: by 10.55.5.136 with SMTP id 130mr9876993qkf.185.1469262434095; Sat, 23 Jul 2016 01:27:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.46.102 with HTTP; Sat, 23 Jul 2016 01:26:44 -0700 (PDT) In-Reply-To: <87r3al5kli.wl-jch@pps.univ-paris-diderot.fr> References: <87r3al5kli.wl-jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Sat, 23 Jul 2016 10:26:44 +0200 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "homenet@ietf.org Group" , MANET IETF Subject: Re: [manet] Manet address assignment X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 08:27:17 -0000 Hi, on the other side a well designed routing protocol does not need much (or any) node-specific configuration... and any mesh-wide configuration could easily deployed by the gateway inside a DNCP/HNCP TLV. Henning Rogge On Sat, Jul 23, 2016 at 1:17 AM, Juliusz Chroboczek wrote: > This message is being sent to the manet mailing list, with homenet in CC. > > I took to the microphone during this week's manet meeting to remind people > that Homenet has designed HNCP (RFC 7788), a protocol for autonomous > configuration of multilink home networks, and that it would be a terrible > missed opportunity if a protocol for manet autoconfiguration were standardised > that did not interoperate with HNCP. > > We at Babel Towers are currently experimenting with HNCP in a small mesh > network. The results are encouraging: up to some minor bugs in the > current implementation, HNCP is able to configure a (non-mobile) mesh > network with no operator intervention. We are planning to spend some time > working on shncpd, our implementation of HNCP, until it is able to work > well in our mesh network: > > - change the link sensing mechanism to work better on persistently lossy > links; > - add the ability to configure just a single /128 on loopback (shncpd is > already able to configure a /128 on each interface, which is useful > for mesh networks but out-of-spec -- HNCP requires a /64). > > If this works out, the plan is then to implement an HNCP protocol > extension that allows it to scale better in large and mobile mesh > networks; this will necessarily involve some tradeoffs, such as being > restricted to allocating /128. I'll let you know more when I have code to > show. > > Note that HNCP only does address configuration and naming; it does not > negotiate routing protocol parameters nor provide monitoring facilities. > Thus, it is not a complete solution for a MANET management protocol, and > I believe it does not conflict with the management work being done within > MANET. > > Regards, > > -- Juliusz > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Sat Jul 23 01:31:56 2016 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 43DE612D781; Sat, 23 Jul 2016 01:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ame8ial2qa0U; Sat, 23 Jul 2016 01:31:51 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F3512D755; Sat, 23 Jul 2016 01:31:50 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Sat, 23 Jul 2016 09:31:25 +0100 From: Rick Taylor To: Henning Rogge , Juliusz Chroboczek Thread-Topic: [manet] Manet address assignment Thread-Index: AQHR5G8zCuDVDZHbVUCFheQ/B2BvjKAlnkIAgAAR5WA= Date: Sat, 23 Jul 2016 08:31:25 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801C3AA5BEC@tss-server1.home.tropicalstormsoftware.com> References: <87r3al5kli.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "homenet@ietf.org Group" , MANET IETF Subject: Re: [manet] Manet address assignment X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 08:31:53 -0000 Either way, it's useful information Juliusz, thanks for bringing it to the = list! Rick -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 23 July 2016 09:27 To: Juliusz Chroboczek Cc: homenet@ietf.org Group; MANET IETF Subject: Re: [manet] Manet address assignment Hi, on the other side a well designed routing protocol does not need much (or a= ny) node-specific configuration... and any mesh-wide configuration could ea= sily deployed by the gateway inside a DNCP/HNCP TLV. Henning Rogge On Sat, Jul 23, 2016 at 1:17 AM, Juliusz Chroboczek wrote: > This message is being sent to the manet mailing list, with homenet in CC. > > I took to the microphone during this week's manet meeting to remind=20 > people that Homenet has designed HNCP (RFC 7788), a protocol for=20 > autonomous configuration of multilink home networks, and that it would=20 > be a terrible missed opportunity if a protocol for manet=20 > autoconfiguration were standardised that did not interoperate with HNCP. > > We at Babel Towers are currently experimenting with HNCP in a small=20 > mesh network. The results are encouraging: up to some minor bugs in=20 > the current implementation, HNCP is able to configure a (non-mobile)=20 > mesh network with no operator intervention. We are planning to spend=20 > some time working on shncpd, our implementation of HNCP, until it is=20 > able to work well in our mesh network: > > - change the link sensing mechanism to work better on persistently loss= y > links; > - add the ability to configure just a single /128 on loopback (shncpd i= s > already able to configure a /128 on each interface, which is useful > for mesh networks but out-of-spec -- HNCP requires a /64). > > If this works out, the plan is then to implement an HNCP protocol=20 > extension that allows it to scale better in large and mobile mesh=20 > networks; this will necessarily involve some tradeoffs, such as being=20 > restricted to allocating /128. I'll let you know more when I have=20 > code to show. > > Note that HNCP only does address configuration and naming; it does not=20 > negotiate routing protocol parameters nor provide monitoring facilities. > Thus, it is not a complete solution for a MANET management protocol,=20 > and I believe it does not conflict with the management work being done=20 > within MANET. > > Regards, > > -- Juliusz > > _______________________________________________ > 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 nobody Mon Jul 25 14:56:44 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7047112DA54; Mon, 25 Jul 2016 14:56:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160725215639.11441.74996.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2016 14:56:39 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-11.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 21:56:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Jiazi Yi Benoit Parrein Filename : draft-ietf-manet-olsrv2-multipath-11.txt Pages : 24 Date : 2016-07-25 Abstract: This document specifies a multi-path extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-11 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 nobody Mon Jul 25 15:06:53 2016 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 4842C12DA57 for ; Mon, 25 Jul 2016 15:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDAFzEPML72g for ; Mon, 25 Jul 2016 15:06:37 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 525A712B05C for ; Mon, 25 Jul 2016 15:06:36 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id b199so138011189lfe.0 for ; Mon, 25 Jul 2016 15:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=1eJQhlGyUpuIVd4FEYlykXg9pmzjoErIg7p7FanYyZg=; b=ayXBQdtlIDw30no+3mD9osp5JgW3P/tRHhJvfUbgQ4dAXkV30+7/CB+8oV7Vek/nff zCdlWeI+nYo6psnCOqLYq6Sb8GPY+vhe/uD+kVtBmmDLYIp7bIjOsEfXYl9RHRRM+3bY uSWSZOJFTG6ytDWLEtDe0MXq2SnqSo+77xC7rQa6CGu8yKePS1bC8cd9z5NQ3OCnXX/m qbB+NEw12O/Ihr9He94P4aNPJe2r3Iv7cAyrksl1iEaWxVKgvOGSk/EZlYcaiCAB+LvZ BKkq//LkcScvs3tm5me8DVJ7oF1coM2DUbDcpdVbx+8HPWYn8faVWFQVieghtDxKog+i dbww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=1eJQhlGyUpuIVd4FEYlykXg9pmzjoErIg7p7FanYyZg=; b=ifTBtyfQWxrs2h4PqZIj1wPdg5Xzc1skVWaVBHt4z0W3fTYiYL7LQxRzBQWrwhNNR4 3K44IEHy8+6o7o7IgN1pBoyjVMD8e2+yfK3d9X4UyBu96iImZvgSggwy/6iItiO0zrfb X0d5fG1leu8+TAfODgnraziQ6gjgRdMPWlc9kLsupWAJ3aCdeXw/TXSibMrAmlLALBl4 YfVb0sDYENwQexwUF5aAn8uDvezopnwHRBsGEynvG0+ffH86VvfqpfvgpsKyK+il5Lf2 IIeTaDlwghxXFEdoLimOdvSm6x4jH9JCnJ0A7nuexmRl/723tS7gsydfa72okTzBG2Hu fDRg== X-Gm-Message-State: AEkoouvW4VfJbC86t4KMp3OTb/WbUPo7xMxBg3ra8z7Xs4bPF/uzC+MFaGfgxxOqpbqd1kyPGOhLz6a14p7u5w== X-Received: by 10.25.33.79 with SMTP id h76mr7195012lfh.82.1469484386611; Mon, 25 Jul 2016 15:06:26 -0700 (PDT) MIME-Version: 1.0 Sender: yi.jiazi@gmail.com Received: by 10.114.186.202 with HTTP; Mon, 25 Jul 2016 15:06:25 -0700 (PDT) In-Reply-To: <20160725215639.11441.21673.idtracker@ietfa.amsl.com> References: <20160725215639.11441.21673.idtracker@ietfa.amsl.com> From: Jiazi YI Date: Tue, 26 Jul 2016 00:06:25 +0200 X-Google-Sender-Auth: ogIWCh8cB4yFIFBSRaARn2SqRPg Message-ID: To: manet Content-Type: multipart/alternative; boundary=001a1141091eddf72505387cfed6 Archived-At: Subject: [manet] Fwd: New Version Notification for draft-ietf-manet-olsrv2-multipath-11.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 22:06:45 -0000 --001a1141091eddf72505387cfed6 Content-Type: text/plain; charset=UTF-8 Dear all, We just submitted a new revision of olsrv2-multipath. The update is based on the comments and discussion from the thread https://www.ietf.org/mail-archive/web/manet/current/msg19164.html Other than the editorial changes, an update is that we added an 1-octet value field in the SOURCE_ROUTE TLV to carry a multiplier information. This is to make the holding time of the SR-OLSRv2 Router Tuple can be calculated based on the information carried in the HELLO/TC messages, rather than a router's predefined holding time. Regarding the erasure coding, we temporarily removed the sentence "By definition, erasure coding is insensitive to the packet misordering.". I'll have further exchange with Benoit to have more concrete text or references. Thanks very much for the comments! regards Jiazi ---------- Forwarded message ---------- From: Date: Mon, Jul 25, 2016 at 11:56 PM Subject: New Version Notification for draft-ietf-manet-olsrv2-multipath-11.txt To: Benoit Parrein , Jiazi Yi < jiazi@jiaziyi.com>, Benoit Parrein A new version of I-D, draft-ietf-manet-olsrv2-multipath-11.txt has been successfully submitted by Jiazi Yi and posted to the IETF repository. Name: draft-ietf-manet-olsrv2-multipath Revision: 11 Title: Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Document date: 2016-07-25 Group: manet Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-multipath-11.txt Status: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ Htmlized: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-11 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-11 Abstract: This document specifies a multi-path extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. 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. The IETF Secretariat --001a1141091eddf72505387cfed6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

We just subm= itted a new revision of olsrv2-multipath.=C2=A0

Th= e update is based on the comments and discussion from the thread=C2=A0ht= tps://www.ietf.org/mail-archive/web/manet/current/msg19164.html

Other than the editorial changes, an update is that we ad= ded an 1-octet value field in the SOURCE_ROUTE TLV to carry a multiplier in= formation. This is to make the holding time of the SR-OLSRv2 Router Tuple c= an be calculated based on the information carried in the HELLO/TC messages,= rather than a router's predefined holding time.=C2=A0

Regarding the erasure coding, we temporarily removed the sent= ence "By definition, erasure coding is insensitive to the packet misor= dering.". I'll have further exchange with Benoit to have more conc= rete text or references.=C2=A0

Thanks very m= uch for the comments!

regards

=
Jiazi


---------- Fo= rwarded message ----------
From: <internet-draf= ts@ietf.org>
Date: Mon, Jul 25, 2016 at 11:56 PM
Subjec= t: New Version Notification for draft-ietf-manet-olsrv2-multipath-11.txtTo: Benoit Parrein <Benoit.Parrein@polytech.univ-nantes.fr>, Jiazi Yi <jiazi@jiaziyi.com>, Benoit Parrein <= ;benoit.parrein@p= olytech.univ-nantes.fr>



A new version of I-D, draft-ietf-manet-olsrv2-multipath-11.txt
has been successfully submitted by Jiazi Yi and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-manet-olsrv2-multi= path
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A011
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multi-path Extension for the Optim= ized Link State Routing Protocol version 2 (OLSRv2)
Document date:=C2=A0 2016-07-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 manet
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 24
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-mane= t-olsrv2-multipath-11.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/=
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-11
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsr= v2-multipath-11

Abstract:
=C2=A0 =C2=A0This document specifies a multi-path extension for the Optimiz= ed Link
=C2=A0 =C2=A0State Routing Protocol version 2 (OLSRv2) to discover multiple=
=C2=A0 =C2=A0disjoint paths, so as to improve reliability of the OLSRv2 pro= tocol.
=C2=A0 =C2=A0The interoperability with OLSRv2 is retained.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a1141091eddf72505387cfed6-- From nobody Tue Jul 26 07:02:02 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6F312DE31; Tue, 26 Jul 2016 07:01:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160726140145.8503.52895.idtracker@ietfa.amsl.com> Date: Tue, 26 Jul 2016 07:01:45 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 14:01:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Shawn Jury Darryl Satterwhite Rick Taylor Bo Berry Filename : draft-ietf-manet-dlep-24.txt Pages : 68 Date : 2016-07-26 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-24 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 nobody Tue Jul 26 08:44:15 2016 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 BDC0A12D60F for ; Tue, 26 Jul 2016 08:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq2e7Ro-6-u9 for ; Tue, 26 Jul 2016 08:44:10 -0700 (PDT) Received: from smtp1.idirect.net (smtp1.idirect.net [198.180.159.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B0C12DACB for ; Tue, 26 Jul 2016 08:12:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,425,1464667200"; d="scan'208";a="6846698" IronPort-PHdr: =?us-ascii?q?9a23=3AKkm4wx/eiaQ2mP9uRHKM819IXTAuvvDOBiVQ1KB8?= =?us-ascii?q?0escTK2v8tzYMVDF4r011RmSDN2dtakP27OempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47AblHf6ke/8SQVUk2mc1Ek?= =?us-ascii?q?fqKrQcWC1oye7KObw9XreQJGhT6wM/tZDS6dikHvjPQQmpZoMa0ryxHE8TNicu?= =?us-ascii?q?VSwn50dxrIx06vru/5xpNo8jxRtvQ97IYAFPyiJ+VrBYBfWX4jOmY4+OXquAXN?= =?us-ascii?q?CwyV6TFUBmAflBdUKwnI8B+8WY3+5G+y/MN5xiCAOoXMQKw9Xz3qr65xRQPhji?= =?us-ascii?q?5GfXZt+XvalsV2hYpQoQmqoFp0xIuCM6+PM/8rNJnUYdcbS2QFFv1NXipFD5L2?= =?us-ascii?q?J98UFeMdOedWoaH8q1oUoBCiQw+hGLW8mXdzmnbq0PhigKwaGgbc0VllRopWvQ?= =?us-ascii?q?=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2BOAQAefZdX/8v6+gpeGgEBAQGDd3wGjSWrToF0CRkLhXk?= =?us-ascii?q?CgXAUAQEBAQEBAQGBA4IyBAESAYISAQEBAQMBAQE3NBcEAgEIEQQBAR8JBycLF?= =?us-ascii?q?AcBAQUDAgQBEgiIN7kLAQEBAQEBAQEBAQEBAQEBAQEBAR6GK4RMihsFmSsGAYY?= =?us-ascii?q?XgnyFYIFzToQMiHmMLYN4HoQubodKfwEBAQ?= From: "Ratliff, Stanley" To: "manet@ietf.org" , "Alvaro Retana (aretana)" Thread-Topic: [manet] I-D Action: draft-ietf-manet-dlep-24.txt Thread-Index: AQHR50ZIy8T+NkwAV0m71QgxugOSzqAq0N9g Date: Tue, 26 Jul 2016 15:12:51 +0000 Message-ID: <7315b00eaeea46e8a12042ba9a0025e8@VAUSDITCHM2.idirect.net> References: <20160726140145.8503.52895.idtracker@ietfa.amsl.com> In-Reply-To: <20160726140145.8503.52895.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [manet] FW: I-D Action: draft-ietf-manet-dlep-24.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 15:44:14 -0000 Hello WG, = We (the authors) believe DLEP-24 addresses the AD review comments, and reso= lves the comments on-list from DLEP-23. As always, your further review & co= mments are welcome. = Alvaro, FYI. = Regards, Stan > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, July 26, 2016 10:02 AM > To: i-d-announce@ietf.org > Cc: manet@ietf.org > Subject: [manet] I-D Action: draft-ietf-manet-dlep-24.txt > = > = > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Mobile Ad-hoc Networks of the IETF. > = > Title : Dynamic Link Exchange Protocol (DLEP) > Authors : Stan Ratliff > Shawn Jury > Darryl Satterwhite > Rick Taylor > Bo Berry > Filename : draft-ietf-manet-dlep-24.txt > Pages : 68 > Date : 2016-07-26 > = > Abstract: > When routing devices rely on modems to effect communications over > wireless links, they need timely and accurate knowledge of the > characteristics of the link (speed, state, etc.) in order to make > routing decisions. In mobile or other environments where these > characteristics change frequently, manual configurations or the > inference of state through routing or transport protocols does not > allow the router to make the best decisions. A bidirectional, event- > driven communication channel between the router and the modem is > necessary. > = > = > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ > = > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-manet-dlep-24 > = > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-dlep-24 > = > = > Please note that it may take a couple of minutes from the time of submiss= ion > 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/ > = > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Tue Jul 26 08:57:23 2016 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 CF7D412DB2E for ; Tue, 26 Jul 2016 08:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rdnYC_foTQH for ; Tue, 26 Jul 2016 08:57:15 -0700 (PDT) Received: from smtp2.idirect.net (smtp2.idirect.net [198.180.159.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DEF12DD1D for ; Tue, 26 Jul 2016 08:37:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,425,1464667200"; d="scan'208";a="1509958" IronPort-PHdr: =?us-ascii?q?9a23=3AXkXAQBVJtMEcz7ChNwjA27GURdXV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYZxeBt8tkgFKBZ4jH8fUM07OQ6PG4HzJbqsbd+Fk5M7V0Hycfjs?= =?us-ascii?q?sXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJP?= =?us-ascii?q?K/jvHcaK1oLshrj0pcaYM1kArQH+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf?= =?us-ascii?q?9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t4XXskyJ?= =?us-ascii?q?YQaG/H8bTGhS2jFIGQne8BbiXprr+mvHlas3kH2RPdf3VvY4VD2466B1RTfigS?= =?us-ascii?q?ocJiUl/WTMzMd3ifQf6Fikrhpy36bVbZ2bcv1kcemVKdYTQ2dddsdcSyIHBZmz?= =?us-ascii?q?OdghFe0EaKxippX5plUA6VOFGQCqAO7+gHccnWX/wak73eoJEA3HxgErA5QIvW?= =?us-ascii?q?iC/4a9D7sbTe3glPqA9j7Edf4DnG6lsIU=3D?= X-IPAS-Result: =?us-ascii?q?A2BOAQB2g5dX/8n6+gpeGgEBAQGDd3wGjSWrU4F9JIV0AwI?= =?us-ascii?q?CgXAUAQEBAQEBAQGBA4IyBAESAYISAQEBAQNJKBQEAgEIEQQBASgHMhQJCAEBB?= =?us-ascii?q?AESCBMDiCGsfYwXAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYrg0mBA4QSCgcBChk?= =?us-ascii?q?lDIUjBYgbhjN7iWIGAY5zgXOEWoh5hEGEAINsg3gegkYcgUxuhwUCDTZ/AQEB?= From: "Ratliff, Stanley" To: "Dearlove, Christopher (UK)" , "manet@ietf.org" Thread-Topic: Routing area draft minutes available Thread-Index: AdHnLXWJAkRNXUXbTkuFzXoYajOiEQAHKn9QAAIqbbA= Date: Tue, 26 Jul 2016 15:37:48 +0000 Message-ID: <0250fbb839714f2b94da891a1a5fde42@VAUSDITCHM2.idirect.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] Routing area draft minutes available X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 15:57:18 -0000 Chris, = > -----Original Message----- > From: Dearlove, Christopher (UK) [mailto:chris.dearlove@baesystems.com] > Sent: Tuesday, July 26, 2016 10:51 AM > To: Jonathan Hardwick ; routing- > discussion@ietf.org; rtg-chairs@ietf.org; rtg-dir@ietf.org; rtg- > ads@tools.ietf.org > Subject: RE: Routing area draft minutes available > = > Obviously (as I wasn't present) I'm not commenting on the minutes reflect= ing > what was said. But to the questions asked about MANET: > = > > George Swallow: Building large packets by putting small packets togethe= r; > large > > packets more likely to get corrputed; how about sending = smaller > > packets? > > Justin: Smaller packets will get through more, which is not always good= as > you > > don't want to find neighbours that you have a poor link to. > = > I think a more important point is that packets have overheads (headers for > RFC 5444, UDP, IP, MAC and also media access overheads). So fewer packets > can be a significant win. > = > > Chris Bowers: Why is the 2-hop neighbour important? > > Justin: Many of the algorithms require you to know your 2-hop neighbour= s. > > Chris: So unlike IS-IS, you need to be careful to constraing flooding? > > (Yes) > > Stan: RFC 5820 uses a 2-hop neighbourhood for flooding in OSPFv3. > = > RFC 3626 (OLSR) predates this in using two hop information to define MPRs > (used for improved flooding and topology reduction), it's where some ideas > in the experimental OSPF wireless extensions came from. And of course now > we have OLSRv2 (RFC 7181) at Proposed Standard. > = > > Jehan Tremback: Does DLEP replace Hello in OLSR protocols? > > Justin: Not completely as the Hello messages require TLVs. > = > NHDP (RFC 6130), the owner of the HELLO messages in the OLSRv2 family, > permits using any other sources of information (DLEP could be one) to > augment HELLO messages (subject to certain constraints). But there are > several things in HELLO messages that DLEP doesn't supply to the router -= in > particular, but not only, things added by OLSRv2 (MPRs, knowledge of > OLSRv2 support using its metrics). I'm also not sure DLEP would provide t= he > multiple interface information properly. > = > But even if DLEP did report such things radio to router, DLEP is entirely= about > that interface. DLEP defines no over the air signalling, which is what HE= LLO > messages provide - to establish connectivity and exchange information. To > use DLEP to provide the information that routers need to run NHDP/OLSRv2, > you'd need to define an over the air signalling between radios. Or in oth= er > words, re-invent NHDP. > = > Rather, what might make sense is that if you want some over the air > signalling for DLEP gather some of its information, you could add it to H= ELLO > messages if running NHDP. (Not quite ideal, as HELLO messages are designed > to run router to router, not radio to radio. And off course you may well = not > be running NHDP, in which case you would need another solution.) In the DLEP/OSPF implementation I worked on - when the router-side DLEP rec= eived a Destination Up message from the modem, it (the router-side DLEP) wo= uld simply indicate to OSPF that the event occurred. OSPF used this indicat= ion to send a normal HELLO, irrespective of the state of its HELLO timer. T= here is a similar indication on receipt of Destination Down from the modem;= that indicator causes OSPF to act as if the "Dead Timer" has expired on th= e neighbor. I can see this type of interaction between DLEP and NHDP. = Regards, Stan > = > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > __________________________________________________________ > ________________ > = > T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com > = > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited Registered in England & Wales No: > 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 > 7YP > = > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org] On > Behalf Of Jonathan Hardwick > Sent: 26 July 2016 12:05 > To: routing-discussion@ietf.org; rtg-chairs@ietf.org; rtg-dir@ietf.org; r= tg- > ads@tools.ietf.org > Subject: Routing area draft minutes available > = > = > *** WARNING *** > This message originates from outside our organisation, either from an > external partner or the internet. > Consider carefully whether you should click on any links, open any > attachments or reply. > For information regarding Red Flags that you can look out for in emails y= ou > receive, click here. > If you feel the email is suspicious, please follow this process. > The draft minutes for the RTGAREA meeting at IETF 96 are now > available.=A0 Please let me know if you have any comments. > https://www.ietf.org/proceedings/96/minutes/minutes-96-rtgarea > = > Best regards > Jon > = > ********************************************************** > ********** > 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 distribu= te its > contents to any other person. > ********************************************************** > ********** > = _____________________________________________________ This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. _____________________________________________________ From nobody Tue Jul 26 09:15:37 2016 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 5CD5E12D0BA for ; Tue, 26 Jul 2016 09:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.207 X-Spam-Level: X-Spam-Status: No, score=-8.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLXjICuaJeWW for ; Tue, 26 Jul 2016 09:15:33 -0700 (PDT) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630E112D0A4 for ; Tue, 26 Jul 2016 09:13:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,425,1464649200"; d="scan'208";a="39297805" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 26 Jul 2016 17:13:21 +0100 X-IronPort-AV: E=Sophos;i="5.28,425,1464649200"; d="scan'208";a="127664714" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 26 Jul 2016 17:13:21 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.169]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Tue, 26 Jul 2016 17:13:21 +0100 From: "Dearlove, Christopher (UK)" To: "Ratliff, Stanley" , "manet@ietf.org" Thread-Topic: Routing area draft minutes available Thread-Index: AdHnLXWJAkRNXUXbTkuFzXoYajOiEQAHKn9QAAIqbbAAAWD0kA== Date: Tue, 26 Jul 2016 16:13:21 +0000 Message-ID: References: <0250fbb839714f2b94da891a1a5fde42@VAUSDITCHM2.idirect.net> In-Reply-To: <0250fbb839714f2b94da891a1a5fde42@VAUSDITCHM2.idirect.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Routing area draft minutes available X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 16:15:35 -0000 Yes, that is an additional form of possible interaction. But it meets the s= ame basic shape - DLEP can inform the user of HELLO messages (OLSR or OSPF)= - here to help manage its schedule, which I hadn't considered - but doesn'= t substitute for them. --=20 Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: Ratliff, Stanley [mailto:sratliff@idirect.net]=20 Sent: 26 July 2016 16:38 To: Dearlove, Christopher (UK); manet@ietf.org Subject: RE: Routing area draft minutes available ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- Chris,=20 > -----Original Message----- > From: Dearlove, Christopher (UK)=20 > [mailto:chris.dearlove@baesystems.com] > Sent: Tuesday, July 26, 2016 10:51 AM > To: Jonathan Hardwick ; routing-=20 > discussion@ietf.org; rtg-chairs@ietf.org; rtg-dir@ietf.org; rtg-=20 > ads@tools.ietf.org > Subject: RE: Routing area draft minutes available >=20 > Obviously (as I wasn't present) I'm not commenting on the minutes=20 > reflecting what was said. But to the questions asked about MANET: >=20 > > George Swallow: Building large packets by putting small packets=20 > > together; > large > > packets more likely to get corrputed; how about sending = smaller > > packets? > > Justin: Smaller packets will get through more, which is not always=20 > > good as > you > > don't want to find neighbours that you have a poor link to. >=20 > I think a more important point is that packets have overheads (headers=20 > for RFC 5444, UDP, IP, MAC and also media access overheads). So fewer=20 > packets can be a significant win. >=20 > > Chris Bowers: Why is the 2-hop neighbour important? > > Justin: Many of the algorithms require you to know your 2-hop neighbour= s. > > Chris: So unlike IS-IS, you need to be careful to constraing flooding? > > (Yes) > > Stan: RFC 5820 uses a 2-hop neighbourhood for flooding in OSPFv3. >=20 > RFC 3626 (OLSR) predates this in using two hop information to define=20 > MPRs (used for improved flooding and topology reduction), it's where=20 > some ideas in the experimental OSPF wireless extensions came from. And=20 > of course now we have OLSRv2 (RFC 7181) at Proposed Standard. >=20 > > Jehan Tremback: Does DLEP replace Hello in OLSR protocols? > > Justin: Not completely as the Hello messages require TLVs. >=20 > NHDP (RFC 6130), the owner of the HELLO messages in the OLSRv2 family,=20 > permits using any other sources of information (DLEP could be one) to=20 > augment HELLO messages (subject to certain constraints). But there are=20 > several things in HELLO messages that DLEP doesn't supply to the=20 > router - in particular, but not only, things added by OLSRv2 (MPRs,=20 > knowledge of > OLSRv2 support using its metrics). I'm also not sure DLEP would=20 > provide the multiple interface information properly. >=20 > But even if DLEP did report such things radio to router, DLEP is=20 > entirely about that interface. DLEP defines no over the air=20 > signalling, which is what HELLO messages provide - to establish=20 > connectivity and exchange information. To use DLEP to provide the=20 > information that routers need to run NHDP/OLSRv2, you'd need to define=20 > an over the air signalling between radios. Or in other words, re-invent N= HDP. >=20 > Rather, what might make sense is that if you want some over the air=20 > signalling for DLEP gather some of its information, you could add it=20 > to HELLO messages if running NHDP. (Not quite ideal, as HELLO messages=20 > are designed to run router to router, not radio to radio. And off=20 > course you may well not be running NHDP, in which case you would need=20 > another solution.) In the DLEP/OSPF implementation I worked on - when the router-side DLEP rec= eived a Destination Up message from the modem, it (the router-side DLEP) wo= uld simply indicate to OSPF that the event occurred. OSPF used this indicat= ion to send a normal HELLO, irrespective of the state of its HELLO timer. T= here is a similar indication on receipt of Destination Down from the modem;= that indicator causes OSPF to act as if the "Dead Timer" has expired on th= e neighbor. I can see this type of interaction between DLEP and NHDP.=20 Regards, Stan >=20 > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories=20 > __________________________________________________________ > ________________ >=20 > T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com >=20 > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great=20 > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited Registered in England & Wales No= : > 01337451 Registered Office: Surrey Research Park, Guildford, Surrey,=20 > GU2 7YP >=20 > From: routing-discussion [mailto:routing-discussion-bounces@ietf.org]=20 > On Behalf Of Jonathan Hardwick > Sent: 26 July 2016 12:05 > To: routing-discussion@ietf.org; rtg-chairs@ietf.org;=20 > rtg-dir@ietf.org; rtg- ads@tools.ietf.org > Subject: Routing area draft minutes available >=20 >=20 > *** WARNING *** > This message originates from outside our organisation, either from an=20 > external partner or the internet. > Consider carefully whether you should click on any links, open any=20 > attachments or reply. > For information regarding Red Flags that you can look out for in=20 > emails you receive, click here. > If you feel the email is suspicious, please follow this process. > The draft minutes for the RTGAREA meeting at IETF 96 are now=20 > available.=A0 Please let me know if you have any comments. > https://www.ietf.org/proceedings/96/minutes/minutes-96-rtgarea >=20 > Best regards > Jon >=20 > ********************************************************** > ********** > This email and any attachments are confidential to the intended=20 > recipient and may also be privileged. If you are not the intended=20 > 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=20 > distribute its contents to any other person. > ********************************************************** > ********** >=20 _____________________________________________________ This electronic message and any files transmitted with it contains informat= ion from iDirect, which may be privileged, proprietary and/or confidential.= It is intended solely for the use of the individual or entity to whom they= are addressed. If you are not the original recipient or the person respons= ible for delivering the email to the intended recipient, be advised that yo= u have received this email in error, and that any use, dissemination, forwa= rding, printing, or copying of this email is strictly prohibited. If you re= ceived this email in error, please delete it and immediately notify the sen= der. _____________________________________________________ From nobody Thu Jul 28 08:59:03 2016 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FCF12D0DC; Thu, 28 Jul 2016 08:59:02 -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: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160728155902.12860.24919.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2016 08:59:02 -0700 Archived-At: Cc: manet-chairs@ietf.org, chris.dearlove@baesystems.com, manet@ietf.org, draft-ietf-manet-smf-sec-threats@ietf.org Subject: [manet] Last Call: (Security Threats for Simplified Multicast Forwarding (SMF)) to Informational RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 15:59:02 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for Simplified Multicast Forwarding (SMF)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-11. 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 analyzes security threats of the Simplified Multicast Forwarding (SMF), including the vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-manet-smf-sec-threats/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-manet-smf-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D.