From nobody Wed Apr 1 04:37:37 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6041A02BE for ; Wed, 1 Apr 2015 04:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 V98mTgw5w33J for ; Wed, 1 Apr 2015 04:37:29 -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 B79181A00E2 for ; Wed, 1 Apr 2015 04:37:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208";a="539093280" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta1.baesystems.com with ESMTP; 01 Apr 2015 12:37:28 +0100 X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208";a="93224991" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 01 Apr 2015 12:37:26 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.91]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0224.002; Wed, 1 Apr 2015 12:37:26 +0100 From: "Dearlove, Christopher (UK)" To: Jack Shaio , Jiazi YI Thread-Topic: [manet] draft-shaio-manet-common-l3-interface Thread-Index: AdBn76zCrc97kVn+Ru+3K5s8qImEYAAq/qOAAAGVUIAAArWAgAADufmAAOyhmgA= Date: Wed, 1 Apr 2015 11:37:25 +0000 Message-ID: References: <7505A980-FE00-4A0E-8564-8BB3DFDA19EE@gmail.com> <20150327142749.06d30d2a@localhost> In-Reply-To: <20150327142749.06d30d2a@localhost> 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="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Broderick, Don" , Caleb Lo , Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] draft-shaio-manet-common-l3-interface X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 11:37:35 -0000 Jack Shaio > I believe the Local Attached Network set from OLSRv2 will only inform OLS= Rv2 of other interfaces that do not run this protocol. > But this will not inform IP at the router of potential OSPF peers across = the MANET, which is what our CL3 interface is for. That's mixing up two things. The Local Attached Network Set is in input into OLSRv2 from its environment= . OLSRv2's use for it is to propagate it across the network to inform other= routers' Attached Network Sets (no Local) which in turn inform the Routing= Set. OLSRv2 supplies the Routing Set to its environment which, typically, = uses it to set the local IP routing table. What matters about other routers= across the MANET for simple routing is in the Routing Set. (The Attached N= etwork Set may be accessible e.g. using a MIB.) So IP at the router knows about other routers across the network in terms o= f how to route to them. It even has metric information about them, in OLSRv= 2 terms (which includes a term specific to the attached network). It doesn'= t (unmodified) know whether an attached network is just hosts, or another n= etwork running OSPF or any other alternative. The assumed model is that eac= h network takes care of its only internal details, network A does not need = the internal details of network B. That's the basic Internet approach. The = question that I don't think is clear to anyone here is your use case and wh= y it differs from that model. ******************************************************************** 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 Wed Apr 1 04:41:38 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69DB1A8963 for ; Wed, 1 Apr 2015 04:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HH-y7e_vcrpG for ; Wed, 1 Apr 2015 04:41:30 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC9A1A88D0 for ; Wed, 1 Apr 2015 04:41:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208";a="455100311" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 01 Apr 2015 12:41:27 +0100 X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208";a="96918610" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 01 Apr 2015 12:41:28 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.91]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0224.002; Wed, 1 Apr 2015 12:41:27 +0100 From: "Dearlove, Christopher (UK)" To: Jack Shaio , Henning Rogge Thread-Topic: [manet] draft-shaio-manet-common-l3-interface Thread-Index: AdBn76zCrc97kVn+Ru+3K5s8qImEYAAmMeOAAAKHwQAA93aYEA== Date: Wed, 1 Apr 2015 11:41:27 +0000 Message-ID: References: <20150327093314.29f13add@localhost> In-Reply-To: <20150327093314.29f13add@localhost> 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: Cc: "Broderick, Don" , "manet@ietf.org" , Caleb Lo Subject: Re: [manet] draft-shaio-manet-common-l3-interface X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 11:41:36 -0000 You need to read further in that section, starting To ensure that the non-standards track Experimental and Informational designations are not misused to circumvent the Internet Standards Process I'm not saying you are, I'm saying the rest of that section heavily modifies your summary of your intention below. Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ 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 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jack Shaio Sent: 27 March 2015 13:33 To: Henning Rogge Cc: Broderick, Don; Caleb Lo; manet@ietf.org Subject: Re: [manet] draft-shaio-manet-common-l3-interface I believe that is true of draft standards but not of Informational or Exper= imental drafts, which do not define a standard and are provided only as inf= ormation for the IETF community. = This is what I understood from the relevant section of RFC 2026 which defin= ed the process: http://www.rfc-editor.org/rfc/rfc2026.txt = 4.2.3 Procedures for Experimental and Informational RFCs Unless they are the result of IETF Working Group action, documents intended to be published with Experimental or Informational status should be submitted directly to the RFC Editor. The RFC Editor will publish any such documents as Internet-Drafts which have not already been so published. In order to differentiate these Internet-Drafts they will be labeled or grouped in the I-D directory so they are easily recognizable. The RFC Editor will wait two weeks after this publication for comments before proceeding further... = We thought this work was relevant to the manet WG and wanted to give the gr= oup another opportunity to comment on the draft first, before submitting di= rectly to the RFC Editor as the procedures state. --jack shaio On Fri, 27 Mar 2015 13:20:47 +0100 Henning Rogge expoun= ded: =3D=3D=3D Date: Fri, 27 Mar 2015 13:20:47 +0100 =3D=3D=3D From: Henning Rog= ge =3D=3D=3D To: "Broderick, Don" =3D=3D=3D Cc: "manet@ietf.org" , Caleb Lo , "Jack Shaio (jshaio@comcast.net)" =3D=3D=3D Subject: Re: [manet] draft-shaio-manet-common-l3-interface =3D=3D=3D =3D=3D=3D Hi, =3D=3D=3D =3D=3D=3D I think before a document can become a MANET RFC it needs to be = =3D=3D=3D adopted by the working group. =3D=3D=3D =3D=3D=3D Henning Rogge =3D=3D=3D =3D=3D=3D On Thu, Mar 26, 2015 at 7:14 PM, Broderick, Don = wrote: =3D=3D=3D > We are submitting =3D=3D=3D > http://datatracker.ietf.org/doc/draft-shaio-manet-common-l3-int= erface/ to be =3D=3D=3D > an Experimental RFC. It describes an approach to = overlay IP over MANET but =3D=3D=3D > does not specify a protocol; rather t= he focus is on an interface between IP =3D=3D=3D > and MANET that is local = to one terminal. The draft also presents results of =3D=3D=3D > large scale= simulations of this approach. Our intent is to show that it is =3D=3D=3D >= not necessary to standardize the interface between these two layers by =3D= =3D=3D > prescribing a new message exchange between them. =3D=3D=3D > =3D=3D=3D > =3D=3D=3D > =3D=3D=3D > This draft was submitted to the MANET working group for 12 mont= hs and we are =3D=3D=3D > now asking if it can be moved to Experimental RFC= status, based on our =3D=3D=3D > understanding of RFC 2026 section 4.2. =3D=3D=3D > =3D=3D=3D > =3D=3D=3D > =3D=3D=3D > Thank You, =3D=3D=3D > =3D=3D=3D > Donald Broderick =3D=3D=3D > =3D=3D=3D > The MITRE Corporation =3D=3D=3D > =3D=3D=3D > 202 Burlington Road =3D=3D=3D > =3D=3D=3D > Bedford, MA 01730 =3D=3D=3D > =3D=3D=3D > =3D=3D=3D > _______________________________________________ =3D=3D=3D > manet mailing list =3D=3D=3D > manet@ietf.org =3D=3D=3D > https://www.ietf.org/mailman/listinfo/manet =3D=3D=3D > _______________________________________________ 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 Wed Apr 1 14:41:42 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85881A86EC for ; Wed, 1 Apr 2015 14:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 aRcXJ11ZLO7b for ; Wed, 1 Apr 2015 14:41:38 -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 CE4F91A854D for ; Wed, 1 Apr 2015 14:41:37 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t31LfW5Y013522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Apr 2015 23:41:32 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id t31LfWgn027683; Wed, 1 Apr 2015 23:41:32 +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 9AD012A15EE; Wed, 1 Apr 2015 23:41:32 +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 ChnM6MBYSm0F; Wed, 1 Apr 2015 23:41:31 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id B2B452A15EB; Wed, 1 Apr 2015 23:41:30 +0200 (CEST) Date: Wed, 01 Apr 2015 23:41:44 +0200 Message-ID: <87twwzzftz.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Pascal Thubert (pthubert)" In-Reply-To: References: 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 [IPv6:2001:660:3301:8000::1:2]); Wed, 01 Apr 2015 23:41:33 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 01 Apr 2015 23:41:32 +0200 (CEST) X-Miltered: at korolev with ID 551C660C.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 551C660C.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551C660C.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 551C660C.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 : 551C660C.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 551C660C.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Working group re-charter ideas (meeting summary) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:41:40 -0000 > Any contribution you'd want to make to ROLL? This is probably the place > where the ideas you defend in Babel were most successful... I hope you are not comparing RPL's proactive subset to Babel. Babel is a much, much more refined and complete protocol. Which is okay, since RPL's proactive subset is designed to work in a stable network with a single DODAG. Babel is aimed at a completely different space -- which is why it has redundant routing tables, attempts stability in the presence of variable metrics, has strong loop avoidance properties, and includes blackhole resolution. By the way -- I've tried to find experimental data on RPL, and couldn't find any (perhaps I haven't tried hard enough). Could you send me some references, perhaps by private mail? -- Juliusz From nobody Thu Apr 2 00:53:26 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF6B1A89FC; Thu, 2 Apr 2015 00:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vrQ8df48hhTI; Thu, 2 Apr 2015 00:53:22 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1DF81A8997; Thu, 2 Apr 2015 00:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4065; q=dns/txt; s=iport; t=1427961202; x=1429170802; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2q7z1n5hDTgJ8BgbnX30l9wIyS2rcOy4KplVzoOAUMw=; b=bKwwCHSP2IYh3QbbI2WJfVA5xY292CZrirnQunMj+bThKBp8F/bO5VDC jI37exPNt8TYmSA+CtTCEJIfYf7LVI/C/37dWHRig21DuLDadTf8nuKkZ DS9NMI8y5W4O1y1Bs8VBvo1fX3bdKxgmmz96ZTYmJl72Zv2LbEG3qyrpC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DiBgBS9BxV/4YNJK1cgwiBLsMMiC8CgUBMAQEBAQEBfoQfAQEDAXkQAgEIDjgyJQIEDgWIJwjMdgEBAQEBAQEBAQEBAQEBAQEBAQEBAReKKn+EIQYBAQEcMweDF4EWBYpuhXaJdoEdj1yDSCKDbm+BAgEGAheBIQEBAQ X-IronPort-AV: E=Sophos;i="5.11,509,1422921600"; d="scan'208";a="775824" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP; 02 Apr 2015 07:53:22 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t327rLkA032175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 07:53:21 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 2 Apr 2015 02:53:21 -0500 From: "Pascal Thubert (pthubert)" To: Juliusz Chroboczek Thread-Topic: [manet] Working group re-charter ideas (meeting summary) Thread-Index: AQHQaWOdwXJuyKRYmEO7ZSTTVbCP4p0yRRxBgAbFOQCAAFcQPQ== Date: Thu, 2 Apr 2015 07:53:20 +0000 Message-ID: References: , <87twwzzftz.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87twwzzftz.wl-jch@pps.univ-paris-diderot.fr> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ROLL WG , "manet@ietf.org" Subject: Re: [manet] Working group re-charter ideas (meeting summary) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 07:53:24 -0000 I disagree with the terms in your mail pretty much as much as I agree with = your designs, Juliusz... There are literally hundreds of papers that reference RPL, from Google scho= lar. There are deployed networks of thousands of nodes, and they behave even bet= ter than expected. But what hurts even more is your misunderstanding of the technology: RPL inherits from the same roots as Babel, DSDV and DUAL/EIGRP, though RPL = adds technology to cope with harsher constraints and multiple types of link= s that neither Babel nor any of the common ancestry has. You do not seem to have fully realized how similar Babel is to RPL. Conside= r this: RPL's sequenced advertisement is called the iteration of an instanc= e; so the process of microloop avoidance in Babel is effectively the same a= s what RPL calls a global recovery. Both protocols inherit DUAL's feasibili= ty condition. But RPL adds the capability to make local repair which provid= es a service of freezing akin to the the diffusion algorithm but adapted to= LLN and MANET.=20 Even more, RPL adds a capability to stretch the rules, and a capability to = delay the repairs so as to reduce the control overhead in Lower Power and m= obile use cases. To enable these - arguably optional - features, RPL adds t= he capability to instrument packets beyond hop limit to detect loops and tr= igger repairs. Saying the RPL does not work in MANET environment is a gross misrepresentat= ion. RPL derives from early MANEMO work, which was MANET for NEMO, and it w= as fully demonstrated in that space. RPL works fine in MANET for the same r= easons Babel will. And RPL probably works a lot better because it can: - cope with all sorts of radios with objective functions=20 - allow a trade off of routing stretch vs control plane overhead=20 - address memory constraints=20 - natively support interconnection with LLNs - freeze a zone and perform local repairs - support multiple exits. RPL's instances avoid the need for source/destina= tion routing altogether All in all I remain to be convinced that Babel is much, much, anything. In = my view, it is a great approach but I will need more details to find novelt= y vs. an existing proposed std RFC that is RFC 6550. You will need to demon= strate that novelty to get a new work approved. We went through that in the= first phase of ROLL. And I would be interested in bringing back that novel= ty in RPL. On the side there are multiple implementations of RPL. Some on constrained = devices. 2 on Linux, one of them at least running on OpenWRT (Unstrung). We= even have one running on various network OS'es that Cisco ships in its big= irons, and applicable from gigE to virtual links. All in all, there's a lot of misconceptions that a discussion over a whiteb= oard could help clarify. I'm certainly willing to learn more from Babel and= I trust that you'd need some catching up on RPL before you can discuss it = decently, which sadly was not the case in this mail. I would be glad to meet anytime. We are almost next door... Cheers, Pascal Le 1 avr. 2015 =E0 23:41, Juliusz Chroboczek a =E9crit : >> Any contribution you'd want to make to ROLL? This is probably the place >> where the ideas you defend in Babel were most successful... >=20 > I hope you are not comparing RPL's proactive subset to Babel. Babel is > a much, much more refined and complete protocol. >=20 > Which is okay, since RPL's proactive subset is designed to work in > a stable network with a single DODAG. Babel is aimed at a completely > different space -- which is why it has redundant routing tables, attempts > stability in the presence of variable metrics, has strong loop avoidance > properties, and includes blackhole resolution. >=20 > By the way -- I've tried to find experimental data on RPL, and couldn't > find any (perhaps I haven't tried hard enough). Could you send me some > references, perhaps by private mail? >=20 > -- Juliusz From nobody Thu Apr 2 01:30:24 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161D91A8A90; Thu, 2 Apr 2015 01:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Io_qlSjVRnVE; Thu, 2 Apr 2015 01:30:21 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBEB81A8AA5; Thu, 2 Apr 2015 01:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10563; q=dns/txt; s=iport; t=1427963421; x=1429173021; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VDgAPhubo6DXqfgJGeCvSuYqx1ynLDTe4tWxay8lPtQ=; b=kEJlX+VRtpKKljAggDQw5bcGeRdBqXA3PwvoXV3uWn+qDzCuVG18Am0g UAKgE1KfJgHXtI/ZJ3qqZc3gusLIdo6MwmI3Nld4khDCe2lfia1wLSyWQ rCNjK2EuDNjxt2714y3vFej0MW7y4pon2RylgSANwgGgCBxqO/eztwldX U=; X-Files: smime.p7s : 3862 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BGBQBo/RxV/5ldJa1cgwhSXAXFQQqFcwKBQEwBAQEBAQF+hB4BAQEDAQEBAWsLBQsCAQgOCi4CJQslAgQBDQUOiBkIDcxwAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKKn+EIQYBAQFPB4MXgRYFjlWCD4FsgTKCeoNegR2PXINIIoNub4ECAQYCFyJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,509,1422921600"; d="p7s'?scan'208";a="137614645" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 02 Apr 2015 08:30:20 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t328UJCF021018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 08:30:20 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.253]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 2 Apr 2015 03:30:19 -0500 From: "JP Vasseur (jvasseur)" To: Juliusz Chroboczek , "Pascal Thubert (pthubert)" Thread-Topic: [manet] Working group re-charter ideas (meeting summary) Thread-Index: AQHQbR9AU18Lqg+AfE6rBUKLduipcg== Date: Thu, 2 Apr 2015 08:30:19 +0000 Message-ID: References: <,> <87twwzzftz.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.232] Content-Type: multipart/signed; boundary="Apple-Mail=_2D2B0045-47FF-4EAC-B143-7785BB9D41D1"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: ROLL WG , "manet@ietf.org" Subject: Re: [manet] Working group re-charter ideas (meeting summary) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 08:30:23 -0000 --Apple-Mail=_2D2B0045-47FF-4EAC-B143-7785BB9D41D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Juliusz, Just chiming in here =85 since indeed you may want to have a deeper look = into the several RFC specifying RPL. Furthermore, beyond novelty, I would stress the fact that RPL has been = deployed in a NUMBER of networks,=20 at large scale (order of magnitude is millions) and showed outstanding = results in the field, remember what the IETF thinks about =93running code=94 =85 Thanks. JP. > On Apr 2, 2015, at 9:53 AM, Pascal Thubert (pthubert) = wrote: >=20 > I disagree with the terms in your mail pretty much as much as I agree = with your designs, Juliusz... >=20 > There are literally hundreds of papers that reference RPL, from Google = scholar. >=20 > There are deployed networks of thousands of nodes, and they behave = even better than expected. >=20 > But what hurts even more is your misunderstanding of the technology: >=20 > RPL inherits from the same roots as Babel, DSDV and DUAL/EIGRP, though = RPL adds technology to cope with harsher constraints and multiple types = of links that neither Babel nor any of the common ancestry has. >=20 > You do not seem to have fully realized how similar Babel is to RPL. = Consider this: RPL's sequenced advertisement is called the iteration of = an instance; so the process of microloop avoidance in Babel is = effectively the same as what RPL calls a global recovery. Both protocols = inherit DUAL's feasibility condition. But RPL adds the capability to = make local repair which provides a service of freezing akin to the the = diffusion algorithm but adapted to LLN and MANET.=20 >=20 > Even more, RPL adds a capability to stretch the rules, and a = capability to delay the repairs so as to reduce the control overhead in = Lower Power and mobile use cases. To enable these - arguably optional - = features, RPL adds the capability to instrument packets beyond hop limit = to detect loops and trigger repairs. >=20 > Saying the RPL does not work in MANET environment is a gross = misrepresentation. RPL derives from early MANEMO work, which was MANET = for NEMO, and it was fully demonstrated in that space. RPL works fine in = MANET for the same reasons Babel will. And RPL probably works a lot = better because it can: > - cope with all sorts of radios with objective functions=20 > - allow a trade off of routing stretch vs control plane overhead=20 > - address memory constraints=20 > - natively support interconnection with LLNs > - freeze a zone and perform local repairs > - support multiple exits. RPL's instances avoid the need for = source/destination routing altogether >=20 > All in all I remain to be convinced that Babel is much, much, = anything. In my view, it is a great approach but I will need more = details to find novelty vs. an existing proposed std RFC that is RFC = 6550. You will need to demonstrate that novelty to get a new work = approved. We went through that in the first phase of ROLL. And I would = be interested in bringing back that novelty in RPL. >=20 > On the side there are multiple implementations of RPL. Some on = constrained devices. 2 on Linux, one of them at least running on OpenWRT = (Unstrung). We even have one running on various network OS'es that Cisco = ships in its big irons, and applicable from gigE to virtual links. >=20 > All in all, there's a lot of misconceptions that a discussion over a = whiteboard could help clarify. I'm certainly willing to learn more from = Babel and I trust that you'd need some catching up on RPL before you can = discuss it decently, which sadly was not the case in this mail. >=20 > I would be glad to meet anytime. We are almost next door... >=20 > Cheers, >=20 > Pascal >=20 > Le 1 avr. 2015 =E0 23:41, Juliusz Chroboczek = a =E9crit : >=20 >>> Any contribution you'd want to make to ROLL? This is probably the = place >>> where the ideas you defend in Babel were most successful... >>=20 >> I hope you are not comparing RPL's proactive subset to Babel. Babel = is >> a much, much more refined and complete protocol. >>=20 >> Which is okay, since RPL's proactive subset is designed to work in >> a stable network with a single DODAG. Babel is aimed at a completely >> different space -- which is why it has redundant routing tables, = attempts >> stability in the presence of variable metrics, has strong loop = avoidance >> properties, and includes blackhole resolution. >>=20 >> By the way -- I've tried to find experimental data on RPL, and = couldn't >> find any (perhaps I haven't tried hard enough). Could you send me = some >> references, perhaps by private mail? >>=20 >> -- Juliusz >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_2D2B0045-47FF-4EAC-B143-7785BB9D41D1 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHjCCBTAw ggQYoAMCAQICEQDVs65XZh59t2IXVyBjHIr6MA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNDExMjQwMDAwMDBaFw0xNTExMjQyMzU5NTla MCMxITAfBgkqhkiG9w0BCQEWEmp2YXNzZXVyQGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMnOoDwgfyigTrGJQkL+oeRZ/jELtw6kVKr5mYh1odj7ez8u8cPbZVsgvuLu UKGl6qjUjPd0kYgUR49lQynBhdY98L6MGHLTCtp6GIn4Ux3Kfk5lZvU/hgDveiDYbQNkYvjL2B1m vrr+lM/0E1b1qLNxRhePGy3GT0pSgi3wKfhEmUwMXayHZ3Vly0ugYH4idrBPcsBL9WNBDi7BYVCE ntzv2QVuB6fLuddurd+HAvJs7HT7NFwkS8O3sGhAmAz94yXsml9XtJEePaI0EzgXueK3bYUnYvPF rg44+v20UlVaY1+6vQYecBOXjxlOsprD+YKtGqaKew/Q7LMl4q3B070CAwEAAaOCAegwggHkMB8G A1UdIwQYMBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBS6q/3WoBmfGTrzbfUh6da/ TnTZwDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEw T6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMB0GA1Ud EQQWMBSBEmp2YXNzZXVyQGNpc2NvLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAVU6J5QAmIVAp5ErX b2t86SQefahFFBTZOdnkl//UAqsyDrxaLBLGylM4Ve8sm1UwXO645rwT+UGPBYdOI6JSMAjYgDtd DUzfASU2za3L08OSrF0uaDWc2NpTNn80jGIH5CdP/IC8op6r2ee8P9vOOyFtqz57q4SIOT/qZmNR YA2XWO1mxl3kM6UVTf37lPxkJa3FBg5U8S702Cw9wyM1oUn3DUnmhf16hDdxYYaFzIaEmTQk9QRd 5xxwTcoBMaJufdhmwwoCdWW2RmWmrNUORzYkt6Fp/Lv5KjNsOK7PLuU1VnvFqOeMj1jzWi6twhJp RfAuAqj912Sj0ykTBvWtLjCCBeYwggPOoAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcN AQEMBQAwgYUxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8g UlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1 OVowgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNB IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypVpVSR sivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYKjrc5NOpG 9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRikw8lBoNoSWY66 nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsUtQIDAQABo4IBPDCC ATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0OBBYEFIKvbIz4xf6WYXzo Hz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgw BgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9S U0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggrBgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE88 7l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3fQP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBx huhb6txM1n/y78e/4ZOs0j8CGpfb+SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77 zwbjOKkDamxlpZ4TKSDMKVmU/PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fy adqGOncjZjaaSOGTTFB+E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttN tjv7VFNYG+I31gnMrwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzg kejL580ul+9hz9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydeh zuZutLbZdRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgk L3VYnwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIDujCCA7YC AQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA1bOuV2Yefbdi F1cgYxyK+jAJBgUrDgMCGgUAoIIB4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNTA0MDIwODMwMThaMCMGCSqGSIb3DQEJBDEWBBQr/VaH5EyGtTRT/LFVKMIHsE0C kzCBvgYJKwYBBAGCNxAEMYGwMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9 MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFp bCBDQQIRANWzrldmHn23YhdXIGMcivowgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANWzrldmHn23YhdXIGMcivowDQYJKoZIhvcN AQEBBQAEggEAY9Nf87ysqjNeGbx/RgsiKw3s3PKzexAs2wOX1m7x/EbpR43g3G6xgp5PkOP3izyg 67scjvGPPTRtWu3O4Ugjb3Er6m5CLHWmVS+b+eHH3uJ1zwtPHiMyPh7m8kevqDidjARFWT3LUnAF 85l/sthcFVODcEbZmKU7+IfCphVgA+k1Lobs8OQxpkVtYxh3pDFDyB23BzhcsYI2HYdNA1+y6DoN qRNXEehC5b9oUoTMBhgK6g7M0ePV5rgTJIeAMJA9BfETDQ2piee3QwtqGevJ4epTLxsxZoDVEKeB sYa26ZP+eaWNTY09VtzcsEG0o7kKL1WMAPEQfke+WfUbYbCaJwAAAAAAAA== --Apple-Mail=_2D2B0045-47FF-4EAC-B143-7785BB9D41D1-- From nobody Thu Apr 2 05:55:36 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426251B2C9C; Thu, 2 Apr 2015 05:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 D3pHLGnZDyxL; Thu, 2 Apr 2015 05:55:33 -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 A3BC11ACED6; Thu, 2 Apr 2015 05:55:16 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t32CtCHA004285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Apr 2015 14:55:12 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id t32CtCT0029133; Thu, 2 Apr 2015 14:55:12 +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 6CDCE2A0C8D; Thu, 2 Apr 2015 14:55:12 +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 tY0YslvWqjl5; Thu, 2 Apr 2015 14:55:10 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 901212A0C8C; Thu, 2 Apr 2015 14:55:10 +0200 (CEST) Date: Thu, 02 Apr 2015 14:55:24 +0200 Message-ID: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Pascal Thubert (pthubert)" In-Reply-To: References: 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 [IPv6:2001:660:3301:8000::1:2]); Thu, 02 Apr 2015 14:55:12 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 02 Apr 2015 14:55:12 +0200 (CEST) X-Miltered: at korolev with ID 551D3C30.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 551D3C30.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551D3C30.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 551D3C30.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 : 551D3C30.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 551D3C30.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: ROLL WG , "manet@ietf.org" Subject: [manet] Understanding RPL [was: Working group re-charter ideas] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 12:55:35 -0000 Thanks for your answer, Pascal. > There are literally hundreds of papers that reference RPL, Indeed. But I've made a half-serious attempt at a bibliography search, and couldn't find anything to satisfy my thirst for experimental data, especially for the proactive subset. Could you please give me a reference? > so the process of microloop avoidance in Babel is effectively the same > as what RPL calls a global recovery. Both protocols inherit DUAL's > feasibility condition. My perhaps mistaken understanding is that RPL uses a more primitive version of DSDV's feasibility condition (without the even-odd mechanism that avoids loops after a retraction). If RPL uses DUAL feasibility, then I completely fail to see the data structure that keeps the necessary history (the equivalent of Babel's source table). (Which makes sense for RPL -- you certainly don't want to multiply the data structures being held in a sensor. Babel and RPL play in different spaces, right?) > But RPL adds the capability to make local repair which provides > a service of freezing akin to the the diffusion algorithm but adapted to > LLN and MANET. Again, I may be confused, but I think the local repair mechanism is not specified in the RFC. There's an example mechanism given in Section 3.7.2, but that example is prone to loops in the presence of packet loss. As what RPL calls a "global repair", all I could find in the RFC is A DODAG root institutes a global repair operation by incrementing the DODAGVersionNumber. This initiates a new DODAG Version. However, there's nothing I see to say when a root decides to trigger a global repair (except for some vague mention of periodic updates, which the DSDV experiment has shown are not a good idea). This is very much unlike Babel (different spaces, remember?) which has a provably complete reactive mechanism for triggering seqno updates. > Even more, RPL adds a capability to stretch the rules, and a capability to > delay the repairs so as to reduce the control overhead in Lower Power and > mobile use cases. Yes. That's probably a very good feature in the space where RPL plays. Which is different from the space that Babel aims for. > All in all I remain to be convinced that Babel is much, much, anything. That citation belongs on the conclusion slide of the next talk I give ;-) -- Juliusz From nobody Thu Apr 2 07:46:15 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED361B2D1E; Thu, 2 Apr 2015 07:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 UGmS6fa6yPzI; Thu, 2 Apr 2015 07:46:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494371B2D18; Thu, 2 Apr 2015 07:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9604; q=dns/txt; s=iport; t=1427985971; x=1429195571; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RKdgYDY1gNFp6IXuUpFrx/M8nI3M9u42FMV9Tqqpx4A=; b=jdKP/GowO6D04JFhc5Nly7gUUI7n/cMi0nIkO4hTrAboHfH5NQLulGHu IoxVMNSy0RfL+HsDj5YJVhejcEsFx0Zk8OQjMQinybO1SFFr/IWubAynx jzLtpw0u26OAdZNIUkdqXngzyH647+seuOw4X8whTfTIF9i2hxqeSsJ6q 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AEDACEVR1V/5pdJa1cgwiBM8MehHKDQAKBREwBAQEBAQF+hB4BAQEDATo/BQsCAQgOFBQQMiUCBA4NEQGIDQjOAwEBAQEBAQEDAQEBAQEBAQEaiip/hCAKHjEHgxeBFgWQaooBgRyDNIwvg0giggIcgVCBcUJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,511,1422921600"; d="scan'208";a="408665361" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 02 Apr 2015 14:46:10 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t32EkAsu017248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 14:46:10 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Thu, 2 Apr 2015 09:46:10 -0500 From: "Pascal Thubert (pthubert)" To: Juliusz Chroboczek Thread-Topic: Understanding RPL [was: Working group re-charter ideas] Thread-Index: AQHQbUREgfg7pDtvIkm1HF6A+WKgZJ05rtKQ Date: Thu, 2 Apr 2015 14:46:09 +0000 Deferred-Delivery: Thu, 2 Apr 2015 14:45:00 +0000 Message-ID: References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ROLL WG , "manet@ietf.org" Subject: Re: [manet] Understanding RPL [was: Working group re-charter ideas] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 14:46:13 -0000 Hello Juliusz:=20 > Indeed. But I've made a half-serious attempt at a bibliography search, a= nd > couldn't find anything to satisfy my thirst for experimental data, especi= ally for > the proactive subset. Could you please give me a reference? >=20 The references I'm aware of do belong to the private space of companies whi= ch make a living selling RPL devices.=20 Maybe people in the list have academic links? > > so the process of microloop avoidance in Babel is effectively the same > > as what RPL calls a global recovery. Both protocols inherit DUAL's > > feasibility condition. >=20 > My perhaps mistaken understanding is that RPL uses a more primitive versi= on of > DSDV's feasibility condition (without the even-odd mechanism that avoids = loops > after a retraction). If RPL uses DUAL feasibility, then I completely fai= l to see the > data structure that keeps the necessary history (the equivalent of Babel'= s source > table). That's all this discussion around that value L which is the smallest Rank a= node has had in a given DODAG for a given version. A DODAG gets to a number of routes as indicates by the RIO option with (pfx= ,plen) in the DIO via a root which is your router id. The router needs to maintain it value L per DODAG it has participated to. A= ll set. But there's more fun. Let me explain what's behind the text below in RPL... " Let L be the lowest Rank within a DODAG Version that a given node has advertised... A node is allowed to join any DODAG Version that it has never been a prior member of without any restrictions, but if the node has been a prior member of the DODAG Version, then it must continue to observe the rule that it may not advertise a Rank higher than L+DAGMaxRankIncrease at any point in the life of the DODAG Version. " ... I'm pretty sure you will like it: =20 - One interesting difference with Babel is that RPL can route to all nodes = with a single DODAG to a single root, using MOP 2. This gives you the absol= ute minimum amount of state, but that has a potentially large stretch when = not routing to or from the root. At the other extreme, RPL can route optima= lly to all nodes by building one DODAG per destination, using MOP 0, in whi= ch case you get roughly the same behavior as Babel. And the cool thing is t= hat RPL can build as many DODAGs as wanted between these 2 extremes. With t= his, RPL fills one of the requirement discussed at Homenet, that is the cap= ability to save resources by selectively drop state. RPL simply does that b= y NOT building MOP 0 DODAG for all destinations, and routing along other MO= P 2 DODAGs with a stretch. IOW, one can use RPL to one or more MOP 2 instan= ces, say, rooted at the edges of a stadium, and as many MOP 0 as you like t= o optimize to particular sources and sinks. All this can be done with the c= urrent spec. - Another interesting difference is that if we have 2 roots, RPL partitions= the network in 2 DODAGs. This translates into the fact that if we have 2 r= outers that expose a same destination, RPL, as opposed to Babel, does not s= uffer from a routing loop. The rule above forces a router to maintain its l= owest rank per DODAG, and the feasibility condition applies on a per-DODAG = basis with a different value of L per DODAG. Which has yet the other conseq= uence that if a node has never been in a particular DODAG, then that is en= ough feasibility condition; it can jump in with no loop. That's divide and= conquer for you, quite a key feature if you want to scale your network. > (Which makes sense for RPL -- you certainly don't want to multiply the da= ta > structures being held in a sensor. Babel and RPL play in different space= s, right?) >=20 > > But RPL adds the capability to make local repair which provides a > > service of freezing akin to the the diffusion algorithm but adapted to > > LLN and MANET. >=20 > Again, I may be confused, but I think the local repair mechanism is not s= pecified > in the RFC. There's an example mechanism given in Section 3.7.2, but tha= t > example is prone to loops in the presence of packet loss. Oh, it is specified, most certainly. Local repair is in fact a mobility-fr= iendly freezing - which is intently not DUAL's diffusion because diffusion = would not work on a MANET where some nodes may go away before the distribut= ed algorithm is complete, which would cause DUAL to lock. Local repair is d= one by either poisoning or detaching, sections 8.2.2.5. Or 8.2.2.6. Because= mobility and radio interferences may cause repeated packet loss, neither p= oisoning nor detaching is a fool proof guarantee of freezing the whole imp= acted sub-dag. So there's all that discussion, which you'll find but scanni= ng the RFC for the word poisoning. That's when a set of simple ideas turn i= nto a lot of quasi-opaque text, to the great suffering of the editor, trust= me on that. On the side, poisoning is really inheriting from IGRP, not EIG= RP.=20 > As what RPL calls a "global repair", all I could find in the RFC is >=20 > A DODAG root institutes a global repair operation by incrementing the > DODAGVersionNumber. This initiates a new DODAG Version. >=20 > However, there's nothing I see to say when a root decides to trigger a gl= obal > repair (except for some vague mention of periodic updates, which the DSDV > experiment has shown are not a good idea). This is very much unlike Babe= l > (different spaces, remember?) which has a provably complete reactive > mechanism for triggering seqno updates. =20 We voluntarily left out the trigger for a new iteration, because that can b= e largely outside the scope of the routing protocol, and for the part that = belongs to the routing protocol, it is highly dependent of the use case, ho= w frequently and for which reason you want to fire a new iteration. As you = point out, if the network has large to infinite resources, a new iteration = can be fired on any event that causes a freeze somewhere. But you rapidly f= ind that you want to delay that to save control plane, in particular if the= frozen area is not transmitting any data to that destination anyway. Then = you start thinking in terms of OSPF throttling and may get quite far, depen= ding on how constrained your network is. We went as far as allowing a confi= gurable stretch in the feasibility condition, allowing to increase the Rank= by a limited extra, which may, if you are lucky, save the day, or, if you = are unlucky, count to a very tightly controlled infinity. Because RPL has local repair, it needs a lot less global repair, which in t= urn is a great news if a new iteration is indeed a relatively costly operat= ions vs. effective traffic in the network. Note well: The base RFC only incorporates what's common to all RPL cases, that's the c= ore DV operation. Anything too specific is left to an external plug-in that= is adapted to the use case, called an objective function (OF). The bare mi= nimum OF is RFC 6552. If a particular use case has a valid reason to trigge= r a new iteration, then the OF is the place to make that decision. Arguably= , we could have documented a vector to trigger this new iteration in RFC 65= 50, and we have not. There are a number of other things that we left out, i= n a search for the bare minimum, and yet we ended with 100+ pages. But that= does not reflect the footprint of the code, which can be quite small.. And then, there are the external sources of trigger, say, an event such as = an explosion that will disrupt the network and is detected outside of the r= outing protocol. The local repairs will fail and or at best consume lots of= resources. The reactive triggers will either no get there or too many will= , in which case there will be too many iterations, too close from one anoth= er. This is when an external source -an open loop between the events and th= e routing action - can be welcome. We certainly did not start discussing su= ch a thing in the RFC. All in all I do not buy the different spaces. RPL was explicitly designed f= or multiple spaces because, by design, we left out of RPL and into the OF e= verything that's specific. You have a different space, you figure a differ= ent way to use RPL (how many DODAGs, MOP x, etc...) and you design your own= objective function if need be, tying metrics and logic to feed your partic= ular needs. This has been tried from some the smallest to some of the large= st routers on this planet, quite successfully, if you ask me. I'd say that = a MANET or a HOMENET router stand peacefully in the middle ground between t= hese extremes. > > Even more, RPL adds a capability to stretch the rules, and a > > capability to delay the repairs so as to reduce the control overhead > > in Lower Power and mobile use cases. >=20 > Yes. That's probably a very good feature in the space where RPL plays. > Which is different from the space that Babel aims for. >=20 > > All in all I remain to be convinced that Babel is much, much, anything. >=20 > That citation belongs on the conclusion slide of the next talk I give ;-) Do I get an invite? I'll be a good citizen ; )=20 After this discussion, I'm tempted to start a "RPL for not so low power los= sy networks" spec that would probably no have to specify anything much but = mostly provide guidance on how to use RPL for wired, home and MANET deploym= ents. All the best, Pascal From nobody Thu Apr 2 08:04:27 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498EA1A0161; Thu, 2 Apr 2015 06:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ylZmyh0TlPur; Thu, 2 Apr 2015 06:30:00 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0605.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::605]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61AC1A8AD7; Thu, 2 Apr 2015 06:29:56 -0700 (PDT) Received: from DB4PR06MB047.eurprd06.prod.outlook.com (10.242.154.154) by DB4PR06MB048.eurprd06.prod.outlook.com (10.242.154.155) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 2 Apr 2015 13:11:59 +0000 Received: from DB4PR06MB047.eurprd06.prod.outlook.com ([169.254.14.105]) by DB4PR06MB047.eurprd06.prod.outlook.com ([169.254.14.105]) with mapi id 15.01.0125.002; Thu, 2 Apr 2015 13:11:59 +0000 From: Yvonne-Anne Pignolet To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" Thread-Topic: [Roll] Understanding RPL [was: Working group re-charter ideas] Thread-Index: AQHQbURbA3RRxwyg40O6DMQHrMeTkJ05sPmQ Date: Thu, 2 Apr 2015 13:11:59 +0000 Message-ID: References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.75.192.109] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB048; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(13464003)(76176999)(54356999)(15975445007)(19580395003)(2656002)(122556002)(87936001)(46102003)(19580405001)(2900100001)(77156002)(102836002)(62966003)(2950100001)(33656002)(86362001)(74316001)(50986999)(66066001)(106116001)(76576001)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR06MB048; H:DB4PR06MB047.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DB4PR06MB048; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB048; x-forefront-prvs: 0534947130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ch.abb.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 13:11:59.4325 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 372ee9e0-9ce0-4033-a64a-c07073a91ecd X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB048 Archived-At: X-Mailman-Approved-At: Thu, 02 Apr 2015 08:04:19 -0700 Cc: "manet@ietf.org" Subject: Re: [manet] [Roll] Understanding RPL [was: Working group re-charter ideas] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 13:30:03 -0000 Hi Juliusz Some papers dealing with the RPL repair and loop avoidance mechanisms (and = exlaining them) are for example - A Study of the RPL Repair Process Using ContikiRPL, http://link.springer.= com/chapter/10.1007%2F978-3-642-30633-4_8 - Efficiency of the RPL repair mechanisms for Low Power and Lossy Networks,= http://ieeexplore.ieee.org/xpl/login.jsp?tp=3D&arnumber=3D6906339&url=3Dht= tp%3A%2F%2Fieeexplore.ieee.org%2Fiel7%2F6895209%2F6906315%2F06906339.pdf%3F= arnumber%3D6906339 - Doing it right - Recommendations for RPL in PLC-based networks for the Sm= art Grid, http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=3D7007= 688 - Recipes for faster failure recovery in Smart Grid communication networks,= http://ieeexplore.ieee.org/xpl/login.jsp?tp=3D&arnumber=3D7007654&url=3Dht= tp%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D7007654 Regards Yvonne-Anne -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Juliusz Chroboczek Sent: Donnerstag, 2. April 2015 14:55 To: Pascal Thubert (pthubert) Cc: ROLL WG; manet@ietf.org Subject: [Roll] Understanding RPL [was: Working group re-charter ideas] Thanks for your answer, Pascal. > There are literally hundreds of papers that reference RPL, Indeed. But I've made a half-serious attempt at a bibliography search, and= couldn't find anything to satisfy my thirst for experimental data, especia= lly for the proactive subset. Could you please give me a reference? > so the process of microloop avoidance in Babel is effectively the same=20 > as what RPL calls a global recovery. Both protocols inherit DUAL's=20 > feasibility condition. My perhaps mistaken understanding is that RPL uses a more primitive version= of DSDV's feasibility condition (without the even-odd mechanism that avoid= s loops after a retraction). If RPL uses DUAL feasibility, then I complete= ly fail to see the data structure that keeps the necessary history (the equ= ivalent of Babel's source table). (Which makes sense for RPL -- you certainly don't want to multiply the data= structures being held in a sensor. Babel and RPL play in different spaces= , right?) > But RPL adds the capability to make local repair which provides a=20 > service of freezing akin to the the diffusion algorithm but adapted to=20 > LLN and MANET. Again, I may be confused, but I think the local repair mechanism is not spe= cified in the RFC. There's an example mechanism given in Section 3.7.2, bu= t that example is prone to loops in the presence of packet loss. As what RPL calls a "global repair", all I could find in the RFC is A DODAG root institutes a global repair operation by incrementing the DODAGVersionNumber. This initiates a new DODAG Version. However, there's nothing I see to say when a root decides to trigger a glob= al repair (except for some vague mention of periodic updates, which the DSD= V experiment has shown are not a good idea). This is very much unlike Babe= l (different spaces, remember?) which has a provably complete reactive mec= hanism for triggering seqno updates. > Even more, RPL adds a capability to stretch the rules, and a=20 > capability to delay the repairs so as to reduce the control overhead=20 > in Lower Power and mobile use cases. Yes. That's probably a very good feature in the space where RPL plays. Which is different from the space that Babel aims for. > All in all I remain to be convinced that Babel is much, much, anything. That citation belongs on the conclusion slide of the next talk I give ;-) -- Juliusz _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Thu Apr 2 09:41:43 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B7D1ACE2B; Thu, 2 Apr 2015 09:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 kn3WyqSVuP0H; Thu, 2 Apr 2015 09:41:38 -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 0CB9E1B2D77; Thu, 2 Apr 2015 09:41:13 -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/56100) with ESMTP id t32GfCni009769; Thu, 2 Apr 2015 18:41:12 +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 6CD382A0C75; Thu, 2 Apr 2015 18:41:12 +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 rO0xPPGH0Xld; Thu, 2 Apr 2015 18:41:10 +0200 (CEST) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D3C0A2A0C6D; Thu, 2 Apr 2015 18:41:10 +0200 (CEST) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.84) (envelope-from ) id 1YdiB4-0002Q5-Hw; Thu, 02 Apr 2015 18:41:10 +0200 Date: Thu, 02 Apr 2015 18:41:10 +0200 Message-ID: <7ipp7m7aah.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Routing Over Low power and Lossy networks In-Reply-To: References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> 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]); Thu, 02 Apr 2015 18:41:12 +0200 (CEST) X-Miltered: at korolev with ID 551D7128.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551D7128.000 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 : 551D7128.000 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: "manet@ietf.org" Subject: Re: [manet] [Roll] Understanding RPL [was: Working group re-charter ideas] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:41:40 -0000 > Some papers dealing with the RPL repair and loop avoidance mechanisms > (and exlaining them) are for example Thanks for the references, Yvonne-Anne. I'll have a look as soon as I find out whether we still have access to IEEE-paywalled articles (budget cuts, so I'm no longer sure we do). However -- some of the abstracts are not entirely clear, but it looks like it's all simulation work. Do you have any experimental data? -- Juliusz From nobody Thu Apr 2 16:41:58 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB381A885C; Thu, 2 Apr 2015 16:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] autolearn=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 6OcZdPCGPujD; Thu, 2 Apr 2015 16:41:47 -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 87ECF1A8855; Thu, 2 Apr 2015 16:41:47 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t32Nff9X020767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2015 01:41:41 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id t32Nfff0002820; Fri, 3 Apr 2015 01:41:41 +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 127492A0C5D; Fri, 3 Apr 2015 01:41:41 +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 x2lbq997fUqd; Fri, 3 Apr 2015 01:41:39 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C10982A0C00; Fri, 3 Apr 2015 01:41:38 +0200 (CEST) Date: Fri, 03 Apr 2015 01:41:53 +0200 Message-ID: <87fv8i85dq.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Pascal Thubert (pthubert)" In-Reply-To: References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> 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 [IPv6:2001:660:3301:8000::1:2]); Fri, 03 Apr 2015 01:41:41 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 03 Apr 2015 01:41:41 +0200 (CEST) X-Miltered: at korolev with ID 551DD3B5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 551DD3B5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551DD3B5.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 551DD3B5.000 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 : 551DD3B5.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 551DD3B5.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: ROLL WG , "manet@ietf.org" Subject: Re: [manet] Understanding RPL [was: Working group re-charter ideas] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 23:41:55 -0000 Thanks a lot for the lengthy explanation, Pascal, I feel that I understand RPL somewhat better now. >> My perhaps mistaken understanding is that RPL uses a more primitive >> version of DSDV's feasibility condition > That's all this discussion around that value L Ah, I see. Section 8.2.2.4.3. (I'm not apologising for missing it -- it is well hidden.) Yes, that looks like DUAL-feasibility, but weakened so that loops of diameter DAGMaxRankIncrease or less are allowed, right? Why the weakening? Is that to compensate for the fact that you don't have a mechanism to resolve blackholes in a timely manner? > A node is allowed to join any DODAG Version that it has never been a > prior member of without any restrictions, but if the node has been a > prior member of the DODAG Version, then it must continue to observe > the rule that it may not advertise a Rank higher than > L+DAGMaxRankIncrease at any point in the life of the DODAG Version. Yeah, that's pretty clear. The same is true of Babel. > One interesting difference with Babel is that RPL can route to all nodes > with a single DODAG to a single root, using MOP 2. Yes, I've noticed this mechanism before. I think that's a smart mechanism (I much prefer it to MOP 1), and I trust you've evaluated its performance carefully, at least for some OF. However, that's definitely not something I'd ever consider adding to Babel -- I have a very strong desire to keep the base protocol small, and to make sure that all extended variants can interoperate as long as they implement the base protocol correctly. You see -- once again, we're aiming at two different application spaces. You're thinking of sensor networks, where it is reasonable to require that all nodes in a given network implement MOP 2. Babel is aimed at home and hybrid networks (cash-starved networks with some meshy bits), which tend to grow organically, with routers that never get reflashed, and therefore contain different variants of the protocol. > Another interesting difference is that if we have 2 roots, RPL > partitions the network in 2 DODAGs. Sorry if I'm being slow, but I don't see how that can be true. If you have R1 R2 /\ / \ A B and there is instability in the network, so that simultaneously A switches to B as parent, and B switches to R2 while its retraction ("poison") gets lost, what prevents A from having B as parent while believing it's still in R1's DODAG? > Local repair is done by either poisoning or detaching, sections > 8.2.2.5. I don't see how that can be implemented. Suppose A is B's parent. A advertises INFINITE_RANK. A's retraction ("poison") is lost. B has no reason to change parents, so B has a parent with infinite rank. Oops, B is just violating the MUST NOT in 8.2.2.5.2. Are you assuming the network is reliable? Or am I missing some mechanism that prevents that from happening? > Or 8.2.2.6. That's just a variant of the above but advertising DIO instead of a retraction, right? > On the side, poisoning is really inheriting from IGRP, It's been a long time since I looked at IGRP, but I seem to recall that it avoids the issue I describe above by imposing a silent time after a metric increase. This causes temporary blackholes, of course, of up to 3 minutes if memory serves. > We voluntarily left out the trigger for a new iteration, because that > can be largely outside the scope of the routing protocol, I disagree with that, at least in the space for which Babel is aiming. > All in all I do not buy the different spaces. RPL was explicitly > designed for multiple spaces because, by design, we left out of RPL and > into the OF everything that's specific. Well, the space Babel aims for requires that implementations from different vendors interoperate. That requires putting a provably complete set of "must implement" mechanisms in the base spec. I don't believe that RPL has that property. > Do I get an invite? Sure, I'll try to remember to send you a note when I next give a seminar. -- Juliusz From nobody Thu Apr 2 23:15:09 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41D31A90EA; Thu, 2 Apr 2015 23:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 y8tNgyey4n-K; Thu, 2 Apr 2015 23:15:00 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::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 6EABD1A90E6; Thu, 2 Apr 2015 23:15:00 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so129778057wib.1; Thu, 02 Apr 2015 23:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=D33FOWdMqLNR5MnDvAqflPy3nbeS3WTG5xZ/g/vC94g=; b=ZLwUVljpz0xyqOBgymDlKwFpG0I/pcBe+ixTSpbp4zBBr9sNJZNwwZyZam0FrF6LI3 CaXPS40kpphMBuAUq9kC0XWifEVZk568Xk4eyRjZUcSwCikJnunYqelHG96Hm3Hz6orn CjltpkDBGz3dpxU6VZxF7wxK9+mGFAWZTMra5eWBe4z8xx08vo5b+pkV2VY1kja6Z9V9 2B+Bx4KPmnUDbVgSoj4iJK3+kbKnLMqo8drtNgNj3iV4sEkZDlAA7sZhI6DDOkKGm1lh L6ykLFVqtqUy2boVeS1ht8lYxDF+PSMs755t3SSpl6kQqVFca0sbrOY7LTk2qYgD2oOj kNzA== X-Received: by 10.194.123.67 with SMTP id ly3mr1729498wjb.105.1428041699243; Thu, 02 Apr 2015 23:14:59 -0700 (PDT) Received: from [192.168.1.58] ([95.91.215.14]) by mx.google.com with ESMTPSA id ga8sm1363330wib.11.2015.04.02.23.14.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 23:14:58 -0700 (PDT) Message-ID: <551E2FE1.4000509@gmail.com> Date: Fri, 03 Apr 2015 08:14:57 +0200 From: =?windows-1252?Q?Cenk_G=FCndogan?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Juliusz Chroboczek References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> <87fv8i85dq.wl-jch@pps.univ-paris-diderot.fr> In-Reply-To: <87fv8i85dq.wl-jch@pps.univ-paris-diderot.fr> Content-Type: multipart/alternative; boundary="------------090302050807060109070603" Archived-At: Cc: Routing Over Low power and Lossy networks , "manet@ietf.org" Subject: Re: [manet] [Roll] Understanding RPL [was: Working group re-charter ideas] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 06:15:08 -0000 This is a multi-part message in MIME format. --------------090302050807060109070603 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello Juliusz, On 03.04.2015 01:41, Juliusz Chroboczek wrote: >> Local repair is done by either poisoning or detaching, sections >> 8.2.2.5. > I don't see how that can be implemented. > > Suppose A is B's parent. A advertises INFINITE_RANK. A's retraction > ("poison") is lost. B has no reason to change parents, so B has a parent > with infinite rank. Oops, B is just violating the MUST NOT in 8.2.2.5.2. > > Are you assuming the network is reliable? Or am I missing some mechanism > that prevents that from happening? I also did struggle with this scenario for quite some time. However, there are several places in the RFC that specifically deal (directly or indirectly) with this issue. 8.2.2.5 . Poisoning 1. A node poisons routes by advertising a Rank of INFINITE_RANK. 2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in its parent set. My interpretation of these bullet points is that DIOs advertising INFINITE_RANK are sent out periodically (probably in a decaying fashion via Trickle), in order to reduce the chance that these DIOs stay unnoticed. However, this might not be a complete solution, as all DIOs from A to B can become lost thus leading to the same problem, but then the RFC states that links should be guaranteed to be symmetric anyways, e.g. by using NUD [1] or other alternatives. Something else I want to mention is that RPL utilizes a few lifetime counters (e.g. for the dodag or route), which would also help in this scenario (We wouldn't refresh the lifetime of a node with INFINITE_RANK, would we?), but admittedly, depending on the specified lifetime values, in a very sluggish way. At last, it is important to remember that RPL uses data-path validation to reduce the chattiness of control packets, described in [2] and most likely realized by using [3]. In that case A can reset its Trickle timer when encountering inconsistencies and start e.g. another poisoning routine by sending out another set of INFINITE_RANK DIOs. Best, Cenk [1] Neighbor Unreachability Detection (https://tools.ietf.org/html/rfc2461#page-66) [2] https://tools.ietf.org/html/rfc6550#section-3.2.7 [3] https://tools.ietf.org/html/rfc6553 --------------090302050807060109070603 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Hello Juliusz,

On 03.04.2015 01:41, Juliusz Chroboczek wrote:
Local repair is done by either poisoning or detaching, sections
8.2.2.5.

I don't see how that can be implemented.

Suppose A is B's parent.  A advertises INFINITE_RANK.  A's retraction
("poison") is lost.  B has no reason to change parents, so B has a parent
with infinite rank.  Oops, B is just violating the MUST NOT in 8.2.2.5.2.

Are you assuming the network is reliable?  Or am I missing some mechanism
that prevents that from happening?

I also did struggle with this scenario for quite some time.
However, there are several places in the RFC that specifically deal (directly or indirectly) with this issue.

8.2.2.5.  Poisoning


   1.  A node poisons routes by advertising a Rank of INFINITE_RANK.

   2.  A node MUST NOT have any nodes with a Rank of INFINITE_RANK in
       its parent set.

My interpretation of these bullet points is that DIOs advertising INFINITE_RANK are sent out periodically
(probably in a decaying fashion via Trickle), in order to reduce the chance that these DIOs stay unnoticed.
However, this might not be a complete solution, as all DIOs from A to B can become lost thus leading to the same problem,
but then the RFC states that links should be guaranteed to be symmetric anyways, e.g. by using NUD [1] or other alternatives.

Something else I want to mention is that RPL utilizes a few lifetime counters (e.g. for the dodag or route),
which would also help in this scenario (We wouldn't refresh the lifetime of a node with INFINITE_RANK, would we?),
but admittedly, depending on the specified lifetime values, in a very sluggish way.

At last, it is important to remember that RPL uses data-path validation to reduce the chattiness of control packets,
described in [2] and most likely realized by using [3].
In that case A can reset its Trickle timer when encountering inconsistencies and start e.g. another poisoning routine
by sending out another set of INFINITE_RANK DIOs.

Best,
Cenk

[1] Neighbor Unreachability Detection (https://tools.ietf.org/html/rfc2461#page-66)
[2] https://tools.ietf.org/html/rfc6550#section-3.2.7
[3] https://tools.ietf.org/html/rfc6553
--------------090302050807060109070603-- From nobody Fri Apr 3 01:51:13 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF661A1A97; Fri, 3 Apr 2015 01:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 uzZiZCJI0zEq; Fri, 3 Apr 2015 01:51:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083B51A1AB8; Fri, 3 Apr 2015 01:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13668; q=dns/txt; s=iport; t=1428051067; x=1429260667; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wgzVv6AkODcB2nvkvxfhuUF7r7KJeKnPxWq7pTrMkV0=; b=hwMk3xW8u7DHzSj3fcTB4wOI2EZrNjxytlT9wgFu+SseI9barXCvJWlo W+QY7Kwaiu+IxqyUREdiBJkXjYBphgab/VAjpDZsVowE4fs3D1xnCN7Aa 2sU342URqHabHxTiJ1IEwXSxCOZTZNDvJNM5PVx5qdFvyrMEi3XXsW40c E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B3CADIUx5V/5tdJa1cgwtSXMMwgjYBCYV9AoErTAEBAQEBAX6EHwEBBAEBAWsLEAIBCD8HIQYLFBECBA4FG4gAAxENxwcNhTIBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIoqf4JHgi4EB4MXgRYFinGFeYN1gQdhP4IXgU2BHYYVhmqGLyKCAxyBUG8BAQGBASSBGwEBAQ X-IronPort-AV: E=Sophos;i="5.11,516,1422921600"; d="scan'208,217";a="408921930" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 03 Apr 2015 08:51:06 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t338p5Nq009789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Apr 2015 08:51:05 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.104]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 3 Apr 2015 03:51:04 -0500 From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?Cenk_G=FCndogan?= Thread-Topic: [manet] [Roll] Understanding RPL [was: Working group re-charter ideas] Thread-Index: AQHQbdWN0AgUGz00DUugxuEkjZWsNZ06+vex Date: Fri, 3 Apr 2015 08:51:04 +0000 Message-ID: <7F8D39C7-E757-43F2-BD04-AB2B602B133D@cisco.com> References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> <87fv8i85dq.wl-jch@pps.univ-paris-diderot.fr>,<551E2FE1.4000509@gmail.com> In-Reply-To: <551E2FE1.4000509@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7F8D39C7E75743F2BD04AB2B602B133Dciscocom_" MIME-Version: 1.0 Archived-At: Cc: Routing Over Low power and Lossy networks , "manet@ietf.org" , Juliusz Chroboczek Subject: Re: [manet] [Roll] Understanding RPL [was: Working group re-charter ideas] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 08:51:11 -0000 --_000_7F8D39C7E75743F2BD04AB2B602B133Dciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You pretty much have it all, Cenk, I thank you for this great explanation. Let me observe a few things: One is that poisoning gives you only half of the value of detaching since d= etaching maintains connectivity within the detached DODAG, which is a usefu= l consideration in A MANET situation. This mode is an inheritance from MANE= MO where we were looking for the minimal topological awareness so as to ens= ure maximum resilience to swarming in a highly mobile situation. Second is that both RPL methods derive from the desire of getting a similar= service as the diffusion algorithm in DUAL/EIGRP, but in a MANET situatio= n where connectivity is uncertain and the real diffusion algorithm is doome= d to fail. We had to adapt to the real world and its statistical behavior, and had to = cover for the exception, which RPL does as you describe. So DUAL was replac= ed with a trickle-based diffusion, and the packets were instrumented beyond= hop count to detect and fix the anomalies. There was ample simulation work that showed the value for traffic continuit= y vs. plain black holing (till the next sequence is advertised). Same goes = for the stretch to the feasibility condition. Now if you disable those functionalities - arguably in a rather fast and st= able network - , and you make one mop0 DODAG per router in one instance, yo= u get something that is highly similar to BABEL - and that is no magic. And= in that, BABEL is less than EIGRP, but arguably, for that same reason, EIG= RP is not applicable to MANET. If you make that 2 instances, you can select the Homenet multi homed GW wit= hout the need for source/destination routing. If you add the option of P2P RPL you probably get a reactive DV in the clos= e family of AODV. RPL aggregated the quintessence of classical DV with the best knowledge of = people applying DV to mobility (MANEMO/ NINA), and of those applying it to = sensors (such as CTP and multiple proprietary solutions from WSN vendors). At the same time, RPL kept out anything specific to a particular type of us= e case - metrics, logic, policies. One really creates a solution by choosin= g his own objective function. It can be said that RFC 6550 is generic and t= hat the application of an OF creates an instance which is the real routing = protocol. The text is arguably hard to read. Part of that came from the aggregation process over 19 rounds of the draft.= I'm afraid that if we pass the BABEL RFC through the WG process, one will = hardly recognize it in the end, even if we manage to preserve the basic ope= rations. Another reason is that we had to strip all the why's and focus on specifyin= g observable behaviors. That is certainly not how one would write a book or= a paper. I'm afraid that what makes BABEL such a great read today will be = lost if the same process is applied. Cheers, Pascal Le 3 avr. 2015 =E0 08:15, Cenk G=FCndogan > a =E9crit : Hello Juliusz, On 03.04.2015 01:41, Juliusz Chroboczek wrote: Local repair is done by either poisoning or detaching, sections 8.2.2.5. I don't see how that can be implemented. Suppose A is B's parent. A advertises INFINITE_RANK. A's retraction ("poison") is lost. B has no reason to change parents, so B has a parent with infinite rank. Oops, B is just violating the MUST NOT in 8.2.2.5.2. Are you assuming the network is reliable? Or am I missing some mechanism that prevents that from happening? I also did struggle with this scenario for quite some time. However, there are several places in the RFC that specifically deal (direct= ly or indirectly) with this issue. 8.2.2.5. Poisoning 1. A node poisons routes by advertising a Rank of INFINITE_RANK. 2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in its parent set. My interpretation of these bullet points is that DIOs advertising INFINITE_= RANK are sent out periodically (probably in a decaying fashion via Trickle), in order to reduce the chance= that these DIOs stay unnoticed. However, this might not be a complete solution, as all DIOs from A to B can= become lost thus leading to the same problem, but then the RFC states that links should be guaranteed to be symmetric any= ways, e.g. by using NUD [1] or other alternatives. Something else I want to mention is that RPL utilizes a few lifetime counte= rs (e.g. for the dodag or route), which would also help in this scenario (We wouldn't refresh the lifetime of= a node with INFINITE_RANK, would we?), but admittedly, depending on the specified lifetime values, in a very slugg= ish way. At last, it is important to remember that RPL uses data-path validation to = reduce the chattiness of control packets, described in [2] and most likely realized by using [3]. In that case A can reset its Trickle timer when encountering inconsistencie= s and start e.g. another poisoning routine by sending out another set of INFINITE_RANK DIOs. Best, Cenk [1] Neighbor Unreachability Detection (https://tools.ietf.org/html/rfc2461#= page-66) [2] https://tools.ietf.org/html/rfc6550#section-3.2.7 [3] https://tools.ietf.org/html/rfc6553 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_7F8D39C7E75743F2BD04AB2B602B133Dciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You pretty much have it all, Cenk, I thank you for this great explanat= ion.

Let me observe a few things:

One is that poisoning gives you only half of the value of detaching si= nce detaching maintains connectivity within the detached DODAG, which is a = useful consideration in A MANET situation. This mode is an inheritance from= MANEMO where we were looking for the minimal topological awareness so as to ensure maximum resilience to sw= arming in a highly mobile situation.

Second is that both RPL methods derive from the desire of getting a si= milar service as the diffusion algorithm  in DUAL/EIGRP, but in a MANE= T situation where connectivity is uncertain and the real diffusion algorith= m is doomed to fail. 

We had to adapt to the real world and its statistical behavior, and ha= d to cover for the exception, which RPL does as you describe. So DUAL was r= eplaced with a trickle-based diffusion, and the packets were instrumented b= eyond hop count to detect and fix the anomalies. 

There was ample simulation work that showed the value for traffic cont= inuity vs. plain black holing (till the next sequence is advertised). Same = goes for the stretch to the feasibility condition.

Now if you disable those functionalities - arguably in a rather fast a= nd stable network - , and you make one mop0 DODAG per router in one instanc= e, you get something that is highly similar to BABEL - and that is no magic= . And in that, BABEL is less than EIGRP, but arguably, for that same reason, EIGRP is not applicable to MANE= T.

If you make that 2 instances, you can select the Homenet multi homed G= W without the need for source/destination routing.

If you add the option of P2P RPL you probably get a reactive DV in the clos= e family of AODV.

RPL aggregated the quintessence of classical DV with the best knowledg= e of people applying DV to mobility (MANEMO/ NINA), and of those applying i= t to sensors (such as CTP and multiple proprietary solutions from WSN vendo= rs).

At the same time, RPL kept out anything specific to a particular type = of use case - metrics, logic, policies. One really creates a solution by ch= oosing his own objective function. It can be said that RFC 6550 is generic = and that the application of an OF creates an instance which is the real routing protocol.

The text is arguably hard to read.

Part of that came from the aggregation process over 19 rounds of the d= raft. I'm afraid that if we pass the BABEL RFC through the WG process, one = will hardly recognize it in the end, even if we manage to preserve the basi= c operations. 

Another reason is that we had to strip all the why's and focus on spec= ifying observable behaviors. That is certainly not how one would write a bo= ok or a paper. I'm afraid that what makes BABEL such a great read today wil= l be lost if the same process is applied.

Cheers,

Pascal

Le 3 avr. 2015 =E0 08:15, Cenk G=FCndogan <cnkgndgn@gmail.com> a =E9crit :

Hello Juliusz,

On 03.04.2015 01:41, Juliusz Chroboczek wrot= e:
Local repair is done by either poisoning or detaching, secti=
ons
8.2.2.5.

I don't see how that can be implemented.

Suppose A is B's parent.  A advertises INFINITE_RANK.  A's retraction
("poison") is lost.  B has no reason to change parents, so B has =
a parent
with infinite rank.  Oops, B is just violating the MUST NOT in 8.2.2.5.2.

Are you assuming the network is reliable?  Or am I missing some mechanism
that prevents that from happening?

I also did struggle with this scenario for quite some time.
However, there are several places in the RFC that specifically deal (direct= ly or indirectly) with this issue.

8.2.2.5.  Poisoning

   1.  A node poisons routes by advertising a Rank of INFINITE_RANK.

   2.  A node MUST NOT have any nodes with a Rank of INFINITE_RANK in
       its parent set.

My interpretation of these bullet points is that DIOs advertising INFINITE_= RANK are sent out periodically
(probably in a decaying fashion via Trickle), in order to reduce the chance= that these DIOs stay unnoticed.
However, this might not be a complete solution, as all DIOs from A to B can= become lost thus leading to the same problem,
but then the RFC states that links should be guaranteed to be symmetric any= ways, e.g. by using NUD [1] or other alternatives.

Something else I want to mention is that RPL utilizes a few lifetime counte= rs (e.g. for the dodag or route),
which would also help in this scenario (We wouldn't refresh the lifetime of= a node with INFINITE_RANK, would we?),
but admittedly, depending on the specified lifetime values, in a very slugg= ish way.

At last, it is important to remember that RPL uses data-path validation to = reduce the chattiness of control packets,
described in [2] and most likely realized by using [3].
In that case A can reset its Trickle timer when encountering inconsistencie= s and start e.g. another poisoning routine
by sending out another set of INFINITE_RANK DIOs.

Best,
Cenk

[1] Neighbor Unreachability Detection (https://tools.ietf.org/= html/rfc2461#page-66)
[2] https://tools.ietf.org/html/rfc6550#section-3.2.7
[3] https://tools.ietf.org/html/rfc6553
_______________________________________________
manet mailing list
manet@ietf.org
https://www.i= etf.org/mailman/listinfo/manet
--_000_7F8D39C7E75743F2BD04AB2B602B133Dciscocom_-- From nobody Fri Apr 3 02:59:26 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950A51A6F13; Fri, 3 Apr 2015 02:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] autolearn=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 do8GuCX7hqvD; Fri, 3 Apr 2015 02:59:24 -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 A66431A6F5D; Fri, 3 Apr 2015 02:59:23 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56100) with ESMTP id t339xL5f014106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Apr 2015 11:59:21 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/56228) with ESMTP id t339xLCR000350; Fri, 3 Apr 2015 11:59:21 +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 802B92A0C60; Fri, 3 Apr 2015 11:59:21 +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 L2zuLz0HTkDe; Fri, 3 Apr 2015 11:59:20 +0200 (CEST) Received: from pirx.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id E7B202A0C02; Fri, 3 Apr 2015 11:59:19 +0200 (CEST) Date: Fri, 03 Apr 2015 11:59:34 +0200 Message-ID: <87ego1zg55.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Cenk =?ISO-8859-1?Q?G=FCndogan?= In-Reply-To: <551E2FE1.4000509@gmail.com> References: <87pp7mlmf7.wl-jch@pps.univ-paris-diderot.fr> <87fv8i85dq.wl-jch@pps.univ-paris-diderot.fr> <551E2FE1.4000509@gmail.com> 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 [IPv6:2001:660:3301:8000::1:2]); Fri, 03 Apr 2015 11:59:21 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Fri, 03 Apr 2015 11:59:21 +0200 (CEST) X-Miltered: at korolev with ID 551E6479.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 551E6479.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 551E6479.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 551E6479.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 : 551E6479.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 551E6479.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Cc: Routing Over Low power and Lossy networks , "manet@ietf.org" Subject: Re: [manet] [Roll] Understanding RPL [was: Working group re-charter ideas] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 09:59:24 -0000 >>> Local repair is done by either poisoning or detaching, section 8.2.2.5. >> I don't see how that can be implemented. >> >> Suppose A is B's parent. A advertises INFINITE_RANK. A's retraction >> ("poison") is lost. B has no reason to change parents, so B has a parent >> with infinite rank. Oops, B is just violating the MUST NOT in 8.2.2.5.2. > I also did struggle with this scenario for quite some time. > However, there are several places in the RFC that specifically deal > (directly or indirectly) with this issue. I'm afraid I don't understand your answer. Could you please tell me exactly what happens in the scenario I've described above? -- Juliusz From nobody Fri Apr 3 12:32:19 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AE51A01AE for ; Fri, 3 Apr 2015 12:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zCzG8ff8hGwk for ; Fri, 3 Apr 2015 12:32:10 -0700 (PDT) Received: from nm47-vm9.bullet.mail.bf1.yahoo.com (nm47-vm9.bullet.mail.bf1.yahoo.com [216.109.114.218]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 815421A0191 for ; Fri, 3 Apr 2015 12:32:10 -0700 (PDT) Received: from [98.139.215.142] by nm47.bullet.mail.bf1.yahoo.com with NNFMP; 03 Apr 2015 19:32:09 -0000 Received: from [98.139.212.233] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 03 Apr 2015 19:32:09 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 03 Apr 2015 19:32:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 782026.99153.bm@omp1042.mail.bf1.yahoo.com Received: (qmail 20088 invoked by uid 60001); 3 Apr 2015 19:32:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1428089529; bh=Cy5PpxvMfVaoCjgpRwzPD+w5MwGPoh0W5IIKPNBBcWY=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0WURCa6/vYJ1sK81jkNc+g+vHX+s5Mx7XZ4ra8H5gxCaOPcE/mZdoTm2xVjiXxyzjMOb5JnrZr4ga6AMtdkAbG6HFIPLEEqAtDpdIJNYbUUn8HGHCxx/AOhS3WFrrcRcqDOXFNiXk3ygZvkB7CZ4tW+Y90sxKo97tSvD8To+6lY= X-YMail-OSG: RtFWE7gVM1lZyX7xn83h8_7yvLI3MLbMHmIeLEgD4MhppQL eXsX8majLsgP17nnYkl_AUoFetcB0fLI2Mto3NbcqYeePZlO6.FJo5WpPQYU 7fk5o0YwpaX8kTL.ni3Ts4jrMdlvhOaHyDjow0GqNF1pj0fB19ZRKqrd7qRB G5lW1y_OVTUda8orC7pAOElZ9KlqVIGX8f9cq41V8mFNIRDt5da4WHXuW8Uy z4atzw..my7Or7PcSnBUdQIGFieSuht4r98QyQ6tlEz6DFsrWH8wDgqvTLe0 JUKNZW7ojMPEgU7br8OWFu6HE095nIPLSWY0Bi5yX2mdGkSIK5C8u6.sLPPj BHWn2gIdZZlAZgvthC9g5yKqbWKVH1O.YKOhJwGbMkJJVr5psWmkWhK0Z2Wc 1TDAPcL6dAzRCHp6SD6whlffDxIlrpV1CcQaBLrpk6YBYPj8zjb6sDq9WT86 lHXYlV1LsKKzqDcX6wEchg55k1Z1G.nL_1Om4W1nNNbtcD.wnW2EHSgTNFZR fkDSkZj4OYHlG4TV6aUqK8utH2U.yPwErXZnJVZI4pAvqJUe5L9cGZOKITka W5jPliXZG Received: from [174.62.202.123] by web400005.mail.bf1.yahoo.com via HTTP; Fri, 03 Apr 2015 12:32:09 PDT X-Rocket-MIMEInfo: 002.001, Q2hyaXN0b3BoZXIsDQoNCldlIGV4cGxhaW5lZCBib3RoIGluIG91ciBkcmFmdCAoSW50cm8gYW5kIHNlY3Rpb24gMykgdGhhdCB0aGUgcHVycG9zZSBvZiBDTDMgaXMgdG8gc2VsZWN0IGludGVsbGlnZW50bHksDQpmcm9tIGFsbCBwb3RlbnRpYWwgZW5kcG9pbnRzIGluIHRoZSBNQU5FVCwgYSAiZ29vZCIgc2V0IG9mIE9TUEYgcGVlcnMgdG8gcHJlc2VudCB0byBpdHMgYXR0YWNoZWQgcm91dGVyLg0KDQpUaGUgc2VsZWN0aW9uIGlzIGJhc2VkIG9uIHdoYXRldmVyIGFsZ29yaXRobSB0aGUgQ0wzIG5vZGUgaXMBMAEBAQE- X-Mailer: YahooMailClassic/452 YahooMailWebService/0.8.203.740 Message-ID: <1428089529.62164.YahooMailBasic@web400005.mail.bf1.yahoo.com> Date: Fri, 3 Apr 2015 12:32:09 -0700 From: JS To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] draft-shaio-manet-common-l3-interface X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 19:32:15 -0000 Christopher, We explained both in our draft (Intro and section 3) that the purpose of CL= 3 is to select intelligently, from all potential endpoints in the MANET, a "good" set of OSPF peers to pr= esent to its attached router. The selection is based on whatever algorithm the CL3 node is using; coordin= ation among different CL3 nodes is not required nor do they have to use the same algorithm. This avoids presenting all potential OSPF peers to the router, as would hap= pen in the case you describe below. The advantage is that MANET nodes can be expected to have intermitte= nt connectivity as they move, so if all of them were OSPF peers, we would see OSPF adjacencies constantly= being brought up and then brought down. An intermediate algorithm operating before the router can fil= ter out potential nodes on the MANET that have show recent intermittent connectivity; we cannot expect mos= t commercial IP routers to have implemented protocols from the MANET WG or to supplement them with alg= orithms like these. Our draft presents results with and without such an algorithm; without mean= s all potential OSPF peers are presented to the router, as would happen in the case you described. The second key point is that CL3 adapts to work with any typical IP router = and with any MANET. This is important because very few commercial IP router models have implemented DLE= P and because many MANETs are in use that have not been defined by the MANET working group. We= defined a mechanism that adapts to work with both of these and described results using a public= ly-released MANET (OLSRv1). thanks, =A0 =A0=A0=A0Jack Shaio Date: Wed, 1 Apr 2015 11:37:25 +0000 From: "Dearlove, Christopher (UK)" Subject: Re: [manet] draft-shaio-manet-common-l3-interface Message-ID: =A0=A0=A0 Content-Type: text/plain; charset=3D"us-ascii" =20 Jack Shaio > I believe the Local Attached Network set from OLSRv2 will only inform OLSRv2 of other interfaces that do not run this protocol. > But this will not inform IP at the router of potential OSPF peers across the MANET, which is what our CL3 interface is for. =20 That's mixing up two things. =20 The Local Attached Network Set is in input into OLSRv2 from its environment. OLSRv2's use for it is to propagate it across the network to inform other routers' Attached Network Sets (no Local) which in turn inform the Routing Set. OLSRv2 supplies the Routing Set to its environment which, typically, uses it to set the local IP routing table. What matters about other routers across the MANET for simple routing is in the Routing Set. (The Attached Network Set may be accessible e.g. using a MIB.) =20 So IP at the router knows about other routers across the network in terms of how to route to them. It even has metric information about them, in OLSRv2 terms (which includes a term specific to the attached network). It doesn't (unmodified) know whether an attached network is just hosts, or another network running OSPF or any other alternative. The assumed model is that each network takes care of its only internal details, network A does not need the internal details of network B. That's the basic Internet approach. The question that I don't think is clear to anyone here is your use case and why it differs from that model. From nobody Fri Apr 3 12:44:20 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DFA1A026C for ; Fri, 3 Apr 2015 12:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hlG-VgNOAnTn for ; Fri, 3 Apr 2015 12:44:17 -0700 (PDT) Received: from nm39-vm3.bullet.mail.bf1.yahoo.com (nm39-vm3.bullet.mail.bf1.yahoo.com [72.30.239.147]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599B31A0263 for ; Fri, 3 Apr 2015 12:44:17 -0700 (PDT) Received: from [98.139.215.141] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 03 Apr 2015 19:44:16 -0000 Received: from [98.139.212.241] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 03 Apr 2015 19:44:16 -0000 Received: from [127.0.0.1] by omp1050.mail.bf1.yahoo.com with NNFMP; 03 Apr 2015 19:44:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 977786.78020.bm@omp1050.mail.bf1.yahoo.com Received: (qmail 18534 invoked by uid 60001); 3 Apr 2015 19:44:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1428090255; bh=LTS+qQsZyiE66/L4F4960J7mLwroHpPvbEUtf8peYO4=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4KWRsdvYo+A+d4ZYVycLW4x7JtbPy8NacZkxoKJqq7+zOREfApYuD8sJPyuYnxTExyzTK4phOLUOCR7mIOSvbuinTViQy5FIdfd6B4xi3O5We+NGtcgZyjigJJ7+51p3y3+LgefSq0xSZWo1/yYjqASM1mcXdQ66DFWwbwoz29w= X-YMail-OSG: zzJCvpAVM1lv_2Vbo31LxLTA_ZKXKfhWMEdO.gRNp7S0C4a lBl.tGjRI_LxBt87w.ZC5FaG9ibOVjAEhy3cKHZCoJNpSCjjlNZR5jxb8rQs z8R5B4KEYCtc0UY6H_9jUvFSE3IBVzkleULqk2GyeXAxrWOIv5aI8no8zfBN uo02.frKZnuGhhLo0sWR7fj.hdfOssrKx_yA_DFrzDddZWKjdlFBPolAujVA X_Ck_sXBHKSVAbrf3KexrEIdd9pkNqFxxRjZqEmzHbfrjLR75oiAazPm6ptC 9LAGYFzi6eC2KZY14_6XJ6j_vYGIm6othja1rTZwcim6e6r9cuNtrwUH1S48 pxQyacwQssJqI0Od70JyFm2ikLNecfvf8Tet7L9B93e08ERmqPjI3PkZi7AF vRKnB3W0mT1WeMQz2y54J7LDvSYQ9NAX_40w98sodK4gz4oCd1_ok5nMwqct X82UzBc9UQfP1F97xuBWUYrV6mW2fpgcgw.7cQ9AJG5lDs.bc_UnddoVYK7o h78O00hprQIDSz_Uq3YHir9.SmBmg9Y.KvefZX_ERpcICbP8fs.25HnPtnGq JCoaGV.YzIzJ22XTzjRr54ErW9I731xnUVdVKgxPxkQVbMAHH7pR7LNoWdm1 ObHKP11WpQTgvcjiPSz4RzKEHiUZBqWyF3CWmPo3T.x_BKUTsYSrZ7Sgwwms 2MXrWf5O2QXn2snb96ankHAPYtqKEWUp4_DgV Received: from [174.62.202.123] by web400004.mail.bf1.yahoo.com via HTTP; Fri, 03 Apr 2015 12:44:15 PDT X-Rocket-MIMEInfo: 002.001, Q2hyaXN0b3BoZXIsDQoNCkkgcmVhZCBSRkMgMjAyNiBjYXJlZnVsbHkgYXMgSSBrbm93IHlvdSBkaWQgdG9vOg0Kc2VjdGlvbiA0LjIgY2xhcmlmaWVzIHRoYXQgSW5mb3JtYXRpb25hbCBhbmQgRXhwZXJpbWVudGFsIFJGQ3MgYXJlIG5vdCBJbnRlcm5ldCBTdGFuZGFyZHMgaW4gYW55IHNlbnNlLg0KDQpzZWN0aW9uIDQuMi4zLCBleHRlbmRpbmcgdGhlIHBhcnQgeW91IHF1b3RlZCwgc2F5cyB0aGF0IEluZm9ybWF0aW9uYWwgYW5kIEV4cGVyaW1lbnRhbCBSRkNzIHNob3VsZA0Kbm90IGJlIHVzZWQgdG8gY2kBMAEBAQE- X-Mailer: YahooMailClassic/452 YahooMailWebService/0.8.203.740 Message-ID: <1428090255.88777.YahooMailBasic@web400004.mail.bf1.yahoo.com> Date: Fri, 3 Apr 2015 12:44:15 -0700 From: JS To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] draft-shaio-manet-common-l3-interface X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 19:44:19 -0000 Christopher, I read RFC 2026 carefully as I know you did too: section 4.2 clarifies that Informational and Experimental RFCs are not Inte= rnet Standards in any sense. section 4.2.3, extending the part you quoted, says that Informational and E= xperimental RFCs should not be used to circumvent the standards process and require that they not c= over work being done, or planned to be done, in an IETF working group. The key objective of our CL3 draft is to allow integration of the many IP r= outers that do implement MANET WG protocols with MANET that were not standardized by the MANET WG. This is described in section 3 of our draft as well as the email threads re= garding our draft. It is clear from those threads, and from the MANET WG charter thread, that there does n= ot seem to be an effort in the WG to address this issue. Our draft does not define message formats, specify codepoints, define a MIB= , nor any other specification that might be considered a standard. It therefore is not attempt to circumv= ent work done or being planned in the MANET working group. I quoted both of these sections below for ease of reference. thanks, =A0 =A0=A0=A0Jack Shaio 4.2 Non-Standards Track Maturity Levels Not every specification is on the standards track. A specification may not be intended to be an Internet Standard, or it may be intended for eventual standardization but not yet ready to enter the standards track. A specification may have been superseded by a more recent Internet Standard, or have otherwise fallen into disuse or disfavor. Specifications that are not on the standards track are labeled with one of three "off-track" maturity levels: "Experimental", "Informational", or "Historic". The documents bearing these labels are not Internet Standards in any sense. 4.2.3 Procedures for Experimental and Informational RFCs Unless they are the result of IETF Working Group action, documents intended to be published with Experimental or Informational status should be submitted directly to the RFC Editor. The RFC Editor will publish any such documents as Internet-Drafts which have not already been so published. In order to differentiate these Internet-Drafts they will be labeled or grouped in the I-D directory so they are easily recognizable. The RFC Editor will wait two weeks after this publication for comments before proceeding further. The RFC Editor is expected to exercise his or her judgment concerning the editorial suitability of a document for publication with Experimental or Informational status, and may refuse to publish a document which, in the expert opinion of the RFC Editor, is unrelated to Internet activity or falls below the technical and/or editorial standard for RFCs. To ensure that the non-standards track Experimental and Informational designations are not misused to circumvent the Internet Standards Process, the IESG and the RFC Editor have agreed that the RFC Editor will refer to the IESG any document submitted for Experimental or Informational publication which, in the opinion of the RFC Editor, may be related to work being done, or expected to be done, within the IETF community. The IESG shall review such a referred document within a reasonable period of time, and recommend either that it be published as originally submitted or referred to the IETF as a contribution to the Internet Standards Process. ---------------------------------------------------------------------- =20 Message: 1 Date: Wed, 1 Apr 2015 11:41:27 +0000 From: "Dearlove, Christopher (UK)" Subject: Re: [manet] draft-shaio-manet-common-l3-interface Message-ID: =A0=A0=A0 Content-Type: text/plain; charset=3D"iso-8859-1" =20 You need to read further in that section, starting =20 =A0=A0=A0To ensure that the non-standards track=A0 Experimental and Inform= ational =A0=A0=A0designations are not misused to circumvent=A0 the Internet Standa= rds=A0 =A0=A0=A0Process =20 I'm not saying you are, I'm saying the rest of that section=A0 heavily mod= ifies your summary of your intention below. =20 Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence =20 BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.=20 www.baesystems.com/ai =20 =20 -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Jack Shaio Sent: 27 March 2015 13:33 To: Henning Rogge Cc: Broderick, Don; Caleb Lo; manet@ietf.org Subject: Re: [manet] draft-shaio-manet-common-l3-interface =20 I believe that is true of draft standards but not of Informational or Experimental drafts, which do not define a standard and are provided only as information for the IETF community.=20 =20 This is what I understood from the relevant section of RFC 2026 which defined the process: http://www.rfc-editor.org/rfc/rfc2026.txt =20 =20 =20 4.2.3=A0 Procedures for Experimental and Informational RFCs =20 =A0=A0=A0Unless they are the result of IETF Working Group action, document= s =A0=A0=A0intended to be published with Experimental or Informational statu= s =A0=A0=A0should be submitted directly to the RFC Editor.=A0 The RFC Editor= will =A0=A0=A0publish any such documents as Internet-Drafts which have not alre= ady =A0=A0=A0been so published.=A0 In order to differentiate these Internet-Dr= afts =A0=A0=A0they will be labeled or grouped in the I-D=A0 directory so they a= re =A0=A0=A0easily recognizable.=A0 The RFC Editor will wait two weeks after = this =A0=A0=A0publication for comments before proceeding=A0 further... =A0=20 We thought this work was relevant to the manet WG and wanted to give the group another opportunity to comment on the draft first, before submitting directly to the RFC Editor as the procedures state. =20 --jack shaio =20 =20 From nobody Wed Apr 8 11:57:28 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1541B3503 for ; Wed, 8 Apr 2015 11:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 EjdsTEPjEqf0 for ; Wed, 8 Apr 2015 11:57:26 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 C2FF01B34DE for ; Wed, 8 Apr 2015 11:57:26 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so77562939obb.3 for ; Wed, 08 Apr 2015 11:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6ets385ri+9qsQh3mge7lToyIxBzwTJ/3sqgXjsxkZY=; b=zMrnMUqgHotNbpBm9zUe/L2a+2/VGFyzTSIWLGLqtxL1JVjnuo6I4iTH4PVemnVaNM 3NyfKZ+B/xnnIRUFsuuHsVs6Ce5b0x1vpU/1z9tGDb5w5Io2IzF9FEX3bDGEYU0uXu/4 0P0Ramvy5ez5vtS/eEVUufX9OH6CU9DYx0+XCLAQdPQ+PUse2Pa9eW7lHbJaOI4Si181 pxY2bMV7maws2OLumnxGrNp1qXHiRIkg82UxexxMvX6IxvKk2rO0nsWlhkGmL5LLjmrY W+ZxxcBNW2XVBQ4QTd43W/iNtaw4kpIdcmWMzdjTnGX+j+0lzcy6tNPTGwGejr30SKFG MzxQ== MIME-Version: 1.0 X-Received: by 10.60.116.102 with SMTP id jv6mr34066731oeb.50.1428519446329; Wed, 08 Apr 2015 11:57:26 -0700 (PDT) Received: by 10.202.75.207 with HTTP; Wed, 8 Apr 2015 11:57:26 -0700 (PDT) Date: Wed, 8 Apr 2015 14:57:26 -0400 Message-ID: From: Justin Dean To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=089e0115ef40273ca205133b1afe Archived-At: Subject: [manet] DLEP in last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 18:57:28 -0000 --089e0115ef40273ca205133b1afe Content-Type: text/plain; charset=UTF-8 The DLEP draft is now in last call please review and post comments to the list. Last call will last for two weeks, ending April 22nd. Justin --089e0115ef40273ca205133b1afe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The DLEP draft is now in last call please review and = post comments to the list.=C2=A0 Last call will last for two weeks, ending = April 22nd.

Justin
--089e0115ef40273ca205133b1afe-- From nobody Wed Apr 8 12:41:52 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2251B356B for ; Wed, 8 Apr 2015 12:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 64i4KUebpO6c for ; Wed, 8 Apr 2015 12:41:48 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 842061B356A for ; Wed, 8 Apr 2015 12:41:48 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t38JfGBA028700; Wed, 8 Apr 2015 15:41:16 -0400 From: "Cheng, Bow-Nan - 0665 - MITLL" To: Justin Dean , "manet@ietf.org" Thread-Topic: [manet] DLEP in last call Thread-Index: AQHQci3dU5pJO3rAEkujmOB5qEoVP51Dg4wA Date: Wed, 8 Apr 2015 19:41:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [172.25.57.38] Content-Type: multipart/alternative; boundary="_000_D14AFC5C1C266bchengllmitedu_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-08_06:2015-04-08,2015-04-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504080159 Archived-At: Subject: Re: [manet] DLEP in last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 19:41:50 -0000 --_000_D14AFC5C1C266bchengllmitedu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Justin, Quick question =97 I thought at the last IETF there were some issues to add= ress in Draft 8 that Stan and Rick were going to generate a new draft (9) b= efore last call. Did something change? Or is it simply that the changes hav= e been accepted and will make it to the final draft? Thanks! -Bow-Nan From: Justin Dean > Date: Wednesday, April 8, 2015 at 2:57 PM To: "manet@ietf.org" > Subject: [manet] DLEP in last call The DLEP draft is now in last call please review and post comments to the l= ist. Last call will last for two weeks, ending April 22nd. Justin --_000_D14AFC5C1C266bchengllmitedu_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Justin,

Quick question =97 I thought at the last IETF there were some issues t= o address in Draft 8 that Stan and Rick were going to generate a new draft = (9) before last call. Did something change? Or is it simply that the change= s have been accepted and will make it to the final draft? Thanks!

-Bow-Nan

From: Justin Dean <bebemaster@gmail.com>
Date: Wednesday, April 8, 2015 at 2= :57 PM
To: "manet@ietf.org" <man= et@ietf.org>
Subject: [manet] DLEP in last call<= br>

The DLEP draft is now in last call please review and post comments to = the list.  Last call will last for two weeks, ending April 22nd.

Justin
 --_000_D14AFC5C1C266bchengllmitedu_-- From nobody Wed Apr 8 14:47:18 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696511A88C0 for ; Wed, 8 Apr 2015 14:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7zY3wPozLSWB for ; Wed, 8 Apr 2015 14:47:14 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id BDA031A88AE for ; Wed, 8 Apr 2015 14:47:13 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.11,546,1422918000"; d="scan'208,217"; a="40919894" Received: from exc-cashub03.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 08 Apr 2015 23:47:12 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB03.tsn.tno.nl ([fe80::6d39:f277:173e:a926%13]) with mapi id 14.03.0195.001; Wed, 8 Apr 2015 23:47:12 +0200 From: "Velt, R. (Ronald) in 't" To: "Cheng, Bow-Nan - 0665 - MITLL" , Justin Dean , "manet@ietf.org" Thread-Topic: [manet] DLEP in last call Thread-Index: AQHQci3llYV/xp27gUCYwiYQjQZKa51DYhCAgABBz7A= Date: Wed, 8 Apr 2015 21:47:11 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F307DE98E67@EXC-MBX03.tsn.tno.nl> References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_72FB622921C13746AD6349E70A8D9F307DE98E67EXCMBX03tsntnon_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP in last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 21:47:17 -0000 --_000_72FB622921C13746AD6349E70A8D9F307DE98E67EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Bow-Nan, Justin, Stan's message of March 29 (http://www.ietf.org/mail-archive/web/manet/curr= ent/msg17491.html ) does indeed suggest that a new version will be submitte= d, which will then be subjected to WGLC. Because of this, I put my review o= f -08 on hold. Thanks, Ronald From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Cheng, Bow-Nan - 0= 665 - MITLL Sent: woensdag 8 april 2015 21:41 To: Justin Dean; manet@ietf.org Subject: Re: [manet] DLEP in last call Hi Justin, Quick question - I thought at the last IETF there were some issues to addre= ss in Draft 8 that Stan and Rick were going to generate a new draft (9) bef= ore last call. Did something change? Or is it simply that the changes have = been accepted and will make it to the final draft? Thanks! -Bow-Nan From: Justin Dean > Date: Wednesday, April 8, 2015 at 2:57 PM To: "manet@ietf.org" > Subject: [manet] DLEP in last call The DLEP draft is now in last call please review and post comments to the l= ist. Last call will last for two weeks, ending April 22nd. Justin This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. --_000_72FB622921C13746AD6349E70A8D9F307DE98E67EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Bow-Nan, Justin,

 <= /p>

Stan’= ;s message of March 29 (http://www.ietf.org/mail-archive/web/manet/curren= t/msg17491.html ) does indeed suggest that a new version will be submitted, which will the= n be subjected to WGLC. Because of this, I put my review of -08 on hold.

 = ;

Thanks,

Ronald

 = ;

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Cheng, Bow-Nan - 0665 - MITLL
Sent: woensdag 8 april 2015 21:41
To: Justin Dean; manet@ietf.org
Subject: Re: [manet] DLEP in last call

 

Hi Justin,<= /p>

 

Quick question — I thou= ght at the last IETF there were some issues to address in Draft 8 that Stan= and Rick were going to generate a new draft (9) before last call. Did something change? Or is it simply that the changes have been accepted = and will make it to the final draft? Thanks!

 

-Bow-Nan

 

From: Justin Dean <bebemaster@gmail.com>
Date: Wednesday, April 8, 2015 at 2:57 PM
To: "manet@ietf.org"= <manet@ietf.org>
Subject: [manet] DLEP in last call

 

Justin

 

, "Cheng, Bow-Nan - 0665 - MITLL" , Justin Dean , "manet@ietf.org" Thread-Topic: [manet] DLEP in last call Thread-Index: AQHQci3h9aEoKeJ1OU+i5M/32d6yzw== Date: Thu, 9 Apr 2015 08:49:07 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801670C08C5@tss-server1.home.tropicalstormsoftware.com> References: <72FB622921C13746AD6349E70A8D9F307DE98E67@EXC-MBX03.tsn.tno.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP in last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 08:49:37 -0000 All,=0A= =0A= Stan and I are integrating a number of comments from Bow-Nan and others =0A= as we speak, and should have an 'absolutely final' draft as soon as =0A= possible. The UK holidays over Easter have slowed me slightly.=0A= =0A= However, the current diff from draft-08 is very small, and mostly =0A= typographical, so any comments on 08 are still very useful.=0A= =0A= Regards,=0A= =0A= Rick=0A= =0A= =0A= On 08/04/15 22:47, Velt, R. (Ronald) in 't wrote:=0A= > Bow-Nan, Justin,=0A= >=0A= > Stan=92s message of March 29=0A= > (http://www.ietf.org/mail-archive/web/manet/current/msg17491.html ) does= =0A= > indeed suggest that a new version will be submitted, which will then be= =0A= > subjected to WGLC. Because of this, I put my review of -08 on hold.=0A= >=0A= > Thanks,=0A= >=0A= > Ronald=0A= >=0A= > *From:*manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Cheng,=0A= > Bow-Nan - 0665 - MITLL=0A= > *Sent:* woensdag 8 april 2015 21:41=0A= > *To:* Justin Dean; manet@ietf.org=0A= > *Subject:* Re: [manet] DLEP in last call=0A= >=0A= > Hi Justin,=0A= >=0A= > Quick question =97 I thought at the last IETF there were some issues to= =0A= > address in Draft 8 that Stan and Rick were going to generate a new draft= =0A= > (9) before last call. Did something change? Or is it simply that the=0A= > changes have been accepted and will make it to the final draft? Thanks!= =0A= >=0A= > -Bow-Nan=0A= >=0A= > *From: *Justin Dean >= =0A= > *Date: *Wednesday, April 8, 2015 at 2:57 PM=0A= > *To: *"manet@ietf.org " >=0A= > *Subject: *[manet] DLEP in last call=0A= >=0A= > The DLEP draft is now in last call please review and post comments to=0A= > the list. Last call will last for two weeks, ending April 22nd.=0A= >=0A= > Justin=0A= >=0A= > This message may contain information that is not intended for you. If=0A= > you are not the addressee or if this message was sent to you by mistake,= =0A= > you are requested to inform the sender and delete the message. TNO=0A= > accepts no liability for the content of this e-mail, for the manner in=0A= > which you use it and for damage of any kind resulting from the risks=0A= > inherent to the electronic transmission of messages.=0A= >=0A= =0A= From nobody Mon Apr 13 02:14:21 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2831B3022 for ; Mon, 13 Apr 2015 02:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Hs4I7aTOWvEp for ; Mon, 13 Apr 2015 02:14:17 -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 E284A1B3021 for ; Mon, 13 Apr 2015 02:14:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,568,1422921600"; d="scan'208";a="542158630" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta1.baesystems.com with ESMTP; 13 Apr 2015 10:14:14 +0100 X-IronPort-AV: E=Sophos;i="5.11,568,1422921600"; d="scan'208";a="94270376" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 13 Apr 2015 10:14:13 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.91]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0224.002; Mon, 13 Apr 2015 10:14:13 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , "Velt, R. (Ronald) in 't" , "Cheng, Bow-Nan - 0665 - MITLL" , Justin Dean , "manet@ietf.org" Thread-Topic: [manet] DLEP in last call Thread-Index: AQHQci3h0QJ6q5RwIUGyRaRgCuC8mZ1Kr7fw Date: Mon, 13 Apr 2015 09:14:12 +0000 Message-ID: References: <72FB622921C13746AD6349E70A8D9F307DE98E67@EXC-MBX03.tsn.tno.nl> <38A5475DE83986499AEACD2CFAFC3F9801670C08C5@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801670C08C5@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [manet] DLEP in last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 09:14:19 -0000 However it does not appear appropriate to issue a short Last Call (two week= s) for a document we do not even have the final draft of. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ 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 Rick Taylor Sent: 09 April 2015 09:49 To: Velt, R. (Ronald) in 't; Cheng, Bow-Nan - 0665 - MITLL; Justin Dean; ma= net@ietf.org Subject: Re: [manet] DLEP in last call ----------------------! 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. -------------------------------------------------------- All, Stan and I are integrating a number of comments from Bow-Nan and others as = we speak, and should have an 'absolutely final' draft as soon as possible. = The UK holidays over Easter have slowed me slightly. However, the current diff from draft-08 is very small, and mostly typograph= ical, so any comments on 08 are still very useful. Regards, Rick On 08/04/15 22:47, Velt, R. (Ronald) in 't wrote: > Bow-Nan, Justin, > > Stan's message of March 29 > (http://www.ietf.org/mail-archive/web/manet/current/msg17491.html ) = > does indeed suggest that a new version will be submitted, which will = > then be subjected to WGLC. Because of this, I put my review of -08 on hol= d. > > Thanks, > > Ronald > > *From:*manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Cheng, = > Bow-Nan - 0665 - MITLL > *Sent:* woensdag 8 april 2015 21:41 > *To:* Justin Dean; manet@ietf.org > *Subject:* Re: [manet] DLEP in last call > > Hi Justin, > > Quick question - I thought at the last IETF there were some issues to = > address in Draft 8 that Stan and Rick were going to generate a new = > draft > (9) before last call. Did something change? Or is it simply that the = > changes have been accepted and will make it to the final draft? Thanks! > > -Bow-Nan > > *From: *Justin Dean > > *Date: *Wednesday, April 8, 2015 at 2:57 PM > *To: *"manet@ietf.org " > > *Subject: *[manet] DLEP in last call > > The DLEP draft is now in last call please review and post comments to = > the list. Last call will last for two weeks, ending April 22nd. > > Justin > > This message may contain information that is not intended for you. If = > you are not the addressee or if this message was sent to you by = > mistake, you are requested to inform the sender and delete the = > message. TNO accepts no liability for the content of this e-mail, for = > the manner in which you use it and for damage of any kind resulting = > from the risks inherent to the electronic transmission of messages. > _______________________________________________ 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 Mon Apr 13 05:47:05 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4D11B2F4E for ; Mon, 13 Apr 2015 05:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 PIBZQNEzVtVV for ; Mon, 13 Apr 2015 05:47:01 -0700 (PDT) Received: from mail-vn0-x233.google.com (mail-vn0-x233.google.com [IPv6:2607:f8b0:400c:c0f::233]) (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 CA9BD1B2F4B for ; Mon, 13 Apr 2015 05:47:00 -0700 (PDT) Received: by vnbf62 with SMTP id f62so19220080vnb.13 for ; Mon, 13 Apr 2015 05:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=3IFbrIYlm9seKJFWgxmuAEgMNF3RFsmuMmsPYO/ux5M=; b=AfjHZwNy8hlxoKdoeziDWUDoWi8AgCCXgzwD7Xe1DibLs+nNAa+m0tzmNsebbiKDKQ kxmNtZ8UwPLVbZ7Wyamquzod5Wbav7An5rPFWO0gzHL/xc6YLyqAWB4Rt27efX+mYooP dPNZEnymoDbqVaNTmXBYfhHLO5gVXMnlyTCRZYZhWgWH8Q/mbfWm+VTPvAW9o/SfDDuI 8BxcZdGHGBVBW8m7lglfq3+DM32yRQj2/kv7FwGDpyGJB8R95Dg7Zhd5zL7zSyTj6Emx ULC1UYqyjvszX/52Hx86omilwcfBRXPYKx+R01H84BYVdoSRgNIh1nIUa9QQ+hqHFiYg VM8w== X-Received: by 10.60.70.40 with SMTP id j8mr12161527oeu.59.1428929220030; Mon, 13 Apr 2015 05:47:00 -0700 (PDT) MIME-Version: 1.0 References: <72FB622921C13746AD6349E70A8D9F307DE98E67@EXC-MBX03.tsn.tno.nl> <38A5475DE83986499AEACD2CFAFC3F9801670C08C5@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: From: Justin Dean Date: Mon, 13 Apr 2015 12:46:59 +0000 Message-ID: To: "Dearlove, Christopher (UK)" , Rick Taylor , "Velt, R. (Ronald) in 't" , "Cheng, Bow-Nan - 0665 - MITLL" , "manet@ietf.org" Content-Type: multipart/alternative; boundary=001a11330ab491b52405139a82b2 Archived-At: Subject: Re: [manet] DLEP in last call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 12:47:03 -0000 --001a11330ab491b52405139a82b2 Content-Type: text/plain; charset=UTF-8 There was a mix up in communication between myself and Stan. The last call will be extended to at LEAST two weeks after a new draft is issued, likely more. On Mon, Apr 13, 2015, 5:14 AM Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > However it does not appear appropriate to issue a short Last Call (two > weeks) for a document we do not even have the final draft of. > > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > __________________________________________________________________________ > > 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 > > > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor > Sent: 09 April 2015 09:49 > To: Velt, R. (Ronald) in 't; Cheng, Bow-Nan - 0665 - MITLL; Justin Dean; > manet@ietf.org > Subject: Re: [manet] DLEP in last call > > ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external partner > or from the internet. > Consider carefully whether you should click on any links, open any > attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions > on reporting suspicious email messages. > -------------------------------------------------------- > > All, > > Stan and I are integrating a number of comments from Bow-Nan and others as > we speak, and should have an 'absolutely final' draft as soon as possible. > The UK holidays over Easter have slowed me slightly. > > However, the current diff from draft-08 is very small, and mostly > typographical, so any comments on 08 are still very useful. > > Regards, > > Rick > > > On 08/04/15 22:47, Velt, R. (Ronald) in 't wrote: > > Bow-Nan, Justin, > > > > Stan's message of March 29 > > (http://www.ietf.org/mail-archive/web/manet/current/msg17491.html ) > > does indeed suggest that a new version will be submitted, which will > > then be subjected to WGLC. Because of this, I put my review of -08 on > hold. > > > > Thanks, > > > > Ronald > > > > *From:*manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Cheng, > > Bow-Nan - 0665 - MITLL > > *Sent:* woensdag 8 april 2015 21:41 > > *To:* Justin Dean; manet@ietf.org > > *Subject:* Re: [manet] DLEP in last call > > > > Hi Justin, > > > > Quick question - I thought at the last IETF there were some issues to > > address in Draft 8 that Stan and Rick were going to generate a new > > draft > > (9) before last call. Did something change? Or is it simply that the > > changes have been accepted and will make it to the final draft? Thanks! > > > > -Bow-Nan > > > > *From: *Justin Dean > > > > *Date: *Wednesday, April 8, 2015 at 2:57 PM > > *To: *"manet@ietf.org " > > > > *Subject: *[manet] DLEP in last call > > > > The DLEP draft is now in last call please review and post comments to > > the list. Last call will last for two weeks, ending April 22nd. > > > > Justin > > > > This message may contain information that is not intended for you. If > > you are not the addressee or if this message was sent to you by > > mistake, you are requested to inform the sender and delete the > > message. TNO accepts no liability for the content of this e-mail, for > > the manner in which you use it and for damage of any kind resulting > > from the risks inherent to the electronic transmission of messages. > > > > > _______________________________________________ > 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. > ******************************************************************** > > --001a11330ab491b52405139a82b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

There was a mix up in communication between myself and Stan.= The last call will be extended to at LEAST two weeks after a new draft is = issued, likely more.


On Mon, Apr 13, 2015, 5:14 AM=C2=A0Dearlove,= Christopher (UK) <chri= s.dearlove@baesystems.com> wrote:
= However it does not appear appropriate to issue a short Last Call (two week= s) for a document we do not even have the final draft of.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________<= br>
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.c= om/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 Rick Taylor
Sent: 09 April 2015 09:49
To: Velt, R. (Ronald) in 't; Cheng, Bow-Nan - 0665 - MITLL; Justin Dean= ; manet@ietf.org Subject: Re: [manet] DLEP in last call

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

All,

Stan and I are integrating a number of comments from Bow-Nan and others as = we speak, and should have an 'absolutely final' draft as soon as po= ssible.=C2=A0 The UK holidays over Easter have slowed me slightly.

However, the current diff from draft-08 is very small, and mostly typograph= ical, so any comments on 08 are still very useful.

Regards,

Rick


On 08/04/15 22:47, Velt, R. (Ronald) in 't wrote:
> Bow-Nan, Justin,
>
> Stan's message of March 29
> (http://www.ietf.org/mail-archive/web/manet/curren= t/msg17491.html )
> does indeed suggest that a new version will be submitted, which will > then be subjected to WGLC. Because of this, I put my review of -08 on = hold.
>
> Thanks,
>
> Ronald
>
> *From:*manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Cheng,
> Bow-Nan - 0665 - MITLL
> *Sent:* woensdag 8 april 2015 21:41
> *To:* Justin Dean; manet@ietf.org
> *Subject:* Re: [manet] DLEP in last call
>
> Hi Justin,
>
> Quick question - I thought at the last IETF there were some issues to<= br> > address in Draft 8 that Stan and Rick were going to generate a new
> draft
> (9) before last call. Did something change? Or is it simply that the > changes have been accepted and will make it to the final draft? Thanks= !
>
> -Bow-Nan
>
> *From: *Justin Dean <bebemaster@gmail.com
> <mailto:b= ebemaster@gmail.com>>
> *Date: *Wednesday, April 8, 2015 at 2:57 PM
> *To: *"manet@= ietf.org <mailto:manet@ietf.org>" <manet@ietf.org
> <mailto:manet@i= etf.org>>
> *Subject: *[manet] DLEP in last call
>
> The DLEP draft is now in last call please review and post comments to<= br> > the list.=C2=A0 Last call will last for two weeks, ending April 22nd.<= br> >
> Justin
>
> This message may contain information that is not intended for you. If<= br> > you are not the addressee or if this message was sent to you by
> mistake, you are requested to inform the sender and delete the
> message. TNO accepts no liability for the content of this e-mail, for<= br> > the manner in which you use it and for damage of any kind resulting > from the risks inherent to the electronic transmission of messages. >


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://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.
********************************************************************

--001a11330ab491b52405139a82b2-- From vmercieca0@gmail.com Wed Apr 15 07:11:22 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D02F1B3530 for ; Wed, 15 Apr 2015 07:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 G_2e1wh8FlYw for ; Wed, 15 Apr 2015 07:11:21 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::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 CC2721A9133 for ; Wed, 15 Apr 2015 07:11:20 -0700 (PDT) Received: by labbd9 with SMTP id bd9so33706972lab.2 for ; Wed, 15 Apr 2015 07:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SVkgBoNz2YYL4lkmrRACcjH/gSqaOEi4MOuY5OEewsg=; b=zHYVQ7yLWnl57uK328tulsGtQ2UkwaQe48PBYAu0IKBAcfC4z6zmSpH3riDn//vBkQ S78uAjK7vaXFV3a3YPu2iapNswgUo1fasy9vIXPOoHzVZZM4abQ7A3BBmwt4YlVnUkVK XphJCFuD1MJyNyfLWGWtPIjs0pAl3t92SUX/ZWFmCJJvwp64cAvD5E4xjgGCD7ZJ2x7i Ne6dsTOL6FxqHKQjlp1D2e+CerRkDhZy/zIIWGeb/wyHQgLr3vXxxKqRaXyRCtHEdaO9 JuMw1RTRSU3d7qztA7tNmdrVunF3pUhybe+BYOdZn7tzDPMrlbINe8pdqKVrGRbjtVwB Iy8A== MIME-Version: 1.0 X-Received: by 10.152.36.227 with SMTP id t3mr24431439laj.12.1429107079336; Wed, 15 Apr 2015 07:11:19 -0700 (PDT) Received: by 10.112.252.4 with HTTP; Wed, 15 Apr 2015 07:11:19 -0700 (PDT) Date: Wed, 15 Apr 2015 15:11:19 +0100 Message-ID: From: Victoria Mercieca To: manet@ietf.org Content-Type: multipart/alternative; boundary=089e0158aefecf58490513c3eb75 Archived-At: Subject: [manet] AODVv2 Milestones X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 14:12:45 -0000 --089e0158aefecf58490513c3eb75 Content-Type: text/plain; charset=UTF-8 Hello all, As discussed at the MANET meeting in Dallas, the AODVv2 team have set a number of milestones to work towards, in order to have AODVv2 ready for Last Call at the next IETF meeting. Our milestones are as follows: [April 22nd/end of April] RFC 5444 double check with Henning Rogge [end of April] Editorial updates [end of April] Security Considerations text for review on MANET list [first week of May] Based on MANET list review, submit Security Considerations for early sec AD review [mid May - DONE] Craft language for reboot procedure, enabling RREQ / RREP assistance [mid May - DONE] Fix language about bidirectionality and adjacency [end of May] New version of the draft - Version 9 [mid June] Reviews by MANET list [end of June] Revision 10 of the draft, updated based on reviews by WG [July 6th] Deadline for draft submission for next IETF meeting We all appreciate your support and look forward to your feedback. Kind regards, Victoria, on behalf of the AODVv2 author team. --089e0158aefecf58490513c3eb75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all,

As discussed= at the MANET meeting in Dallas, the AODVv2 team have set a number of miles= tones to work towards, in order to have AODVv2 ready for Last Call at the n= ext IETF meeting. Our milestones are as follows:

[= April 22nd/end of April] RFC 5444 double check with Henning Rogge
[end of April] Editorial updates
[end of April] Security Conside= rations text for review on MANET list
[first week of May] Bas= ed on MANET list review, submit Security Considerations for early sec AD re= view
[mid May - DONE] Craft language for reboot procedure, en= abling RREQ / RREP assistance=C2=A0
[mid May - DONE] Fix language= about bidirectionality and adjacency
[end of May] New version of= the draft - Version 9
[mid June] Reviews by MANET list
[end of June] Revision 10 of the draft, updated based on reviews by WG
[July 6th] Deadline for draft submission for next IETF meeting
=

We all appreciate your support and look forward to your= feedback.

Kind regards,
Victoria, on be= half of the AODVv2 author team.

--089e0158aefecf58490513c3eb75-- From nobody Wed Apr 15 08:43:41 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C711F1ACE28 for ; Wed, 15 Apr 2015 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 bA2bWRlM4dap for ; Wed, 15 Apr 2015 08:43:38 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::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 561861A912D for ; Wed, 15 Apr 2015 08:43:38 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so56610888pdb.1 for ; Wed, 15 Apr 2015 08:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type; bh=qKc6F3AqKCjD7OdGXPIOsIh5Gs1eCRu4PNmoOcDaBNY=; b=vkg1IdddYY4wrz+nsYZ8tCWoTSIKuZ7I96bV8dKScEbtDQ0VwUGNojjLjlLfP0S9Xy x7a+9QxVKtQVSxVSL0sLuc/uWUPQe42MSNdTFWF8DSPvri8NVXQGbbc9cGWWagVH8NYN Llk9IG53HSzCfcFNOzVQOm56FPLeDRL1MfA2E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=qKc6F3AqKCjD7OdGXPIOsIh5Gs1eCRu4PNmoOcDaBNY=; b=SPqhQOq3Ss0yWgKReYd93+ym364WMJtCPawJYPSy1dWIEMtFjHR1p+ZoCt7hEyuvdn QzNDzEZRgePkIgAgmFYKoi9E+d2NOZO7X2LJN8R8hG9a1IDi2DaLxzs76IEKSSJVRuvp XnAIpmfX02db0KTwZZHJiHc9WOMcpgnF/OyvE6mOygOkXC4di0pwSjcGAOFOW31TDbtm YUjrMyq3HI5RBUm90fFf7SNKfw8qsl2otJ0UzsBRQTVDYlumVDfKqFsAPdoUk6wYA7G5 Up1hsly5cwHb0tBwmg2XJx9hZFWTheseQkJ7vcjZ1o+G51xfj/Sdu7+bnYZQzvi2+til F07Q== X-Gm-Message-State: ALoCoQnLhF7oH6W5cAPo9mjTggm1ozM0a9KZ0vuY+n0QgIGJtb3pMdTWxSiRJxKopB2QN+q4RoJb MIME-Version: 1.0 X-Received: by 10.70.94.67 with SMTP id da3mr47935908pdb.158.1429112617814; Wed, 15 Apr 2015 08:43:37 -0700 (PDT) Received: by 10.70.81.134 with HTTP; Wed, 15 Apr 2015 08:43:37 -0700 (PDT) Date: Wed, 15 Apr 2015 08:43:37 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [manet] Preliminary minutes posted X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 15:43:39 -0000 I have posted the preliminary minutes of the MANET meeting. Please let me know if corrections are requested: https://www.ietf.org/proceedings/92/minutes/minutes-92-manet Regards Ulrich From nobody Thu Apr 16 14:34:16 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751361B3726; Thu, 16 Apr 2015 14:34:13 -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 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 sURT3vEWwkei; Thu, 16 Apr 2015 14:34:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A17051B372A; Thu, 16 Apr 2015 14:34:09 -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.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416213409.14686.90242.idtracker@ietfa.amsl.com> Date: Thu, 16 Apr 2015 14:34:09 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 21:34:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Bo Berry Cisco Systems Darryl Satterwhite Rick Taylor Filename : draft-ietf-manet-dlep-09.txt Pages : 64 Date : 2015-04-16 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-dlep-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-09 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 Fri Apr 17 05:36:36 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9417B1B2B9E for ; Fri, 17 Apr 2015 05:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 srtC9AdB3ycm for ; Fri, 17 Apr 2015 05:36:33 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E861A6F32 for ; Fri, 17 Apr 2015 05:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1497; q=dns/txt; s=iport; t=1429274194; x=1430483794; h=from:to:cc:subject:date:message-id:mime-version; bh=xESehYKb0hTt5bJ0dhuFmV4aY3eX3ZRuQr5A1w9ZAMg=; b=ftTM6YlJZBqzp7ajyZEFqn+XG0lQCVGgCAfPfNVlzfC5py4j+1M/ysPq c8mE8KSCwOjCuLOfu+7U32xym872/Sij2Ordzr3irQ91m3AGjXpcSwIWC 21Yb73TPL9QhB0RGcrJEQSOy3zbhdGe7IGoptm7UqCid8JamKQ9SjIRKD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DCBQDQ/TBV/51dJa1dgkVHgTOHBsZpgVY7EQEBAQEBAQF9hBcMBB1cEgELAXQnBA6IL8g9AQEBAQEBBAEBAQEBAQEBGpAlhDQBBI8Egh6LO4M6kDMig2+CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,594,1422921600"; d="scan'208,217";a="142140905" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 17 Apr 2015 12:36:33 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3HCaWlC022332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Apr 2015 12:36:32 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.6]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Fri, 17 Apr 2015 07:36:31 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-manet-tlv-naming@tools.ietf.org" Thread-Topic: AD Review of draft-ietf-manet-tlv-naming Thread-Index: AQHQeQsi7M0KVDn3uke1gihobrGm6w== Date: Fri, 17 Apr 2015 12:36:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_D1563DB1A890Cxxx_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: [manet] AD Review of draft-ietf-manet-tlv-naming X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 12:36:34 -0000 --_000_D1563DB1A890Cxxx_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! Not much to say on this one. The naming makes sense. Thanks for the work! I=92m starting the 2-week IETF Last Call for this draft and putting it on t= he next possible Telechat agenda. Please be on the lookout for any comment= s during this time, specially IANA=92s review of the document. Thanks! Alvaro. --_000_D1563DB1A890Cxxx_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!

Not much to say on this one.  The naming makes sense.

Thanks for the work!


I=92m starting the 2-week IETF Last Call for this draft and putting it= on the next possible Telechat agenda.  Please be on the lookout for a= ny comments during this time, specially IANA=92s review of the document.

Thanks!

Alvaro.
--_000_D1563DB1A890Cxxx_-- From nobody Fri Apr 17 06:00:05 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FEC1B2C2D for ; Fri, 17 Apr 2015 05:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TvVOs5XsMJkw for ; Fri, 17 Apr 2015 05:59:53 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6901B2C28 for ; Fri, 17 Apr 2015 05:59:53 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,594,1422939600"; d="jpg'145?scan'145,208,217,145";a="17268153" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport.idirect.net with ESMTP; 17 Apr 2015 08:59:53 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 17 Apr 2015 08:59:52 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Fri, 17 Apr 2015 08:59:52 -0400 From: "Ratliff, Stanley" To: Mobile Ad Hoc Networks mailing list Thread-Topic: DLEP-09 Thread-Index: AdB5Dijsuf08P0oXRc6vubghpHd05g== Date: Fri, 17 Apr 2015 12:59:52 +0000 Message-ID: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/related; boundary="_004_970cf81ffef1443eb2f59f584f0acd6bVAUSDITCHM2idirectnet_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 12:59:55 -0000 --_004_970cf81ffef1443eb2f59f584f0acd6bVAUSDITCHM2idirectnet_ Content-Type: multipart/alternative; boundary="_000_970cf81ffef1443eb2f59f584f0acd6bVAUSDITCHM2idirectnet_" --_000_970cf81ffef1443eb2f59f584f0acd6bVAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Working Group, DLEP-09 was posted yesterday, and contains the fixes for issues brought up = in reviews prior to IETF 92. With DLEP-09, the authors formally request a 2-week Working Group Last Call= (WGLC). If the 2-week WGLC is granted, Last call comments would be due by = May 1, 2015. Regards, Stan ________________________________ Stan Ratliff | Architect, Applied Research VT iDirect | 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, US= A T: +1 703 544-8520 | F: +1 222 123-4567 sratliff@idirect.net | www.idirect.net Connect with iDirect: Twitter.com/iDirect | = Facebook.com/iDirect [cid:image001.jpg@01D078EC.DC845760] Advancing a Connected World --_000_970cf81ffef1443eb2f59f584f0acd6bVAUSDITCHM2idirectnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Working Group,

 

DLEP-09 was posted yesterday, and contains the fixes= for issues brought up in reviews prior to IETF 92.

 

With DLEP-09, the authors formally request a 2-week = Working Group Last Call (WGLC). If the 2-week WGLC is granted, Last call co= mments would be due by May 1, 2015.

 

Regards,
Stan

 

Stan Ratliff  |  Architect, Applied Research<= /span>

VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Hernd= on, VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 123-4567

sratliff@i= direct.net  |  www.idirect.net

Connect with iDirect: Twitter.com/iDi= rect  |  Facebook.com/i= Direct

 

<= /p>

Advancing a Connected World

 <= /span>

 

--_000_970cf81ffef1443eb2f59f584f0acd6bVAUSDITCHM2idirectnet_-- --_004_970cf81ffef1443eb2f59f584f0acd6bVAUSDITCHM2idirectnet_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3003; creation-date="Fri, 17 Apr 2015 12:59:51 GMT"; modification-date="Fri, 17 Apr 2015 12:59:51 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --_004_970cf81ffef1443eb2f59f584f0acd6bVAUSDITCHM2idirectnet_-- From nobody Fri Apr 17 06:33:50 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDFA1B2C8A; Fri, 17 Apr 2015 06:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 vUSHezSCV4P4; Fri, 17 Apr 2015 06:33:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF31B1B2CBD; Fri, 17 Apr 2015 06:33:27 -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.0.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150417133327.3613.48361.idtracker@ietfa.amsl.com> Date: Fri, 17 Apr 2015 06:33:27 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] Last Call: (TLV Naming in the MANET Generalized Packet/Message Format) to Proposed Standard X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 17 Apr 2015 13:33:47 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'TLV Naming in the MANET Generalized Packet/Message Format' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-01. 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 TLVs (type-length-value structures) as defined by RFC5444 have both a type (one octet) and a type extension (one octet), together forming a full type (of two octets). RFC5444 sets up IANA registries for TLV types, specifying that an allocation of a TLV type entails creation of an IANA registry for the corresponding type extensions. In some cases, reserving all 256 type extensions for use for a common purpose for a given TLV is meaningful, and thus it makes sense to record a common name for such a TLV type (and all of its type extensions) in the corresponding IANA registries. An example of such is a LINK_METRIC TLV Type, with its type extensions reserved for use to be indicating the "kind" of metric expressed by the value of the TLV. In some other cases, there may not be 256 full types that share a common purpose and, as such, it is not meaningful to record a common name for all the type extensions for a TLV type in the corresponding IANA registries. Rather, it is appropriate to record an individual name per full type. This document reorganizes the naming of already allocated TLV types and type extensions in those registries to use names appropriately. It has no consequences in terms of any protocol implementation. This document also updates the Expert Review guidelines from RFC5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC5444. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-tlv-naming/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-tlv-naming/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 17 13:28:55 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E716C1A0266 for ; Fri, 17 Apr 2015 13:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 jXgzj1ToxWLI for ; Fri, 17 Apr 2015 13:28:52 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 E7CD31A0263 for ; Fri, 17 Apr 2015 13:28:51 -0700 (PDT) Received: by oica37 with SMTP id a37so82107861oic.0 for ; Fri, 17 Apr 2015 13:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lOogQuDXGjaOtDbrCYq1n+iOj57UNqDPzjZf36IyMrU=; b=AnQ9IdYBVB/vusVXh05kTlhYn6Lib2CpvD6G5KSDM8heJ0rdbJVrBWwp1h1CmRZRM3 CLozu3kbteQdKjsNavL6vkWH6BqNaj8m13qRb4gdfSi5vg3yDguKnoW+H4xrFFtMecyZ fIjpX8gHq8Q9dKTRmg5ymDtAXO+6buWVQq1Vjif0Jv3xbzTT+lngQFd58A9IidTMf95Z aA2TW96LYPRyv8uboQlB9U5Onb/b5cp0EsHukJx4NXuJwp2Mc9eJM13DeS2+aPEXrPPA bHaKx/4sjMJV4nqk06UaBQwLWK6f2PNZgJgybGNrnLIx1yb2Iotq4t29lekDecxMJEqF J2tA== MIME-Version: 1.0 X-Received: by 10.202.176.134 with SMTP id z128mr4369866oie.102.1429302531354; Fri, 17 Apr 2015 13:28:51 -0700 (PDT) Received: by 10.202.75.214 with HTTP; Fri, 17 Apr 2015 13:28:51 -0700 (PDT) In-Reply-To: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> Date: Fri, 17 Apr 2015 16:28:51 -0400 Message-ID: From: Justin Dean To: Mobile Ad Hoc Networks mailing list Content-Type: multipart/related; boundary=001a113d3082a891200513f16d21 Archived-At: Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 20:28:54 -0000 --001a113d3082a891200513f16d21 Content-Type: multipart/alternative; boundary=001a113d3082a8911d0513f16d20 --001a113d3082a8911d0513f16d20 Content-Type: text/plain; charset=UTF-8 I've looked over the document and feel that the changes are minor enough to continue the last call (due to the previous mix up). But due to said mix up, and the fact that the document has just been updated, I feel a 3 week last call is more appropriate at this point. More feedback from more eyes on the document will result in a better document. DLEP-09 last call to end on May 8th. Also a heads up that we are planning virtual interim meetings using the ietf's webex. The dates of those meetings will be posted to the list soon. Justin Dean On Fri, Apr 17, 2015 at 8:59 AM, Ratliff, Stanley wrote: > Hello Working Group, > > > > DLEP-09 was posted yesterday, and contains the fixes for issues brought up > in reviews prior to IETF 92. > > > > With DLEP-09, the authors formally request a 2-week Working Group Last > Call (WGLC). If the 2-week WGLC is granted, Last call comments would be due > by May 1, 2015. > > > > Regards, > Stan > > > ------------------------------ > > *Stan Ratliff *| Architect, Applied Research > > *VT iDirect *| 13861 Sunrise Valley Drive, Suite 300, Herndon, VA > 20171, USA > > T: +1 703 544-8520 | F: +1 222 123-4567 > > sratliff@idirect.net | www.idirect.net > > *Connect with iDirect: *Twitter.com/iDirect > | Facebook.com/iDirect > > > > *Advancing a Connected World* > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a113d3082a8911d0513f16d20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've looked over the document and feel = that the changes are minor enough to continue the last call (due to the pre= vious mix up).=C2=A0 But due to said mix up, and the fact that the document= has just been updated, I feel a 3 week last call is more appropriate at th= is point.=C2=A0 More feedback from more eyes on the document will result in= a better document.

DLEP-09 last call to end on May 8th.
Also a heads up that we are planning virtual interim meetings using= the ietf's webex.=C2=A0 The dates of those meetings will be posted to = the list soon.

Justin Dean

On Fri, Apr 17, 2015 at 8:59 AM, R= atliff, Stanley <sratliff@idirect.net> wrote:

Hello Working Group,

=C2=A0

DLEP-09 was posted yesterday, and contains the fixes= for issues brought up in reviews prior to IETF 92.

=C2=A0

With DLEP-09, the authors formally request a 2-week = Working Group Last Call (WGLC). If the 2-week WGLC is granted, Last call co= mments would be due by May 1, 2015.

=C2=A0

Regards,
Stan

=C2=A0

Stan Ratliff=C2=A0 |=C2=A0 Architect, Applied Research

VT iDirect=C2=A0 |=C2=A0 13861 Sunrise Valley Drive, Suite 300, Hernd= on, VA 20171, USA

T: +1 703 544-8520=C2=A0 |=C2=A0 F: +1 222 123-4567<= /u>

sratliff@idirect.net=C2=A0 |=C2=A0 www.idirect.net

Connect with iDirect: Twitter.com/iDirect=C2=A0 |=C2=A0 Facebook.com/iDirect=

=C2=A0

Advancing a Connected World

=C2=A0

=C2=A0


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


--001a113d3082a8911d0513f16d20-- --001a113d3082a891200513f16d21 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: c3b76da6ff01d313_0.0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --001a113d3082a891200513f16d21-- From nobody Fri Apr 17 13:40:23 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E221B2C5B for ; Fri, 17 Apr 2015 13:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 aGgyGNddfIor for ; Fri, 17 Apr 2015 13:40:18 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id DBD0D1AC3B7 for ; Fri, 17 Apr 2015 13:40:03 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,596,1422939600"; d="jpg'145?scan'145,208,217,145";a="17271444" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport.idirect.net with ESMTP; 17 Apr 2015 16:40:03 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 17 Apr 2015 16:40:02 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Fri, 17 Apr 2015 16:40:02 -0400 From: "Ratliff, Stanley" To: Justin Dean , Mobile Ad Hoc Networks mailing list Thread-Topic: [manet] DLEP-09 Thread-Index: AdB5Dijsuf08P0oXRc6vubghpHd05gAYHvCAAAgMP/A= Date: Fri, 17 Apr 2015 20:40:01 +0000 Message-ID: <14f3242407fb4666b4fb42899d5dda0b@VAUSDITCHM2.idirect.net> References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/related; boundary="_004_14f3242407fb4666b4fb42899d5dda0bVAUSDITCHM2idirectnet_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 20:40:21 -0000 --_004_14f3242407fb4666b4fb42899d5dda0bVAUSDITCHM2idirectnet_ Content-Type: multipart/alternative; boundary="_000_14f3242407fb4666b4fb42899d5dda0bVAUSDITCHM2idirectnet_" --_000_14f3242407fb4666b4fb42899d5dda0bVAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gd29ya2luZyBncm91cCDigJMNCg0KSSB3YW50IHRvIHNvbGljaXQgb3RoZXIgb3Bpbmlv bnMgb24gdGhpcyBpc3N1ZS4gVG8gYmUgaG9uZXN0LCBKdXN0aW4gYW5kIEkgYXJlIG5vdCBpbiBh Z3JlZW1lbnQuIEnigJltIG9mIHRoZSBvcGluaW9uIHRoYXQsIGlmIHdlIGV4dGVuZCB0aGUgV0dM QyBwZXJpb2Qgb24gRExFUCB0byAzLXdlZWtzLCB3ZSBzaG91bGQgbWFrZSBpdCBzdGFuZGluZyBw cmFjdGljZSB0byBleHRlbmQgdGhlIFdHTEMgdG8gYSAzLXdlZWsgcGVyaW9kIG9uICphbGwqIHN1 YnNlcXVlbnQgd29yayBkb25lIGJ5IE1BTkVULg0KDQpPcGluaW9ucz8NCg0KUmVnYXJkcywNClN0 YW4NCg0KDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBKdXN0aW4gRGVhbg0KU2VudDogRnJpZGF5LCBBcHJpbCAxNywgMjAxNSA0OjI5IFBN DQpUbzogTW9iaWxlIEFkIEhvYyBOZXR3b3JrcyBtYWlsaW5nIGxpc3QNClN1YmplY3Q6IFJlOiBb bWFuZXRdIERMRVAtMDkNCg0KSSd2ZSBsb29rZWQgb3ZlciB0aGUgZG9jdW1lbnQgYW5kIGZlZWwg dGhhdCB0aGUgY2hhbmdlcyBhcmUgbWlub3IgZW5vdWdoIHRvIGNvbnRpbnVlIHRoZSBsYXN0IGNh bGwgKGR1ZSB0byB0aGUgcHJldmlvdXMgbWl4IHVwKS4gIEJ1dCBkdWUgdG8gc2FpZCBtaXggdXAs IGFuZCB0aGUgZmFjdCB0aGF0IHRoZSBkb2N1bWVudCBoYXMganVzdCBiZWVuIHVwZGF0ZWQsIEkg ZmVlbCBhIDMgd2VlayBsYXN0IGNhbGwgaXMgbW9yZSBhcHByb3ByaWF0ZSBhdCB0aGlzIHBvaW50 LiAgTW9yZSBmZWVkYmFjayBmcm9tIG1vcmUgZXllcyBvbiB0aGUgZG9jdW1lbnQgd2lsbCByZXN1 bHQgaW4gYSBiZXR0ZXIgZG9jdW1lbnQuDQoNCkRMRVAtMDkgbGFzdCBjYWxsIHRvIGVuZCBvbiBN YXkgOHRoLg0KDQpBbHNvIGEgaGVhZHMgdXAgdGhhdCB3ZSBhcmUgcGxhbm5pbmcgdmlydHVhbCBp bnRlcmltIG1lZXRpbmdzIHVzaW5nIHRoZSBpZXRmJ3Mgd2ViZXguICBUaGUgZGF0ZXMgb2YgdGhv c2UgbWVldGluZ3Mgd2lsbCBiZSBwb3N0ZWQgdG8gdGhlIGxpc3Qgc29vbi4NCkp1c3RpbiBEZWFu DQoNCk9uIEZyaSwgQXByIDE3LCAyMDE1IGF0IDg6NTkgQU0sIFJhdGxpZmYsIFN0YW5sZXkgPHNy YXRsaWZmQGlkaXJlY3QubmV0PG1haWx0bzpzcmF0bGlmZkBpZGlyZWN0Lm5ldD4+IHdyb3RlOg0K SGVsbG8gV29ya2luZyBHcm91cCwNCg0KRExFUC0wOSB3YXMgcG9zdGVkIHllc3RlcmRheSwgYW5k IGNvbnRhaW5zIHRoZSBmaXhlcyBmb3IgaXNzdWVzIGJyb3VnaHQgdXAgaW4gcmV2aWV3cyBwcmlv ciB0byBJRVRGIDkyLg0KDQpXaXRoIERMRVAtMDksIHRoZSBhdXRob3JzIGZvcm1hbGx5IHJlcXVl c3QgYSAyLXdlZWsgV29ya2luZyBHcm91cCBMYXN0IENhbGwgKFdHTEMpLiBJZiB0aGUgMi13ZWVr IFdHTEMgaXMgZ3JhbnRlZCwgTGFzdCBjYWxsIGNvbW1lbnRzIHdvdWxkIGJlIGR1ZSBieSBNYXkg MSwgMjAxNS4NCg0KUmVnYXJkcywNClN0YW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClN0YW4gUmF0bGlmZiAgfCAgQXJjaGl0ZWN0LCBBcHBsaWVkIFJlc2VhcmNoDQpWVCBp RGlyZWN0ICB8ICAxMzg2MSBTdW5yaXNlIFZhbGxleSBEcml2ZSwgU3VpdGUgMzAwLCBIZXJuZG9u LCBWQSAyMDE3MSwgVVNBDQpUOiArMSA3MDMgNTQ0LTg1MjA8dGVsOiUyQjElMjA3MDMlMjA1NDQt ODUyMD4gIHwgIEY6ICsxIDIyMiAxMjMtNDU2Nw0Kc3JhdGxpZmZAaWRpcmVjdC5uZXQ8bWFpbHRv OnNyYXRsaWZmQGlkaXJlY3QubmV0PiAgfCAgd3d3LmlkaXJlY3QubmV0PGh0dHA6Ly93d3cuaWRp cmVjdC5uZXQ+DQpDb25uZWN0IHdpdGggaURpcmVjdDogVHdpdHRlci5jb20vaURpcmVjdDxodHRw czovL3R3aXR0ZXIuY29tL2lkaXJlY3Q+ICB8ICBGYWNlYm9vay5jb20vaURpcmVjdDxodHRwczov L3d3dy5mYWNlYm9vay5jb20vaWRpcmVjdD4NCg0KW2NpZDppbWFnZTAwMS5qcGdAMDFEMDc5MkQu MjVBREM5RTBdDQpBZHZhbmNpbmcgYSBDb25uZWN0ZWQgV29ybGQNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QN Cm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0K --_000_14f3242407fb4666b4fb42899d5dda0bVAUSDITCHM2idirectnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IZWxsbyB3b3Jr aW5nIGdyb3VwIOKAkw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JIHdhbnQgdG8gc29saWNpdCBvdGhlciBvcGluaW9ucyBvbiB0aGlzIGlzc3VlLiBUbyBiZSBo b25lc3QsIEp1c3RpbiBhbmQgSSBhcmUgbm90IGluIGFncmVlbWVudC4gSeKAmW0gb2YgdGhlIG9w aW5pb24gdGhhdCwgaWYgd2UgZXh0ZW5kIHRoZSBXR0xDIHBlcmlvZCBvbiBETEVQDQogdG8gMy13 ZWVrcywgd2Ugc2hvdWxkIG1ha2UgaXQgc3RhbmRpbmcgcHJhY3RpY2UgdG8gZXh0ZW5kIHRoZSBX R0xDIHRvIGEgMy13ZWVrIHBlcmlvZCBvbiAqPGI+YWxsPC9iPiogc3Vic2VxdWVudCB3b3JrIGRv bmUgYnkgTUFORVQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pk9waW5pb25zPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YnI+DQpSZWdhcmRzLDxicj4NClN0YW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gbWFuZXQgW21haWx0bzptYW5ldC1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gRGVhbjxicj4NCjxiPlNl bnQ6PC9iPiBGcmlkYXksIEFwcmlsIDE3LCAyMDE1IDQ6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IE1v YmlsZSBBZCBIb2MgTmV0d29ya3MgbWFpbGluZyBsaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbbWFuZXRdIERMRVAtMDk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSd2ZSBsb29rZWQgb3ZlciB0aGUg ZG9jdW1lbnQgYW5kIGZlZWwgdGhhdCB0aGUgY2hhbmdlcyBhcmUgbWlub3IgZW5vdWdoIHRvIGNv bnRpbnVlIHRoZSBsYXN0IGNhbGwgKGR1ZSB0byB0aGUgcHJldmlvdXMgbWl4IHVwKS4mbmJzcDsg QnV0IGR1ZSB0byBzYWlkIG1peCB1cCwgYW5kIHRoZSBmYWN0IHRoYXQgdGhlIGRvY3VtZW50IGhh cyBqdXN0IGJlZW4gdXBkYXRlZCwgSSBmZWVsIGEgMyB3ZWVrIGxhc3QgY2FsbCBpcw0KIG1vcmUg YXBwcm9wcmlhdGUgYXQgdGhpcyBwb2ludC4mbmJzcDsgTW9yZSBmZWVkYmFjayBmcm9tIG1vcmUg ZXllcyBvbiB0aGUgZG9jdW1lbnQgd2lsbCByZXN1bHQgaW4gYSBiZXR0ZXIgZG9jdW1lbnQuPGJy Pg0KPGJyPg0KRExFUC0wOSBsYXN0IGNhbGwgdG8gZW5kIG9uIE1heSA4dGguPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PkFsc28gYSBoZWFkcyB1cCB0aGF0IHdlIGFyZSBwbGFubmluZyB2aXJ0dWFsIGludGVyaW0gbWVl dGluZ3MgdXNpbmcgdGhlIGlldGYncyB3ZWJleC4mbmJzcDsgVGhlIGRhdGVzIG9mIHRob3NlIG1l ZXRpbmdzIHdpbGwgYmUgcG9zdGVkIHRvIHRoZSBsaXN0IHNvb24uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3RpbiBEZWFuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBcHIgMTcs IDIwMTUgYXQgODo1OSBBTSwgUmF0bGlmZiwgU3RhbmxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNy YXRsaWZmQGlkaXJlY3QubmV0IiB0YXJnZXQ9Il9ibGFuayI+c3JhdGxpZmZAaWRpcmVjdC5uZXQ8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGVsbG8gV29ya2luZyBHcm91cCw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkRMRVAtMDkgd2FzIHBvc3RlZCB5ZXN0ZXJkYXksIGFuZCBjb250YWlu cyB0aGUgZml4ZXMgZm9yIGlzc3VlcyBicm91Z2h0IHVwIGluIHJldmlld3MgcHJpb3IgdG8gSUVU RiA5Mi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2l0aCBETEVQLTA5LCB0aGUgYXV0 aG9ycyBmb3JtYWxseSByZXF1ZXN0IGEgMi13ZWVrIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIChX R0xDKS4gSWYgdGhlIDItd2VlayBXR0xDIGlzIGdyYW50ZWQsIExhc3QgY2FsbCBjb21tZW50cyB3 b3VsZCBiZSBkdWUgYnkgTWF5IDEsIDIwMTUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlJlZ2FyZHMsPGJyPg0KU3RhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2xpbmUtaGVpZ2h0OjE0LjBwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPg0KPGhyIHNpemU9IjEiIHdpZHRoPSIxMDAlIiBub3NoYWRlPSIiIHN0eWxlPSJj b2xvcjojQkZCRkJGIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjMu MHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwNkY2RiI+U3RhbiBSYXRsaWZmJm5ic3A7DQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzA2RjZGIj58Jm5ic3A7IEFyY2hpdGVjdCwg QXBwbGllZCBSZXNlYXJjaDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjMuMHB0O3Rl eHQtYXV0b3NwYWNlOm5vbmUiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MDZGNkYiPlZUIGlE aXJlY3QmbmJzcDsNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MDZGNkYiPnwmbmJz cDsgMTM4NjEgU3VucmlzZSBWYWxsZXkgRHJpdmUsIFN1aXRlIDMwMCwgSGVybmRvbiwgVkEgMjAx NzEsIFVTQTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjMuMHB0O3RleHQtYXV0b3Nw YWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MDZGNkYiPlQ6IDxhIGhyZWY9InRlbDol MkIxJTIwNzAzJTIwNTQ0LTg1MjAiIHRhcmdldD0iX2JsYW5rIj4NCiYjNDM7MSA3MDMgNTQ0LTg1 MjA8L2E+Jm5ic3A7IHwmbmJzcDsgRjogJiM0MzsxIDIyMiAxMjMtNDU2Nzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjMuMHB0O3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj48YSBocmVmPSJtYWlsdG86c3JhdGxpZmZAaWRpcmVjdC5uZXQiIHRhcmdldD0iX2JsYW5r Ij5zcmF0bGlmZkBpZGlyZWN0Lm5ldDwvYT48dT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jm5i c3A7DQo8L3NwYW4+PC91PjxzcGFuIHN0eWxlPSJjb2xvcjojNzA2RjZGIj58Jm5ic3A7IDwvc3Bh bj48L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5pZGlyZWN0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+d3d3LmlkaXJlY3QubmV0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjMuMHB0O3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM3MDZGNkYiPkNvbm5lY3Qgd2l0aCBpRGlyZWN0Og0KPC9zcGFuPjwvYj48YSBocmVmPSJo dHRwczovL3R3aXR0ZXIuY29tL2lkaXJlY3QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PlR3aXR0ZXIuY29tL2lEaXJlY3Q8L3NwYW4+PC9hPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibHVl Ij4mbmJzcDsNCjwvc3Bhbj48L3U+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MDZGNkYiPnwmbmJzcDsN Cjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5mYWNlYm9vay5jb20vaWRpcmVjdCIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+RmFjZWJvb2suY29tL2lEaXJlY3Q8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206My4wcHQ7dGV4dC1hdXRvc3BhY2U6bm9uZSI+DQo8Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjMuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwNkY2RiI+PGltZyBib3Jk ZXI9IjAiIHdpZHRoPSIxMzEiIGhlaWdodD0iMjYiIGlkPSJfeDAwMDBfaTEwMjYiIHNyYz0iY2lk OmltYWdlMDAxLmpwZ0AwMUQwNzkyRC4yNUFEQzlFMCI+PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjMuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwNkY2RiI+QWR2YW5j aW5nIGEgQ29ubmVjdGVkIFdvcmxkPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzt0ZXh0LWF1dG9zcGFjZTpub25lIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3Jn Ij5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_14f3242407fb4666b4fb42899d5dda0bVAUSDITCHM2idirectnet_-- --_004_14f3242407fb4666b4fb42899d5dda0bVAUSDITCHM2idirectnet_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3003; creation-date="Fri, 17 Apr 2015 20:40:01 GMT"; modification-date="Fri, 17 Apr 2015 20:40:01 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --_004_14f3242407fb4666b4fb42899d5dda0bVAUSDITCHM2idirectnet_-- From nobody Fri Apr 17 14:10:30 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458E71B2DA8 for ; Fri, 17 Apr 2015 14:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_PASS=-0.001] autolearn=ham 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 Fw6M7N4P2f7g for ; Fri, 17 Apr 2015 14:10:27 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::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 6FF811B2D89 for ; Fri, 17 Apr 2015 14:10:26 -0700 (PDT) Received: by widjs5 with SMTP id js5so42197659wid.1 for ; Fri, 17 Apr 2015 14:10:25 -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-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=m3lNA1bEy58im5KgMjmRpVzGO5kzVLJUr59/04Sv4Nw=; b=rAIaFBBYUoKQrt1DXb2itLXoLFvgUEvG/yUKJf4L9u2uXkrgnhjirw3luPmgKL2ghD vJwXMxAaXLXZCG8Q0c1tIjP86ELM52yC9C2VeLDl4sttoTqDcY0Ol7zOUUFDV3cwmVAT 3jCXXvBKn7X5sRabfByjg8HHBCXx9Nzasrz50yXXdIqUt2konSv2gjG2IKDyu2Xr0j0j Jl53zhjPgkxGo/GP+lWzcVz6CtnbII+3i5l7nWb0OI8pWmXJxrDIO9q7r/E49lT9dyID s1o68rcmppwrrqsciL/LjOD8tw85mg/DAOsoiNBQ8eDaVVSom/NttCIfOhuJHj0ewmhU Y2yQ== X-Received: by 10.194.60.173 with SMTP id i13mr9305766wjr.124.1429305025231; Fri, 17 Apr 2015 14:10:25 -0700 (PDT) Received: from [10.4.192.100] (dab-crx1-h-26-3.dab.02.net. [82.132.225.80]) by mx.google.com with ESMTPSA id vq9sm16191690wjc.6.2015.04.17.14.10.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Apr 2015 14:10:23 -0700 (PDT) References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <14f3242407fb4666b4fb42899d5dda0b@VAUSDITCHM2.idirect.net> Mime-Version: 1.0 (1.0) In-Reply-To: <14f3242407fb4666b4fb42899d5dda0b@VAUSDITCHM2.idirect.net> Content-Type: multipart/alternative; boundary=Apple-Mail-5C496820-F407-4DA2-BD86-D5BFE72EB155 Content-Transfer-Encoding: 7bit Message-Id: <09124CDB-D105-4150-9428-FA7694CB01AD@gmail.com> X-Mailer: iPhone Mail (12D508) From: Christopher Dearlove Date: Fri, 17 Apr 2015 22:10:19 +0100 To: "Ratliff, Stanley" Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 21:10:29 -0000 --Apple-Mail-5C496820-F407-4DA2-BD86-D5BFE72EB155 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable WGLCs are naturally variable, depending on the nature of the document, it's n= ot one size fits all. We've had 2 and 4 week WGLCs in the past. =46rom my re= collection (subject to correction) of the lengths set in the past, and that t= his is not a trivial document, 4 weeks rather than 2 weeks would have fitted= precedent. This is not an extension to 3 weeks. Note, I'm not disputing 3 weeks, I'm disputing this sets any sort of precede= nt. And Justin is the neutral WG chair here. (Just found the WGLC announcement of OLSRv2. You set that at 30 days.) --=20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 17 Apr 2015, at 21:40, Ratliff, Stanley wrote: >=20 > Hello working group =E2=80=93 > =20 > I want to solicit other opinions on this issue. To be honest, Justin and I= are not in agreement. I=E2=80=99m of the opinion that, if we extend the WGL= C period on DLEP to 3-weeks, we should make it standing practice to extend t= he WGLC to a 3-week period on *all* subsequent work done by MANET. > =20 > Opinions? >=20 > Regards, > Stan > =20 > =20 > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean > Sent: Friday, April 17, 2015 4:29 PM > To: Mobile Ad Hoc Networks mailing list > Subject: Re: [manet] DLEP-09 > =20 > I've looked over the document and feel that the changes are minor enough t= o continue the last call (due to the previous mix up). But due to said mix u= p, and the fact that the document has just been updated, I feel a 3 week las= t call is more appropriate at this point. More feedback from more eyes on t= he document will result in a better document. >=20 > DLEP-09 last call to end on May 8th. > =20 > Also a heads up that we are planning virtual interim meetings using the ie= tf's webex. The dates of those meetings will be posted to the list soon. >=20 > Justin Dean > =20 > On Fri, Apr 17, 2015 at 8:59 AM, Ratliff, Stanley w= rote: > Hello Working Group, > =20 > DLEP-09 was posted yesterday, and contains the fixes for issues brought up= in reviews prior to IETF 92. > =20 > With DLEP-09, the authors formally request a 2-week Working Group Last Cal= l (WGLC). If the 2-week WGLC is granted, Last call comments would be due by M= ay 1, 2015. > =20 > Regards, > Stan > =20 > Stan Ratliff | Architect, Applied Research > VT iDirect | 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, U= SA > T: +1 703 544-8520 | F: +1 222 123-4567 > sratliff@idirect.net | www.idirect.net > Connect with iDirect: Twitter.com/iDirect | Facebook.com/iDirect > =20 > > Advancing a Connected World > =20 > =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-5C496820-F407-4DA2-BD86-D5BFE72EB155 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
WGLCs are naturally variable, dependin= g on the nature of the document, it's not one size fits all. We've had 2 and= 4 week WGLCs in the past. =46rom my recollection (subject to correction) of= the lengths set in the past, and that this is not a trivial document, 4 wee= ks rather than 2 weeks would have fitted precedent. This is not an extension= to 3 weeks.

Note, I'm not disputing 3 weeks, I'm d= isputing this sets any sort of precedent. And Justin is the neutral WG chair= here.

(Just found the WGLC announcement of OLSRv2.= You set that at 30 days.)

-- 
Christopher Dearlove
christopher.dearlove@gma= il.com (iPhone)

On 17 Apr 2015, a= t 21:40, Ratliff, Stanley <sratli= ff@idirect.net> wrote:

Hello working group =E2=80=93

 

I want to solicit other opinions on thi= s issue. To be honest, Justin and I are not in agreement. I=E2=80=99m of the= opinion that, if we extend the WGLC period on DLEP to 3-weeks, we should make it standing practice to extend the WGLC to a 3-w= eek period on *all* subsequent work done by MANET.

 

Opinions?


Regards,
Stan

 

 

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean
Sent: Friday, April 17, 2015 4:29 PM
To: Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] DLEP-09

 

I've looked over the document and feel that the chang= es are minor enough to continue the last call (due to the previous mix up).&= nbsp; But due to said mix up, and the fact that the document has just been u= pdated, I feel a 3 week last call is more appropriate at this point.  More feedback from more eyes on the d= ocument will result in a better document.

DLEP-09 last call to end on May 8th.

 

Also a heads up that w= e are planning virtual interim meetings using the ietf's webex.  The da= tes of those meetings will be posted to the list soon.

Justin Dean

 

On Fri, Apr 17, 2015 at 8:59 AM, Ratliff, Stanley <= ;sratliff@idirect.= net> wrote:

Hello Working Group,

 

DLEP-09 was posted yesterday, and contains the fixes for issues brou= ght up in reviews prior to IETF 92.

 

With DLEP-09, the authors formally request a 2-week Working Group La= st Call (WGLC). If the 2-week WGLC is granted, Last call comments would be d= ue by May 1, 2015.

 

Regards,
Stan

 

Stan Ratliff  |  Architect, Applied Research<= /p>

VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Herndon= , VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 123-4567

sratliff@idirect.net  |  www.idirect.net

Connect with iDirect: Twitter.co= m/iDirect  |  Facebook.c= om/iDirect

 

<image001.jpg>

Advancing a Connected World

 

 


_______________________________________________
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-5C496820-F407-4DA2-BD86-D5BFE72EB155-- From nobody Fri Apr 17 14:25:01 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E55A1B2F6A for ; Fri, 17 Apr 2015 14:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 rDBqSc3pEBLx for ; Fri, 17 Apr 2015 14:24:57 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 919921B2F14 for ; Fri, 17 Apr 2015 14:24:57 -0700 (PDT) Received: by paboj16 with SMTP id oj16so137421258pab.0 for ; Fri, 17 Apr 2015 14:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nD3lHaqGLQxS/0OpAA0yWSBq2C7KOLt3aRbn6f8suEE=; b=L4zVxYZ4Tg8Pa8yaFm1OcOI3iS/3M4txnltVGRckymYHym78zIPRKLzeDL6Aj/4h8S INkRdzzr+m+tmqR3VohYabgUeEpCWbwCu+mhelXTXrFjo3wpNElTafKtTZ6pa84ExmOs S0/gXdoU//y+6R/8g2KOFNk5BuNDnQ07ZALeg= 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:date :message-id:subject:from:to:cc:content-type; bh=nD3lHaqGLQxS/0OpAA0yWSBq2C7KOLt3aRbn6f8suEE=; b=dm/44Fk5BzNMDhIrrRDfadv5sDnzZ5yuG6/IibwdI948sfmj3441OfVm9dui9dqhi4 KmfJtKahzw/8gNisaVK2xUQ7YSIPnz0xfgpiQY+yPhi3bn+pKwy603b8PonmxNxvmSnZ qQ8oar4opBUJp5W9omP9v1F4T7zmtAYlJnB+VZG8bqutH2PkA4lkZK/Jz8Fu7ZwOXI0w oOmpXLtpK89vU2DZZFSs6Sri9y1Jd+lOpftX02oFSOSHutjXqS3oXhEJ49m7bfw9wSET abCJ6kEsJajJfTekQp3zqjPjDK8dV/Mh4K6yDa9jn76Av4b76nGM0bQL0BFHGWBRse9j y1jg== X-Gm-Message-State: ALoCoQkKnsUPFYw29PDIud/3Y7OIa2Ue6L1Cw44jdinldV90E+cC4rqtyfzcYVaA0gceEYq4Q/xM MIME-Version: 1.0 X-Received: by 10.70.133.66 with SMTP id pa2mr8817418pdb.164.1429305897149; Fri, 17 Apr 2015 14:24:57 -0700 (PDT) Received: by 10.70.81.134 with HTTP; Fri, 17 Apr 2015 14:24:57 -0700 (PDT) In-Reply-To: <14f3242407fb4666b4fb42899d5dda0b@VAUSDITCHM2.idirect.net> References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <14f3242407fb4666b4fb42899d5dda0b@VAUSDITCHM2.idirect.net> Date: Fri, 17 Apr 2015 14:24:57 -0700 Message-ID: From: Ulrich Herberg To: "Ratliff, Stanley" Content-Type: multipart/related; boundary=001a11c3d65846a45f0513f236cc Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 21:24:59 -0000 --001a11c3d65846a45f0513f236cc Content-Type: multipart/alternative; boundary=001a11c3d65846a45b0513f236cb --001a11c3d65846a45b0513f236cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stan, I agree with Justin's request for a longer WGLC, but I don't believe that this needs to be a standing practice for all future documents. DLEP is a long document and has changed very recently. Justin is not an author of the document. Best regards Ulrich On Fri, Apr 17, 2015 at 1:40 PM, Ratliff, Stanley wrote: > Hello working group =E2=80=93 > > > > I want to solicit other opinions on this issue. To be honest, Justin and = I > are not in agreement. I=E2=80=99m of the opinion that, if we extend the W= GLC period > on DLEP to 3-weeks, we should make it standing practice to extend the WGL= C > to a 3-week period on **all** subsequent work done by MANET. > > > > Opinions? > > > Regards, > Stan > > > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Justin Dean > *Sent:* Friday, April 17, 2015 4:29 PM > *To:* Mobile Ad Hoc Networks mailing list > *Subject:* Re: [manet] DLEP-09 > > > > I've looked over the document and feel that the changes are minor enough > to continue the last call (due to the previous mix up). But due to said > mix up, and the fact that the document has just been updated, I feel a 3 > week last call is more appropriate at this point. More feedback from mor= e > eyes on the document will result in a better document. > > DLEP-09 last call to end on May 8th. > > > > Also a heads up that we are planning virtual interim meetings using the > ietf's webex. The dates of those meetings will be posted to the list soo= n. > > Justin Dean > > > > On Fri, Apr 17, 2015 at 8:59 AM, Ratliff, Stanley > wrote: > > Hello Working Group, > > > > DLEP-09 was posted yesterday, and contains the fixes for issues brought u= p > in reviews prior to IETF 92. > > > > With DLEP-09, the authors formally request a 2-week Working Group Last > Call (WGLC). If the 2-week WGLC is granted, Last call comments would be d= ue > by May 1, 2015. > > > > Regards, > Stan > > > ------------------------------ > > *Stan Ratliff *| Architect, Applied Research > > *VT iDirect *| 13861 Sunrise Valley Drive, Suite 300, Herndon, VA > 20171, USA > > T: +1 703 544-8520 | F: +1 222 123-4567 > > sratliff@idirect.net | www.idirect.net > > *Connect with iDirect: *Twitter.com/iDirect > | Facebook.com/iDirect > > > > *Advancing a Connected World* > > > > > > > _______________________________________________ > 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 > > --001a11c3d65846a45b0513f236cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stan,

I agree with Justin's request= for a longer WGLC, but I don't believe that this needs to be a standin= g practice for all future documents. DLEP is a long document and has change= d very recently. Justin is not an author of the document.

Best regards
Ulrich

On Fri, Apr 17, 2015 at 1:40 PM, Ratliff, S= tanley <sratliff@idirect.net> wrote:

Hello working group =E2=80=93

=C2=A0

I want to solicit other opinions on t= his issue. To be honest, Justin and I are not in agreement. I=E2=80=99m of = the opinion that, if we extend the WGLC period on DLEP to 3-weeks, we should make it standing practice to extend the WGLC to a 3-= week period on *all* subsequent work done by MANET.

=C2=A0

Opinions?


Regards,
Stan

=C2=A0

=C2=A0

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean
Sent: Friday, April 17, 2015 4:29 PM
To: Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] DLEP-09

=C2=A0

I've looked over the document and feel that the = changes are minor enough to continue the last call (due to the previous mix= up).=C2=A0 But due to said mix up, and the fact that the document has just= been updated, I feel a 3 week last call is more appropriate at this point.=C2=A0 More feedback from more eyes on the = document will result in a better document.

DLEP-09 last call to end on May 8th.

=C2=A0

Also a heads up that = we are planning virtual interim meetings using the ietf's webex.=C2=A0 = The dates of those meetings will be posted to the list soon.<= /p>

Justin Dean

=C2=A0

On Fri, Apr 17, 2015 at 8:59 AM, Ratliff, Stanley &l= t;sratliff@idirec= t.net> wrote:

Hello Working Group,

=C2=A0

DLEP-09 was posted yesterday, and contains the fixes= for issues brought up in reviews prior to IETF 92.

=C2=A0

With DLEP-09, the authors formally request a 2-week = Working Group Last Call (WGLC). If the 2-week WGLC is granted, Last call co= mments would be due by May 1, 2015.

=C2=A0

Regards,
Stan

=C2=A0

Stan Ra= tliff=C2=A0 |=C2=A0 Architect, Applied Research=

VT iDirect=C2=A0 |=C2=A0 13861 Sunrise Valley Drive, Suite 300, Hernd= on, VA 20171, USA

T: +1 703 544-8520=C2=A0 |=C2=A0 F: +1 222 123-4567

sratliff@idirect.ne= t=C2=A0 |=C2=A0 www.idirect.net=

Connect with iDirect: Twitter.= com/iDirect=C2=A0 |=C2=A0 Faceboo= k.com/iDirect

=C2=A0

Advanci= ng a Connected World

=C2=A0

=C2=A0


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

=C2=A0


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


--001a11c3d65846a45b0513f236cb-- --001a11c3d65846a45f0513f236cc Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 778ef2350b73b1e4_0.0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --001a11c3d65846a45f0513f236cc-- From nobody Sat Apr 18 18:43:00 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA811AC3C1; Sat, 18 Apr 2015 16:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 gqjgxMhc4o7I; Sat, 18 Apr 2015 16:27:27 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id F0DF71AC3BB; Sat, 18 Apr 2015 16:27:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nvKq1/R6DzrBB1K0kTeBR7R8A51sCHIL6PtohBM7RDKDwUeabifUT37ebs+31NzV; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Yjc8z-00037y-Kv; Sat, 18 Apr 2015 19:27:25 -0400 Received: from 76.254.50.248 by webmail.earthlink.net with HTTP; Sat, 18 Apr 2015 19:27:25 -0400 Message-ID: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Sat, 18 Apr 2015 16:27:25 -0700 (GMT-07:00) From: Randy Presuhn To: manet@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f8911537d81312d8c217761dde4d378d2d5f2c5a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.52 Archived-At: X-Mailman-Approved-At: Sat, 18 Apr 2015 18:42:58 -0700 Cc: disman@ietf.org, mib-doctors@ietf.org Subject: [manet] comments on draft-ietf-manet-report-mib-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 23:27:29 -0000 Hi - I was asked to take a look at draft-ietf-manet-report-mib-04. This is *not* a full MIB doctor review; in my opinion some fundamental issues need to be resolved before a detailed review (either from a MIB doctor or disman perspective) would be worthwhile. These are mostly just top-level issues that absolutely need to be resolved. I fear that even though the questions aren't terribly difficult, the fixes may result in significant document churn. There are also some odds and ends that jumped out that should be fixed before bothering with a serious review. I didn't go into a lot of detail because the sheer number of problems would make any such attempt seem like a DoS attack. The categories here are: (1) data type difficulties (2) time stamping (3) access control (4) odds and ends (5) questions of power Data Type Difficulties Location: Abstract and elswhere Example of Current text: In particular, it describes objects for configuring autonomous report generation on any device that supports MIBs containing objects that resolve to type Integer32 (i.e., Integer32, Counter, Gauge, or TimeTicks). to be used for performance monitoring. Problems: - typographical nit: misplaced "." after ")" - technical: "Counter" is not an SMIv2 type. I assume "Counter32" is intended. If inclusion of Counter64 is also intended, there are other problems. - technical: "Gauge" is not an SMIv2 type. I assume "Gauge32" is intended. - technical: the range of type Integer32 (defined in RFC 2578) does not cover the entire ranges of type Counter32, Gauge32, or TimeTicks, as defined in RFC 3416. The SMI type *Unsigned32* does cover the same ranges. - technical: the use of "resolve" is questionable, since all of the data types mentioned have distinct ASN.1 tags. (RFC 3416 section 3) It gets worse. The definitions for reportSampledCurrentMeasurementValue and reportSampledHistoricalReportsValue limit their ranges to 1 to 2,147,483,647. This means that samples of Counter32, Gauge32, and TimeTicks with values of 0 or anything in the range from 2,147,483,647 to 4,294,967,295 cannot be represented. The reportSampledCurrentMeasurementStatus and the reportSampledHistoricalMeasurementStatus OBJECT-TYPEs appear to be an attempt to address this problem, and would *almost* work if the MeasurementValue were of type Unsigned32, and if its range were not constrained. However, if the module functioned as though sampled data, regardless of type, were "cast" to Unsigned32, then the valuePositive(2) and valueNegative(3) aren't really needed, since the signedness of the sampled values can be recovered from reportSampledStudyOid. Time Stamping There are a bunch of concerns related to time stamping. - several OBJECT-TYPE definitions have impossible syntaxes. "sysUptime" is not a syntax. It should not be IMPORTed. For reportSampledCurrentMeasurementTime and for reportSampledHistoricalMeasurementTime you intend to use a syntax of "TimeStamp" - HOWEVER, there is a health warning attached to the TimeStamp textual convention in RFC 2579, and it applies here. Firstly, it applies because the set of values permitted for reportSampledStudySamplingInterval means it is possible to construct a single report in which the sample times are ambiguous. More significantly, for historical reports, especially for "archival" purposes, the sample times are almost certainly ambiguous. Consequently, I think there needs to be a re-think of whether this is the correct data type for the intended use. - Many counter objects have "discontinuity indicators" other than sysUpTime. This module does not provide a straightforward way to cope with these. See RFC 2981 (search for "discontinuity") to see one approach. - reportSampledStudySamplingInterval may be modified during a report. This means that conventional algorithms for detecting sysUpTime discontinuities within a report may not work. Access Control There are a couple of ways in which access control considerations might affect the design of this module. The presence of reportSampledStudyOwner suggests that someone was thinking about this, but some changes are needed to make things work. (1) reportSampledControlEntry should have an INDEX of { reportSampledStudyOwner, reportSampledStudyIndex } This is necessary if you want to be able to limit access to specific studies to specific users in a reasonable way, and to prevent collisions between users during the creation of studies. (2) Likewise, reportSampledCurrentReportsStatusEntry should also have an INDEX of { reportSampledStudyOwner, reportSampledStudyIndex }, reportSampledCurrentReportsEntry should have { reportSampledStudyIndex, reportSampledCurrentMeasurementIndex } reportSampledHistoricalReportsEntry should have { reportSampledStudyOwner, reportSampledStudyIndex, reportSampledHistoricalReportIndex, reportSampledHistoricalMeasurementIndex } (3) A consequence is that (for example) reportSampledStudyIndex only needs to be unique for a given owner, and not among all studies. Note that reportSampledDataCollectionFailure suffers from the "who's buried in Grant's Tomb" problem, and can be simplified. A second way in which access control matters here is that the sampling process should not circumvent access control. I strongly urge putting in explicit language about this. I'd suggest the following as a starting point for discussion: Security for local access effectively requires recording appropriate security credentials of the creator of a reportSampledControlEntry and using those to access the local objects. These security credentials are parameters necessary as inputs to isAccessAllowed from the Architecture for Describing SNMP Management Frameworks. The system MUST (conceptually) use isAccessAllowed at the time of each access (not just creation of the reportSampledControlEntry) to ensure that it does not permit unauthorized access. When using VACM, the security administrator SHOULD ensure that access permitted to the collected data and notifications (that is, access to reportSampledCurrentReportsStatusTable.*., reportSampledCurrentReportsTable.*., and reportSampledHistoricalReportsTable.*.) is limited to the 's appropriate VACM group. Odds and ends: It's pretty obvious that this module has not seen a MIB compiler recently. In addition to the syntactic problem, there are some glaring stylistic issues that, if fixed now, will make an eventual MIB doctor review go a lot smoother. (1) Use of data types. Every single use of Integer32 in this module is arguably incorrect. Unsigned32 would be a better choice, since these are all sub-typed to exclude negative values. (2) Use of data types. reportSampledStudySamplingInterval seems like it should make use of RFC 2579 TimeInterval, perhaps constrained to be at least 10. (3) Use of UNITS. Though it's a little unusual (but not unheard-of) to use UNITS with non-counter types, a value of "count" in, for example, reportSampledStudyMaximumNumberOfHistoricalReports, is really not helpful. In that particular case, "reports" would make more sense. (4) Attention to error cases: there are a bunch of error situations that should be given a little attention. What happens when there's no longer enough memory to keep accumulating studies? What happens when the object instance referred to by reportSampledStudyOid is the wrong data type? (5) The use of non-volatile storage doesn't seem to have been completely thought through. It doesn't make sense to me, for example, to have the control entries in backing storage, but not the "archival" historical data. Likewise, if a control entry is restored from non-volatile upon reboot, does that cause a new report to be started or does it pick up where it left off on a existing report? (6) Notification throttling. Questions of Power I think the decision to limit the module to local access is reasonable given the intended applicability. I do think, however, there should be a clear explanation of the rationale behind limiting its functionality to the current SNMP context, unlike RFC 1981. I think it would be helpful to at least suggest how it is envisioned that future "statistical" functions alluded to in the text would work with this MIB module - are they expected to be extensions of this module or completely new ones? I honestly have some difficulty seeing what good this module would do; perhaps the WG has discussed concrete use cases, but don't be surpised if a future reviewer raises questions on this point. Randy From nobody Mon Apr 20 03:49:49 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82AD1B2A2D for ; Mon, 20 Apr 2015 03:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.161 X-Spam-Level: X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MgZvPQwfpPrF for ; Mon, 20 Apr 2015 03:49:46 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6704F1B2A2B for ; Mon, 20 Apr 2015 03:49:46 -0700 (PDT) Received: from rufsun5.fkie.fraunhofer.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Yk9Gq-00078f-Op for manet@ietf.org; Mon, 20 Apr 2015 12:49:44 +0200 Received: from mailserv2bcas.fkie.fraunhofer.de ([128.7.96.56] helo=mailserv2.fkie.fraunhofer.de) by mailhost.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Yk9Gq-00039X-LP for manet@ietf.org; Mon, 20 Apr 2015 12:49:44 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 20 Apr 2015 12:49:44 +0200 Message-ID: <5534D9B4.5030408@fkie.fraunhofer.de> Date: Mon, 20 Apr 2015 12:49:24 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> In-Reply-To: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020208070105040908020309" X-Originating-IP: [128.7.5.36] X-Virus-Scanned: yes (ClamAV 0.98.1/20349/Mon Apr 20 09:36:26 2015) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ff5b53f4d81aecd7a6b2d230e03a1f9e Archived-At: Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 10:49:49 -0000 --------------ms020208070105040908020309 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04/17/2015 02:59 PM, Ratliff, Stanley wrote: > Hello Working Group, >=20 > DLEP-09 was posted yesterday, and contains the fixes for issues brought= > up in reviews prior to IETF 92. I just finished reading the DLEP-09 document and I like the improvements since version -07. There are three things I noticed while reading. Section 4.1: - Latency is mandatory... is it okay to say "Latency 0" if you don't know or cannot calculate because of CSMA/CA? If yes we maybe should say that in the text. Section 4.5: - Text malformed: "If [Heartbeat signals]#..." Section 7.9: - didn't we talked about allowing EUI-64 addresses here? I am not sure. Restricting DLEP to 48 bit MAC would mean we cannot use DLEP with EUI-64 tech like 802.15.4 Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de --------------ms020208070105040908020309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNTA0MjAxMDQ5MjhaMCMGCSqGSIb3DQEJBDEWBBRE1JmPucv7fUnBKqUc+FQHKmBIIjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAGcnVQuFWp/3KdjkHCK81EGmy7Ogbzxf9ZthVXP0jMHXq gVJEkqIH25H1c/ccveJ67TXR8jtMaP0KfsSQlD1K53Ywveh3Ns+L6piRKiWEe+4cJWrq3HQh HEs6+gi6/fbjXc0dpjjmnI05CW4GWhVuwCKmYsU3JQBShUed0mkuNP1K/uYrraIqEu1TKh1W N9OxljLo/kzBLp0REYBz9ZFXJUQquWYtiL01tFJSzt6QVGLvmwhIji+Gw6MHE8ewC9TMQZp1 pUro5COAvXEO1RCi7eGEELNIJMS14hwQFasyKaoUK6O8sNS1C3kLkFY4lW1NHoPoZXz8+/PU TtebJDEFlgAAAAAAAA== --------------ms020208070105040908020309-- From nobody Mon Apr 20 03:50:59 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6705F1B2A30 for ; Mon, 20 Apr 2015 03:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 Amo7u33iBS_R for ; Mon, 20 Apr 2015 03:50:52 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 60C3D1B2A36 for ; Mon, 20 Apr 2015 03:50:52 -0700 (PDT) Received: by wizk4 with SMTP id k4so93856736wiz.1 for ; Mon, 20 Apr 2015 03:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=ASLJqFqnEZZcd4ViAqsRmqK4HbGSyAdnjd7x8CyRK4Q=; b=c5RtCvyRtkD+R4AeLpQTzopbeVptOQFDHPt5os60DVVYrTin5baUoqo6Nz2MCmoMzl ITvCJpM7KzC0es02VbEnhFAoY5/rukA0rjvf3n3f/n+gzdGDpp30jz05SihD3udtoM7y CEZKLzXIEATi1xasuphaJJOOaf30PTp3aLxnh9gKFMmwU5ASO7emo2mbCuclSmaBrqrk wHYS0chVa0Adzz5Z6TVeECkbY3eNZzF3fC2kTSS5+XzW07+ptnJjVkPL7MnXs9LZKNcg LgV+1U4XeR1UHKmi0ZddwwwP9vXRPQtSaCAwWty4sZ5CbWFW5YzIDlUdHwZCnhtxwFNG BtMQ== X-Received: by 10.195.12.48 with SMTP id en16mr30053587wjd.21.1429527051070; Mon, 20 Apr 2015 03:50:51 -0700 (PDT) Received: from [10.0.4.178] ([217.158.48.187]) by mx.google.com with ESMTPSA id g14sm23233950wjs.47.2015.04.20.03.50.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 03:50:50 -0700 (PDT) Message-ID: <5534DA09.2020507@gmail.com> Date: Mon, 20 Apr 2015 11:50:49 +0100 From: John Dowdell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: manet@ietf.org References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <14f3242407fb4666b4fb42899d5dda0b@VAUSDITCHM2.idirect.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050104090405080003010509" Archived-At: Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 10:50:55 -0000 This is a multi-part message in MIME format. --------------050104090405080003010509 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Justin/Stan I'd agree with the bigger document/longer WGLC. I can see that we'd need a fair chunk of time when we get to AODVv2 last call; we are improving readability (and hence reviewability, if that's a word, my spell checker thinks not), but I can see that they'd easily need more than 14 days to get their head around it from a standing start. However, DLEP has been around for some five years in various guises. We know there are lots of sleeping reviewers out there, because we meet them all the time; be good to get some views from them. Regards John On 17/04/15 22:24, Ulrich Herberg wrote: > Stan, > > I agree with Justin's request for a longer WGLC, but I don't believe > that this needs to be a standing practice for all future documents. > DLEP is a long document and has changed very recently. Justin is not > an author of the document. > > Best regards > Ulrich > > On Fri, Apr 17, 2015 at 1:40 PM, Ratliff, Stanley > > wrote: > > Hello working group – > > I want to solicit other opinions on this issue. To be honest, > Justin and I are not in agreement. I’m of the opinion that, if we > extend the WGLC period on DLEP to 3-weeks, we should make it > standing practice to extend the WGLC to a 3-week period on **all** > subsequent work done by MANET. > > Opinions? > > > Regards, > Stan > > *From:*manet [mailto:manet-bounces@ietf.org > ] *On Behalf Of *Justin Dean > *Sent:* Friday, April 17, 2015 4:29 PM > *To:* Mobile Ad Hoc Networks mailing list > *Subject:* Re: [manet] DLEP-09 > > I've looked over the document and feel that the changes are minor > enough to continue the last call (due to the previous mix up). > But due to said mix up, and the fact that the document has just > been updated, I feel a 3 week last call is more appropriate at > this point. More feedback from more eyes on the document will > result in a better document. > > DLEP-09 last call to end on May 8th. > > Also a heads up that we are planning virtual interim meetings > using the ietf's webex. The dates of those meetings will be > posted to the list soon. > > Justin Dean > > On Fri, Apr 17, 2015 at 8:59 AM, Ratliff, Stanley > > wrote: > > Hello Working Group, > > DLEP-09 was posted yesterday, and contains the fixes for > issues brought up in reviews prior to IETF 92. > > With DLEP-09, the authors formally request a 2-week Working > Group Last Call (WGLC). If the 2-week WGLC is granted, Last > call comments would be due by May 1, 2015. > > Regards, > Stan > > ------------------------------------------------------------------------ > > *Stan Ratliff *| Architect, Applied Research > > *VT iDirect *| 13861 Sunrise Valley Drive, Suite 300, Herndon, > VA 20171, USA > > T: +1 703 544-8520 | F: +1 222 > 123-4567 > > sratliff@idirect.net __| > www.idirect.net > > *Connect with iDirect: *Twitter.com/iDirect > __| Facebook.com/iDirect > > > ** > > ** > > *Advancing a Connected World* > > > _______________________________________________ > 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 --------------050104090405080003010509 Content-Type: multipart/related; boundary="------------010801050806000707080104" --------------010801050806000707080104 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Justin/Stan

I'd agree with the bigger document/longer WGLC. I can see that we'd need a fair chunk of time when we get to AODVv2 last call; we are improving readability (and hence reviewability, if that's a word, my spell checker thinks not), but I can see that they'd easily need more than 14 days to get their head around it from a standing start.

However, DLEP has been around for some five years in various guises. We know there are lots of sleeping reviewers out there, because we meet them all the time; be good to get some views from them.

Regards
John

On 17/04/15 22:24, Ulrich Herberg wrote:
Stan,

I agree with Justin's request for a longer WGLC, but I don't believe that this needs to be a standing practice for all future documents. DLEP is a long document and has changed very recently. Justin is not an author of the document.

Best regards
Ulrich

On Fri, Apr 17, 2015 at 1:40 PM, Ratliff, Stanley <sratliff@idirect.net> wrote:

Hello working group –

 

I want to solicit other opinions on this issue. To be honest, Justin and I are not in agreement. I’m of the opinion that, if we extend the WGLC period on DLEP to 3-weeks, we should make it standing practice to extend the WGLC to a 3-week period on *all* subsequent work done by MANET.

 

Opinions?


Regards,
Stan

 

 

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Justin Dean
Sent: Friday, April 17, 2015 4:29 PM
To: Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] DLEP-09

 

I've looked over the document and feel that the changes are minor enough to continue the last call (due to the previous mix up).  But due to said mix up, and the fact that the document has just been updated, I feel a 3 week last call is more appropriate at this point.  More feedback from more eyes on the document will result in a better document.

DLEP-09 last call to end on May 8th.

 

Also a heads up that we are planning virtual interim meetings using the ietf's webex.  The dates of those meetings will be posted to the list soon.

Justin Dean

 

On Fri, Apr 17, 2015 at 8:59 AM, Ratliff, Stanley <sratliff@idirect.net> wrote:

Hello Working Group,

 

DLEP-09 was posted yesterday, and contains the fixes for issues brought up in reviews prior to IETF 92.

 

With DLEP-09, the authors formally request a 2-week Working Group Last Call (WGLC). If the 2-week WGLC is granted, Last call comments would be due by May 1, 2015.

 

Regards,
Stan

 

Stan Ratliff  |  Architect, Applied Research

VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 123-4567

sratliff@idirect.net  |  www.idirect.net

Connect with iDirect: Twitter.com/iDirect  |  Facebook.com/iDirect

 

Advancing a Connected World

 

 


_______________________________________________
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

--------------010801050806000707080104 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYH BwcGBwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcI DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAAR CAAaAIMDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8AgpJ+2j8YvgF8cfCug+CfD76X4daa G4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeIP24PijYfEbQNH1G2tte0PS4p 4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/EJfBfytqDeJl0NNNjUMD lhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmvAoYf69zSqN8rafK1 a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4k+FP2vtD0D4e +ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbySKryRMQTG SASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtjLhz9 7zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh 0G98M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C 9LOoSTxa99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl +EWQBrSRmPAwIpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBG f+Wdewfma2Fu/wDgr18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+A HxE8SfFH4ZafrPirwfdeA9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9 R/1B7/8Az+NfoeIEH8PU559aTA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNd AyRiJTGNio/3m+9jtmvl3wB/wWR8f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVV jhQfun61uf8ABOP4s+K/G37dn7Qmja34m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBw BXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfD ss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q/C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhV fzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2khie2kW1vyjxsuCrLtQgg5BANUNf /aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37ygwvyk44pcoH6sfak3Yz3x+NAu VLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeHYPsUszQ2oJKhnPlqX2qW xk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk3rHGDtYbmXAyORzT 5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALMyqB1LEAAkgH4 A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn9595Rhav8A 7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRygfeX w+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP 7Dluls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3 D+WLq4lXVJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E /ma8jFYC0nOlNxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi 9rn7Zfh/XPh54wutJ8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SST zGCgFyAGYgYycADnrwBVe3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8 kWopSavvJ7yfT9NXf56/4KB/sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lN u3ceXjBzx2H7HP7MVv8Ask/s9aH4Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVa K7eZnzZ83+I/2CLrxB/wUK0L46DxZDbwaLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4K RGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7u e9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq 5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6tJNNPAYRIYlKqFRTxGCMgfe5NeZ6r /wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ1MhGB0zX2lRSuB4P+0V+wnpH 7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcqDXGfCL/gnN4h0z45+G/H 3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4Hx/49/4Je65F8WPH fiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4JteHdO/Yd1T4JW+ vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gLSvDHh/8A aI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --------------010801050806000707080104-- --------------050104090405080003010509-- From nobody Mon Apr 20 05:35:06 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F381A1BAF for ; Mon, 20 Apr 2015 05:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jK5XZi091otW for ; Mon, 20 Apr 2015 05:35:00 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBEA01A1BB9 for ; Mon, 20 Apr 2015 05:34: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; Mon, 20 Apr 2015 13:34:35 +0100 From: Rick Taylor To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] DLEP-09 Thread-Index: AQHQe1e9XRRVNyUaJ0Ov4xg4whr8EQ== Date: Mon, 20 Apr 2015 12:34:34 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <5534D9B4.5030408@fkie.fraunhofer.de> 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: Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 12:35:05 -0000 Comments inline...=0A= =0A= On 20/04/15 11:49, Henning Rogge wrote:=0A= > On 04/17/2015 02:59 PM, Ratliff, Stanley wrote:=0A= >> Hello Working Group,=0A= >>=0A= >> DLEP-09 was posted yesterday, and contains the fixes for issues brought= =0A= >> up in reviews prior to IETF 92.=0A= >=0A= > I just finished reading the DLEP-09 document and I like the improvements= =0A= > since version -07.=0A= >=0A= > There are three things I noticed while reading.=0A= =0A= There's at least one other change you missed ;)=0A= =0A= >=0A= > Section 4.1:=0A= > - Latency is mandatory... is it okay to say "Latency 0" if you don't=0A= > know or cannot calculate because of CSMA/CA? If yes we maybe should say= =0A= > that in the text.=0A= =0A= Hmmm... I don't like the idea of latency 0, but I agree that there is a =0A= potential problem with 'currently unmeasurable' latency. Thoughts anyone?= =0A= =0A= >=0A= > Section 4.5:=0A= > - Text malformed: "If [Heartbeat signals]#..."=0A= =0A= Bother! Fixed in my copy now.=0A= =0A= >=0A= > Section 7.9:=0A= > - didn't we talked about allowing EUI-64 addresses here? I am not sure.= =0A= > Restricting DLEP to 48 bit MAC would mean we cannot use DLEP with EUI-64= =0A= > tech like 802.15.4=0A= =0A= There is no real reason that a MAC address MUST have Length 6. Perhaps =0A= there should be some extra text here mentioning EUI-64 addresses are =0A= perfectly valid. The only restriction is that all MAC addresses in a =0A= session should be of the same length.=0A= =0A= Rick=0A= From nobody Mon Apr 20 05:51:54 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2321B1A2130 for ; Mon, 20 Apr 2015 05:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uoTINBJY_1eH for ; Mon, 20 Apr 2015 05:51:49 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 65EE41A6F12 for ; Mon, 20 Apr 2015 05:51:47 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.201 as permitted sender) identity=mailfrom; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,609,1422939600"; d="jpg'145?scan'145,208,217,145";a="6869702" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.201]) by ironport2.idirect.net with ESMTP; 20 Apr 2015 08:51:46 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM1.idirect.net (10.250.250.201) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 20 Apr 2015 08:51:43 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Mon, 20 Apr 2015 08:51:46 -0400 From: "Ratliff, Stanley" To: Mobile Ad Hoc Networks mailing list Thread-Topic: Interim Meetings for MANET Working Group Thread-Index: AdB7Z+NqjE48Gd0AQsODaM12dsaB6Q== Date: Mon, 20 Apr 2015 12:51:45 +0000 Message-ID: <568a7cc4fd454aaeaee5b126b72adc59@VAUSDITCHM2.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/related; boundary="_004_568a7cc4fd454aaeaee5b126b72adc59VAUSDITCHM2idirectnet_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [manet] Interim Meetings for MANET Working Group X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 12:51:53 -0000 --_004_568a7cc4fd454aaeaee5b126b72adc59VAUSDITCHM2idirectnet_ Content-Type: multipart/alternative; boundary="_000_568a7cc4fd454aaeaee5b126b72adc59VAUSDITCHM2idirectnet_" --_000_568a7cc4fd454aaeaee5b126b72adc59VAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello working group participants, As was mentioned in Dallas, we need to schedule a couple of working group i= nterim meetings. Justin and I have agreed on: May 6, 2015 at 11:00AM Eastern time, and June 10, 2015 at 11:00AM Eastern time. Details on a WebEx (or other teleconferencing connection) will be forthcomi= ng. The tentative agenda for both of the interim meetings is: 1. Discuss progress of the AODVv2 author/editor team vis-=E0-vis thei= r posted milestones 2. Discuss potential re-charter items, with a goal of producing a cha= rter that we can reach consensus on *prior* to the meeting in Prague. Again, we'll let everyone know (by posting on the list) the details for the= teleconference. Regards, Stan ________________________________ Stan Ratliff | Architect, Applied Research VT iDirect | 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, US= A T: +1 703 544-8520 | F: +1 222 123-4567 sratliff@idirect.net | www.idirect.net Connect with iDirect: Twitter.com/iDirect | = Facebook.com/iDirect [cid:image001.jpg@01D07B47.3A44B460] Advancing a Connected World --_000_568a7cc4fd454aaeaee5b126b72adc59VAUSDITCHM2idirectnet_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello working group participants,

 

As was mentioned in Dallas, we need to schedule a co= uple of working group interim meetings. Justin and I have agreed on:

 

May 6, 2015 at 11:00AM Eastern time, and =

June 10, 2015 at 11:00AM Eastern time.

 

Details on a WebEx (or other teleconferencing connec= tion) will be forthcoming.

 

The tentative agenda for both of the interim meeting= s is:

1.     &= nbsp; Discuss progress of the AODVv2 author/editor team v= is-=E0-vis their posted milestones

2.     &= nbsp; Discuss potential re-charter items, with a goal of = producing a charter that we can reach consensus on *prior* to the me= eting in Prague.

 

Again, we’ll let everyone know (by posting on = the list) the details for the teleconference.

 

Regards,
Stan

 

Stan Ratliff  |  Architect, Applied Research<= /span>

VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Hernd= on, VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 123-4567

sratliff@i= direct.net  |  www.idirect.net

Connect with iDirect: Twitter.com/iDi= rect  |  Facebook.com/i= Direct

 

<= /p>

Advancing a Connected World

 <= /span>

 

--_000_568a7cc4fd454aaeaee5b126b72adc59VAUSDITCHM2idirectnet_-- --_004_568a7cc4fd454aaeaee5b126b72adc59VAUSDITCHM2idirectnet_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3003; creation-date="Mon, 20 Apr 2015 12:51:44 GMT"; modification-date="Mon, 20 Apr 2015 12:51:44 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --_004_568a7cc4fd454aaeaee5b126b72adc59VAUSDITCHM2idirectnet_-- From nobody Mon Apr 20 05:55:37 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66F71A6FED for ; Mon, 20 Apr 2015 05:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 7Nxg5WLuJdkZ for ; Mon, 20 Apr 2015 05:55:35 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (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 BBF8A1A212D for ; Mon, 20 Apr 2015 05:55:34 -0700 (PDT) Received: by wgyo15 with SMTP id o15so178082131wgy.2 for ; Mon, 20 Apr 2015 05:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=WYktwomWQ+aWAZwwFbqBSVH+BQn7tt7Enwh/tQiA5EE=; b=zEQpk9m6ihc0bG59l7zNrBFfOMec7mlG4N0xePWuGd7yX+/XBicSjO9EGihxHe8Wc3 MdQSL7uPq+xF/S+4C+YI9InSfgx8kIqXiXqlYK+gMPAUSQfhd/t6AFqbKkO2otUXodZv x0A0rGJfZA5Q8NAyCZvZ8q0AK6MqQx3kVlN5/vIys4QKiSgGQQKiFIWwOAyiAhMU6iiW Mb5xwnnI/m9VYBB/7z2jzfYiOIngT1CGcFQ/FP8+9rMk4PdGlBakqNkwp0oOWYgLTirb bS+0glz2nfV2YAysroywqlF0PirzC9LZCt73O41hJ+gF68D5hVMcJT+Dt13dzf7nfBf2 6T5w== X-Received: by 10.194.109.97 with SMTP id hr1mr30015920wjb.10.1429534533463; Mon, 20 Apr 2015 05:55:33 -0700 (PDT) Received: from [10.0.4.178] ([217.158.48.187]) by mx.google.com with ESMTPSA id gj7sm15172233wib.4.2015.04.20.05.55.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 05:55:32 -0700 (PDT) Message-ID: <5534F744.80209@gmail.com> Date: Mon, 20 Apr 2015 13:55:32 +0100 From: John Dowdell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: manet@ietf.org References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <5534D9B4.5030408@fkie.fraunhofer.de> <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 12:55:36 -0000 On 20/04/15 13:34, Rick Taylor wrote: > Comments inline... > > On 20/04/15 11:49, Henning Rogge wrote: >> On 04/17/2015 02:59 PM, Ratliff, Stanley wrote: >>> Hello Working Group, >>> >>> DLEP-09 was posted yesterday, and contains the fixes for issues brought >>> up in reviews prior to IETF 92. >> I just finished reading the DLEP-09 document and I like the improvements >> since version -07. >> >> There are three things I noticed while reading. > There's at least one other change you missed ;) > >> Section 4.1: >> - Latency is mandatory... is it okay to say "Latency 0" if you don't >> know or cannot calculate because of CSMA/CA? If yes we maybe should say >> that in the text. > Hmmm... I don't like the idea of latency 0, but I agree that there is a > potential problem with 'currently unmeasurable' latency. Thoughts anyone? I'd prefer it if the radio can return a rough order magnitude response on latency, just so the link can be characterised against the other local modems that do return latency figures. Similarly with modems that find it hard to discuss bandwidth. However such a response might need an indication that this is a guide figure, but given that functions that feed off DLEP seem (in my personal view) to work better with regularly updated rough estimates rather than precision responses, I don't think this will be necessary. John > >> Section 4.5: >> - Text malformed: "If [Heartbeat signals]#..." > Bother! Fixed in my copy now. > >> Section 7.9: >> - didn't we talked about allowing EUI-64 addresses here? I am not sure. >> Restricting DLEP to 48 bit MAC would mean we cannot use DLEP with EUI-64 >> tech like 802.15.4 > There is no real reason that a MAC address MUST have Length 6. Perhaps > there should be some extra text here mentioning EUI-64 addresses are > perfectly valid. The only restriction is that all MAC addresses in a > session should be of the same length. > > Rick > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Mon Apr 20 05:55:52 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C567B1A914A for ; Mon, 20 Apr 2015 05:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 owx9hth6LXqv for ; Mon, 20 Apr 2015 05:55:49 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 781641A90AD for ; Mon, 20 Apr 2015 05:55:47 -0700 (PDT) Received: by wiax7 with SMTP id x7so82849132wia.0 for ; Mon, 20 Apr 2015 05:55:46 -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-type; bh=lVM8yMv4JfTLEoIwMm/kFRam8Ki6Ej6YfsQYrj4mZyA=; b=DTJYbfxzPwYFnoVetDF1sLXiKz6LZo9HzlPtOgHhECpjZHqYQXlPjaRkecQTD1mGXq uwcilHe/vkodv3qMb5vtCK/bg+IPAaPP0/fxlnZIQ9ax1btZQ+V0Mg4pKavKnZN9+PxQ tNTBxH+fHNjLfzMaPzvWA5cCRa/7L2GeiKdSO9haJ1Tm2mFRo3jYJl25DGNwR0z4lQHf mMKxObZu8fcDjAFu4iuZJXmuLyIUq7+5DXHPH+MGAai398sTYF4gwUE/6CLDAicWIWJh Kzo/ywxxyy2MXXmuq+6UZLTUgh2kfV+ABSQS10496v9RUBof5ZjLH+Pjm4IEJE/47O/q xCzw== X-Received: by 10.194.9.98 with SMTP id y2mr31418367wja.85.1429534546263; Mon, 20 Apr 2015 05:55:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Mon, 20 Apr 2015 05:55:24 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <5534D9B4.5030408@fkie.fraunhofer.de> <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 20 Apr 2015 14:55:24 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 12:55:50 -0000 On Mon, Apr 20, 2015 at 2:34 PM, Rick Taylor wrote: >> Section 7.9: >> - didn't we talked about allowing EUI-64 addresses here? I am not sure. >> Restricting DLEP to 48 bit MAC would mean we cannot use DLEP with EUI-64 >> tech like 802.15.4 > > There is no real reason that a MAC address MUST have Length 6. Perhaps > there should be some extra text here mentioning EUI-64 addresses are > perfectly valid. The only restriction is that all MAC addresses in a > session should be of the same length. Section7.9: > Data Item Type: TBD > Length: 6 Maybe this should be replaced with "length: 6 or 8" ? Henning From nobody Mon Apr 20 06:26:37 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCC11B2B54 for ; Mon, 20 Apr 2015 06:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yzL_YcqT4aQ9 for ; Mon, 20 Apr 2015 06:26:33 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1E05B1B2B52 for ; Mon, 20 Apr 2015 06:26:33 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,609,1422939600"; d="scan'208";a="6870565" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport2.idirect.net with ESMTP; 20 Apr 2015 09:26:30 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 20 Apr 2015 09:26:30 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Mon, 20 Apr 2015 09:26:30 -0400 From: "Ratliff, Stanley" To: John Dowdell , "manet@ietf.org" Thread-Topic: [manet] DLEP-09 Thread-Index: AdB5Dijsuf08P0oXRc6vubghpHd05gCfKcgAAAeOh3A= Date: Mon, 20 Apr 2015 13:26:29 +0000 Message-ID: References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <5534D9B4.5030408@fkie.fraunhofer.de> <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> <5534F744.80209@gmail.com> In-Reply-To: <5534F744.80209@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:26:35 -0000 > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of John Dowdell > Sent: Monday, April 20, 2015 8:56 AM > To: manet@ietf.org > Subject: Re: [manet] DLEP-09 >=20 >=20 >=20 > On 20/04/15 13:34, Rick Taylor wrote: > > Comments inline... > > > > On 20/04/15 11:49, Henning Rogge wrote: > >> On 04/17/2015 02:59 PM, Ratliff, Stanley wrote: > >>> Hello Working Group, > >>> > >>> DLEP-09 was posted yesterday, and contains the fixes for issues > >>> brought up in reviews prior to IETF 92. > >> I just finished reading the DLEP-09 document and I like the > >> improvements since version -07. > >> > >> There are three things I noticed while reading. > > There's at least one other change you missed ;) > > > >> Section 4.1: > >> - Latency is mandatory... is it okay to say "Latency 0" if you don't > >> know or cannot calculate because of CSMA/CA? If yes we maybe should > >> say that in the text. > > Hmmm... I don't like the idea of latency 0, but I agree that there is > > a potential problem with 'currently unmeasurable' latency. Thoughts > anyone? My initial thought is "This is a fight/discussion that we had 2 YEARS ago; = I thought we had actually settled it."=20 > I'd prefer it if the radio can return a rough order magnitude response on > latency, just so the link can be characterised against the other local mo= dems > that do return latency figures. Similarly with modems that find it hard t= o > discuss bandwidth. However such a response might need an indication that > this is a guide figure, but given that functions that feed off DLEP seem = (in my > personal view) to work better with regularly updated rough estimates rath= er > than precision responses, I don't think this will be necessary. So, I read that as "If you can't actually calculate latency, then give us y= our best guess..." ????? ;-) Having gotten the snark out of my system (for now), I'd say the "real" answ= er is:=20 The only way to "fix" this is to make latency optional. If you can't (or wo= n't) calculate latency, then don't send it. Although an implementation coul= d choose a "default latency" that is sent in at the peer-level. This "defau= lt" latency would have to be replicated into all sessions created through t= he radio. If the radio subsequently can't (won't) calculate latency, then t= he provided "default" gets used... and before you ask, "heuristics for choo= sing an appropriate default latency value are left to the implementation". Regards, Stan >=20 > John > > > >> Section 4.5: > >> - Text malformed: "If [Heartbeat signals]#..." > > Bother! Fixed in my copy now. > > > >> Section 7.9: > >> - didn't we talked about allowing EUI-64 addresses here? I am not sure= . > >> Restricting DLEP to 48 bit MAC would mean we cannot use DLEP with > >> EUI-64 tech like 802.15.4 > > There is no real reason that a MAC address MUST have Length 6. > > Perhaps there should be some extra text here mentioning EUI-64 > > addresses are perfectly valid. The only restriction is that all MAC > > addresses in a session should be of the same length. > > > > Rick > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Mon Apr 20 06:31:53 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46C81B2B72; Mon, 20 Apr 2015 06:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xbs1YSm4E29P; Mon, 20 Apr 2015 06:31:48 -0700 (PDT) Received: from upbd19pa13.eemsg.mail.mil (upbd19pa13.eemsg.mail.mil [214.24.27.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB4E1B2B6E; Mon, 20 Apr 2015 06:31:47 -0700 (PDT) Received: from edge-eurd01.mail.mil ([214.24.180.6]) by upbd19pa13.eemsg.mail.mil with ESMTP; 20 Apr 2015 13:31:39 +0000 Received: from UPDCHU27.easf.csd.disa.mil (214.24.180.159) by edge-eurd01.mail.mil (214.24.180.6) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 20 Apr 2015 13:31:46 +0000 Received: from UCOLHPM7.easf.csd.disa.mil (131.64.104.32) by UPDCHU27.easf.csd.disa.mil (214.24.180.159) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 20 Apr 2015 13:31:40 +0000 Received: from UCOLHPKT.easf.csd.disa.mil ([169.254.2.143]) by UCOLHPM7.easf.csd.disa.mil ([131.64.104.32]) with mapi id 14.03.0224.002; Mon, 20 Apr 2015 13:29:07 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Randy Presuhn , "manet@ietf.org" Thread-Topic: comments on draft-ietf-manet-report-mib-04 Thread-Index: AQHQei9Fiv92wK/hwkWBi6jwuYs6iJ1V4VdA Date: Mon, 20 Apr 2015 13:29:07 +0000 Message-ID: References: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> In-Reply-To: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.15] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mib-doctors@ietf.org" , "disman@ietf.org" Subject: Re: [manet] comments on draft-ietf-manet-report-mib-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:31:51 -0000 UmFuZHksDQoNCkkgYXBwcmVjaWF0ZSB5b3VyIGRldGFpbGVkIHJldmlldy4gICBJIGNhbiBzdGFy dCB3b3JraW5nIHRocm91Z2ggbW9kaWZpY2F0aW9ucyB0byB0aGUgbW9kdWxlIGJhc2VkIHVwb24g eW91ciBsaXN0IG9mIGlzc3VlcywgYnV0IEkgYW0gbW9zdCBjb25jZXJuZWQgd2l0aCB5b3VyIHZl cnkgbGFzdCBjb21tZW50L3BhcmFncmFwaC4gICAgSWYgT0sgd2l0aCB5b3UsIEkgd291bGQgZmly c3QgbGlrZSB0byBhZGRyZXNzIHlvdXIgcXVlc3Rpb24gb24gdGhlIHV0aWxpdHkgb2YgdGhlIG1v ZHVsZS4gIElmIHRoYXQgcXVlc3Rpb24gY2Fubm90IGJlIGFuc3dlcmVkIGluIHRoZSBwb3NpdGl2 ZSwgdGhlIHJlc3Qgb2YgbXkgZWZmb3J0cyBvbiBmaXhpbmcgdGhlIG1vZHVsZSB3b3VsZCBiZSBt b290Lg0KDQpJJ2xsIHdyaXRlIHVwIGEganVzdGlmaWNhdGlvbiBmb3IgdGhlIG1vZHVsZSwgdG8g YmUgcGxhY2VkIGluIHRoZSBpbnRyb2R1Y3RvcnkgdGV4dC4gIE9ubHkgd2hlbiBpdCBwYXNzZXMg KG9uIG5vdCkgeW91ciBhcHByb3ZhbCBhbmQgdGhhdCBvZiB0aGUgV0csIHRoZW4gSSdsbCBwcm9j ZWVkIHdpdGggdGhlIHJlc3Qgb2YgdGhlIGNvbW1lbnRzIGFuZCBtb2RpZmljYXRpb25zLiAgRG9l cyB0aGlzIHNlZW0gcmVhc29uYWJsZT8NCg0KVGhhbmtzLCBCb2INCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJhbmR5IFByZXN1aG4gW21haWx0bzpyYW5keV9wcmVz dWhuQG1pbmRzcHJpbmcuY29tXQ0KPiBTZW50OiBTYXR1cmRheSwgQXByaWwgMTgsIDIwMTUgNzoy NyBQTQ0KPiBUbzogbWFuZXRAaWV0Zi5vcmcNCj4gQ2M6IENvbGUsIFJvYmVydCBHIENJViBVU0FS TVkgQ0VSREVDIChVUyk7IGRpc21hbkBpZXRmLm9yZzsgbWliLWRvY3RvcnNAaWV0Zi5vcmcNCj4g U3ViamVjdDogY29tbWVudHMgb24gZHJhZnQtaWV0Zi1tYW5ldC1yZXBvcnQtbWliLTA0DQo+IA0K PiBIaSAtDQo+IA0KPiBJIHdhcyBhc2tlZCB0byB0YWtlIGEgbG9vayBhdCBkcmFmdC1pZXRmLW1h bmV0LXJlcG9ydC1taWItMDQuDQo+IFRoaXMgaXMgKm5vdCogYSBmdWxsIE1JQiBkb2N0b3IgcmV2 aWV3OyBpbiBteSBvcGluaW9uIHNvbWUgZnVuZGFtZW50YWwgaXNzdWVzIG5lZWQgdG8gYmUgcmVz b2x2ZWQgYmVmb3JlIGEgZGV0YWlsZWQgcmV2aWV3IChlaXRoZXINCj4gZnJvbSBhIE1JQiBkb2N0 b3Igb3IgZGlzbWFuIHBlcnNwZWN0aXZlKSB3b3VsZCBiZSB3b3J0aHdoaWxlLg0KPiANCj4gVGhl c2UgYXJlIG1vc3RseSBqdXN0IHRvcC1sZXZlbCBpc3N1ZXMgdGhhdCBhYnNvbHV0ZWx5IG5lZWQg dG8gYmUgcmVzb2x2ZWQuICBJIGZlYXIgdGhhdCBldmVuIHRob3VnaCB0aGUgcXVlc3Rpb25zIGFy ZW4ndCB0ZXJyaWJseQ0KPiBkaWZmaWN1bHQsIHRoZSBmaXhlcyBtYXkgcmVzdWx0IGluIHNpZ25p ZmljYW50IGRvY3VtZW50IGNodXJuLiAgVGhlcmUgYXJlIGFsc28gc29tZSBvZGRzIGFuZCBlbmRz IHRoYXQganVtcGVkIG91dCB0aGF0IHNob3VsZCBiZSBmaXhlZA0KPiBiZWZvcmUgYm90aGVyaW5n IHdpdGggYSBzZXJpb3VzIHJldmlldy4gSSBkaWRuJ3QgZ28gaW50byBhIGxvdCBvZiBkZXRhaWwg YmVjYXVzZSB0aGUgc2hlZXIgbnVtYmVyIG9mIHByb2JsZW1zIHdvdWxkIG1ha2UgYW55IHN1Y2gN Cj4gYXR0ZW1wdCBzZWVtIGxpa2UgYSBEb1MgYXR0YWNrLiAgVGhlIGNhdGVnb3JpZXMgaGVyZSBh cmU6DQo+ICAgKDEpIGRhdGEgdHlwZSBkaWZmaWN1bHRpZXMNCj4gICAoMikgdGltZSBzdGFtcGlu Zw0KPiAgICgzKSBhY2Nlc3MgY29udHJvbA0KPiAgICg0KSBvZGRzIGFuZCBlbmRzDQo+ICAgKDUp IHF1ZXN0aW9ucyBvZiBwb3dlcg0KPiANCj4gRGF0YSBUeXBlIERpZmZpY3VsdGllcw0KPiANCj4g ICBMb2NhdGlvbjogQWJzdHJhY3QgYW5kIGVsc3doZXJlDQo+IA0KPiAgIEV4YW1wbGUgb2YgQ3Vy cmVudCB0ZXh0Og0KPiAgICAgSW4gcGFydGljdWxhciwgaXQgZGVzY3JpYmVzIG9iamVjdHMgZm9y IGNvbmZpZ3VyaW5nIGF1dG9ub21vdXMgcmVwb3J0DQo+ICAgICBnZW5lcmF0aW9uIG9uIGFueSBk ZXZpY2UgdGhhdCBzdXBwb3J0cyBNSUJzIGNvbnRhaW5pbmcgb2JqZWN0cyB0aGF0DQo+ICAgICBy ZXNvbHZlIHRvIHR5cGUgSW50ZWdlcjMyIChpLmUuLCBJbnRlZ2VyMzIsIENvdW50ZXIsIEdhdWdl LCBvcg0KPiAgICAgVGltZVRpY2tzKS4gdG8gYmUgdXNlZCBmb3IgcGVyZm9ybWFuY2UgbW9uaXRv cmluZy4NCj4gDQo+ICAgUHJvYmxlbXM6DQo+IAktIHR5cG9ncmFwaGljYWwgbml0OiBtaXNwbGFj ZWQgIi4iIGFmdGVyICIpIg0KPiAgICAgICAgIC0gdGVjaG5pY2FsOiAiQ291bnRlciIgaXMgbm90 IGFuIFNNSXYyIHR5cGUuICBJIGFzc3VtZQ0KPiAgICAgICAgICAgICAgICAgICAgICAiQ291bnRl cjMyIiBpcyBpbnRlbmRlZC4gIElmIGluY2x1c2lvbiBvZg0KPiAgICAgICAgICAgICAgICAgICAg ICBDb3VudGVyNjQgaXMgYWxzbyBpbnRlbmRlZCwgdGhlcmUgYXJlIG90aGVyIHByb2JsZW1zLg0K PiAgICAgICAgIC0gdGVjaG5pY2FsOiAiR2F1Z2UiIGlzIG5vdCBhbiBTTUl2MiB0eXBlLiAgSSBh c3N1bWUNCj4gICAgICAgICAgICAgICAgICAgICAgIkdhdWdlMzIiIGlzIGludGVuZGVkLg0KPiAJ LSB0ZWNobmljYWw6ICB0aGUgcmFuZ2Ugb2YgdHlwZSBJbnRlZ2VyMzIgKGRlZmluZWQgaW4gUkZD IDI1NzgpDQo+ICAgICAgICAgICAgICAgICAgICAgICBkb2VzIG5vdCBjb3ZlciB0aGUgZW50aXJl IHJhbmdlcyBvZiB0eXBlIENvdW50ZXIzMiwNCj4gICAgICAgICAgICAgICAgICAgICAgIEdhdWdl MzIsIG9yIFRpbWVUaWNrcywgYXMgZGVmaW5lZCBpbiBSRkMgMzQxNi4NCj4gICAgICAgICAgICAg ICAgICAgICAgIFRoZSBTTUkgdHlwZSAqVW5zaWduZWQzMiogZG9lcyBjb3ZlciB0aGUgc2FtZSBy YW5nZXMuDQo+IAktIHRlY2huaWNhbDogdGhlIHVzZSBvZiAicmVzb2x2ZSIgaXMgcXVlc3Rpb25h YmxlLCBzaW5jZSBhbGwNCj4gICAgICAgICAgICAgICAgICAgICAgb2YgdGhlIGRhdGEgdHlwZXMg bWVudGlvbmVkIGhhdmUgZGlzdGluY3QgQVNOLjENCj4gICAgICAgICAgICAgICAgICAgICAgdGFn cy4gIChSRkMgMzQxNiBzZWN0aW9uIDMpDQo+IA0KPiAgIEl0IGdldHMgd29yc2UuICBUaGUgZGVm aW5pdGlvbnMgZm9yIHJlcG9ydFNhbXBsZWRDdXJyZW50TWVhc3VyZW1lbnRWYWx1ZQ0KPiAgIGFu ZCByZXBvcnRTYW1wbGVkSGlzdG9yaWNhbFJlcG9ydHNWYWx1ZSBsaW1pdCB0aGVpciByYW5nZXMg dG8NCj4gICAxIHRvIDIsMTQ3LDQ4Myw2NDcuICBUaGlzIG1lYW5zIHRoYXQgc2FtcGxlcyBvZiBD b3VudGVyMzIsIEdhdWdlMzIsDQo+ICAgYW5kIFRpbWVUaWNrcyB3aXRoIHZhbHVlcyBvZiAwIG9y IGFueXRoaW5nIGluIHRoZSByYW5nZSBmcm9tDQo+ICAgMiwxNDcsNDgzLDY0NyB0byA0LDI5NCw5 NjcsMjk1IGNhbm5vdCBiZSByZXByZXNlbnRlZC4NCj4gDQo+ICAgVGhlIHJlcG9ydFNhbXBsZWRD dXJyZW50TWVhc3VyZW1lbnRTdGF0dXMgYW5kIHRoZQ0KPiAgIHJlcG9ydFNhbXBsZWRIaXN0b3Jp Y2FsTWVhc3VyZW1lbnRTdGF0dXMgT0JKRUNULVRZUEVzIGFwcGVhcg0KPiAgIHRvIGJlIGFuIGF0 dGVtcHQgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0sIGFuZCB3b3VsZCAqYWxtb3N0Kg0KPiAgIHdv cmsgaWYgdGhlIE1lYXN1cmVtZW50VmFsdWUgd2VyZSBvZiB0eXBlIFVuc2lnbmVkMzIsIGFuZA0K PiAgIGlmIGl0cyByYW5nZSB3ZXJlIG5vdCBjb25zdHJhaW5lZC4gIEhvd2V2ZXIsIGlmIHRoZSBt b2R1bGUNCj4gICBmdW5jdGlvbmVkIGFzIHRob3VnaCBzYW1wbGVkIGRhdGEsIHJlZ2FyZGxlc3Mg b2YgdHlwZSwgd2VyZQ0KPiAgICJjYXN0IiB0byBVbnNpZ25lZDMyLCB0aGVuIHRoZSB2YWx1ZVBv c2l0aXZlKDIpIGFuZCB2YWx1ZU5lZ2F0aXZlKDMpDQo+ICAgYXJlbid0IHJlYWxseSBuZWVkZWQs IHNpbmNlIHRoZSBzaWduZWRuZXNzIG9mIHRoZSBzYW1wbGVkIHZhbHVlcw0KPiAgIGNhbiBiZSBy ZWNvdmVyZWQgZnJvbSByZXBvcnRTYW1wbGVkU3R1ZHlPaWQuDQo+IA0KPiANCj4gVGltZSBTdGFt cGluZw0KPiAgIFRoZXJlIGFyZSBhIGJ1bmNoIG9mIGNvbmNlcm5zIHJlbGF0ZWQgdG8gdGltZSBz dGFtcGluZy4NCj4gDQo+ICAgLSBzZXZlcmFsIE9CSkVDVC1UWVBFIGRlZmluaXRpb25zIGhhdmUg aW1wb3NzaWJsZSBzeW50YXhlcy4NCj4gICAgICJzeXNVcHRpbWUiIGlzIG5vdCBhIHN5bnRheC4g IEl0IHNob3VsZCBub3QgYmUgSU1QT1JUZWQuDQo+ICAgICBGb3IgcmVwb3J0U2FtcGxlZEN1cnJl bnRNZWFzdXJlbWVudFRpbWUgYW5kIGZvcg0KPiAgICAgcmVwb3J0U2FtcGxlZEhpc3RvcmljYWxN ZWFzdXJlbWVudFRpbWUgeW91IGludGVuZCB0bw0KPiAgICAgdXNlIGEgc3ludGF4IG9mICJUaW1l U3RhbXAiDQo+IA0KPiAgIC0gSE9XRVZFUiwgdGhlcmUgaXMgYSBoZWFsdGggd2FybmluZyBhdHRh Y2hlZCB0byB0aGUNCj4gICAgIFRpbWVTdGFtcCB0ZXh0dWFsIGNvbnZlbnRpb24gaW4gUkZDIDI1 NzksIGFuZCBpdCBhcHBsaWVzDQo+ICAgICBoZXJlLiAgRmlyc3RseSwgaXQgYXBwbGllcyBiZWNh dXNlIHRoZSBzZXQgb2YgdmFsdWVzDQo+ICAgICBwZXJtaXR0ZWQgZm9yIHJlcG9ydFNhbXBsZWRT dHVkeVNhbXBsaW5nSW50ZXJ2YWwgbWVhbnMNCj4gICAgIGl0IGlzIHBvc3NpYmxlIHRvIGNvbnN0 cnVjdCBhIHNpbmdsZSByZXBvcnQgaW4gd2hpY2gNCj4gICAgIHRoZSBzYW1wbGUgdGltZXMgYXJl IGFtYmlndW91cy4gIE1vcmUgc2lnbmlmaWNhbnRseSwNCj4gICAgIGZvciBoaXN0b3JpY2FsIHJl cG9ydHMsIGVzcGVjaWFsbHkgZm9yICJhcmNoaXZhbCIgcHVycG9zZXMsDQo+ICAgICB0aGUgc2Ft cGxlIHRpbWVzIGFyZSBhbG1vc3QgY2VydGFpbmx5IGFtYmlndW91cy4gIENvbnNlcXVlbnRseSwN Cj4gICAgIEkgdGhpbmsgdGhlcmUgbmVlZHMgdG8gYmUgYSByZS10aGluayBvZiB3aGV0aGVyIHRo aXMgaXMNCj4gICAgIHRoZSBjb3JyZWN0IGRhdGEgdHlwZSBmb3IgdGhlIGludGVuZGVkIHVzZS4N Cj4gDQo+ICAgLSBNYW55IGNvdW50ZXIgb2JqZWN0cyBoYXZlICJkaXNjb250aW51aXR5IGluZGlj YXRvcnMiIG90aGVyDQo+ICAgICB0aGFuIHN5c1VwVGltZS4gVGhpcyBtb2R1bGUgZG9lcyBub3Qg cHJvdmlkZSBhIHN0cmFpZ2h0Zm9yd2FyZA0KPiAgICAgd2F5IHRvIGNvcGUgd2l0aCB0aGVzZS4g IFNlZSBSRkMgMjk4MSAoc2VhcmNoIGZvciAiZGlzY29udGludWl0eSIpDQo+ICAgICB0byBzZWUg b25lIGFwcHJvYWNoLg0KPiANCj4gICAtIHJlcG9ydFNhbXBsZWRTdHVkeVNhbXBsaW5nSW50ZXJ2 YWwgbWF5IGJlIG1vZGlmaWVkIGR1cmluZyBhDQo+ICAgICByZXBvcnQuICBUaGlzIG1lYW5zIHRo YXQgY29udmVudGlvbmFsIGFsZ29yaXRobXMgZm9yIGRldGVjdGluZw0KPiAgICAgc3lzVXBUaW1l IGRpc2NvbnRpbnVpdGllcyB3aXRoaW4gYSByZXBvcnQgbWF5IG5vdCB3b3JrLg0KPiANCj4gQWNj ZXNzIENvbnRyb2wNCj4gICBUaGVyZSBhcmUgYSBjb3VwbGUgb2Ygd2F5cyBpbiB3aGljaCBhY2Nl c3MgY29udHJvbCBjb25zaWRlcmF0aW9ucw0KPiAgIG1pZ2h0IGFmZmVjdCB0aGUgZGVzaWduIG9m IHRoaXMgbW9kdWxlLiAgVGhlIHByZXNlbmNlIG9mDQo+ICAgcmVwb3J0U2FtcGxlZFN0dWR5T3du ZXIgc3VnZ2VzdHMgdGhhdCBzb21lb25lIHdhcyB0aGlua2luZyBhYm91dA0KPiAgIHRoaXMsIGJ1 dCBzb21lIGNoYW5nZXMgYXJlIG5lZWRlZCB0byBtYWtlIHRoaW5ncyB3b3JrLg0KPiANCj4gICAg ICgxKSByZXBvcnRTYW1wbGVkQ29udHJvbEVudHJ5IHNob3VsZCBoYXZlIGFuIElOREVYIG9mDQo+ ICAgICAgICAgeyByZXBvcnRTYW1wbGVkU3R1ZHlPd25lciwgcmVwb3J0U2FtcGxlZFN0dWR5SW5k ZXggfQ0KPiAgICAgICAgIFRoaXMgaXMgbmVjZXNzYXJ5IGlmIHlvdSB3YW50IHRvIGJlIGFibGUg dG8gbGltaXQgYWNjZXNzDQo+ICAgICAgICAgdG8gc3BlY2lmaWMgc3R1ZGllcyB0byBzcGVjaWZp YyB1c2VycyBpbiBhIHJlYXNvbmFibGUgd2F5LA0KPiAgICAgICAgIGFuZCB0byBwcmV2ZW50IGNv bGxpc2lvbnMgYmV0d2VlbiB1c2VycyBkdXJpbmcgdGhlIGNyZWF0aW9uDQo+ICAgICAgICAgb2Yg c3R1ZGllcy4NCj4gDQo+ICAgICAoMikgTGlrZXdpc2UsIHJlcG9ydFNhbXBsZWRDdXJyZW50UmVw b3J0c1N0YXR1c0VudHJ5IHNob3VsZA0KPiAgICAgICAgIGFsc28gaGF2ZSBhbiBJTkRFWCBvZg0K PiAgICAgICAgIHsgcmVwb3J0U2FtcGxlZFN0dWR5T3duZXIsIHJlcG9ydFNhbXBsZWRTdHVkeUlu ZGV4IH0sDQo+ICAgICAgICAgcmVwb3J0U2FtcGxlZEN1cnJlbnRSZXBvcnRzRW50cnkgc2hvdWxk IGhhdmUNCj4gICAgICAgICB7IHJlcG9ydFNhbXBsZWRTdHVkeUluZGV4LCByZXBvcnRTYW1wbGVk Q3VycmVudE1lYXN1cmVtZW50SW5kZXggfQ0KPiAgICAgICAgIHJlcG9ydFNhbXBsZWRIaXN0b3Jp Y2FsUmVwb3J0c0VudHJ5IHNob3VsZCBoYXZlDQo+ICAgICAgICAgeyByZXBvcnRTYW1wbGVkU3R1 ZHlPd25lciwgcmVwb3J0U2FtcGxlZFN0dWR5SW5kZXgsDQo+ICAgICAgICAgICByZXBvcnRTYW1w bGVkSGlzdG9yaWNhbFJlcG9ydEluZGV4LA0KPiAgICAgICAgICAgcmVwb3J0U2FtcGxlZEhpc3Rv cmljYWxNZWFzdXJlbWVudEluZGV4IH0NCj4gDQo+ICAgICAoMykgQSBjb25zZXF1ZW5jZSBpcyB0 aGF0IChmb3IgZXhhbXBsZSkgcmVwb3J0U2FtcGxlZFN0dWR5SW5kZXgNCj4gICAgICAgICBvbmx5 IG5lZWRzIHRvIGJlIHVuaXF1ZSBmb3IgYSBnaXZlbiBvd25lciwgYW5kIG5vdCBhbW9uZw0KPiAg ICAgICAgIGFsbCBzdHVkaWVzLg0KPiANCj4gICBOb3RlIHRoYXQgcmVwb3J0U2FtcGxlZERhdGFD b2xsZWN0aW9uRmFpbHVyZSBzdWZmZXJzIGZyb20gdGhlDQo+ICAgIndobydzIGJ1cmllZCBpbiBH cmFudCdzIFRvbWIiIHByb2JsZW0sIGFuZCBjYW4gYmUgc2ltcGxpZmllZC4NCj4gDQo+ICAgQSBz ZWNvbmQgd2F5IGluIHdoaWNoIGFjY2VzcyBjb250cm9sIG1hdHRlcnMgaGVyZSBpcyB0aGF0IHRo ZQ0KPiAgIHNhbXBsaW5nIHByb2Nlc3Mgc2hvdWxkIG5vdCBjaXJjdW12ZW50IGFjY2VzcyBjb250 cm9sLiAgSSBzdHJvbmdseQ0KPiAgIHVyZ2UgcHV0dGluZyBpbiBleHBsaWNpdCBsYW5ndWFnZSBh Ym91dCB0aGlzLiAgSSdkIHN1Z2dlc3QgdGhlIGZvbGxvd2luZw0KPiAgIGFzIGEgc3RhcnRpbmcg cG9pbnQgZm9yIGRpc2N1c3Npb246DQo+IA0KPiAgICAgIFNlY3VyaXR5IGZvciBsb2NhbCBhY2Nl c3MgZWZmZWN0aXZlbHkgcmVxdWlyZXMgcmVjb3JkaW5nIGFwcHJvcHJpYXRlDQo+ICAgICAgc2Vj dXJpdHkgY3JlZGVudGlhbHMgb2YgdGhlIGNyZWF0b3Igb2YgYSByZXBvcnRTYW1wbGVkQ29udHJv bEVudHJ5DQo+ICAgICAgYW5kIHVzaW5nIHRob3NlIHRvIGFjY2VzcyB0aGUgbG9jYWwgb2JqZWN0 cy4gIFRoZXNlIHNlY3VyaXR5DQo+ICAgICAgY3JlZGVudGlhbHMgYXJlIHBhcmFtZXRlcnMgbmVj ZXNzYXJ5IGFzIGlucHV0cyB0byBpc0FjY2Vzc0FsbG93ZWQNCj4gICAgICBmcm9tIHRoZSBBcmNo aXRlY3R1cmUgZm9yIERlc2NyaWJpbmcgU05NUCBNYW5hZ2VtZW50IEZyYW1ld29ya3MuDQo+ICAg ICAgVGhlIHN5c3RlbSBNVVNUIChjb25jZXB0dWFsbHkpIHVzZSBpc0FjY2Vzc0FsbG93ZWQgYXQg dGhlIHRpbWUgb2YNCj4gICAgICBlYWNoIGFjY2VzcyAobm90IGp1c3QgY3JlYXRpb24gb2YgdGhl IHJlcG9ydFNhbXBsZWRDb250cm9sRW50cnkpDQo+ICAgICAgdG8gZW5zdXJlIHRoYXQgaXQgZG9l cyBub3QgcGVybWl0IHVuYXV0aG9yaXplZCBhY2Nlc3MuDQo+IA0KPiAgICAgIFdoZW4gdXNpbmcg VkFDTSwgdGhlIHNlY3VyaXR5IGFkbWluaXN0cmF0b3IgU0hPVUxEIGVuc3VyZSB0aGF0DQo+ICAg ICAgYWNjZXNzIHBlcm1pdHRlZCB0byB0aGUgY29sbGVjdGVkIGRhdGEgYW5kIG5vdGlmaWNhdGlv bnMgKHRoYXQgaXMsDQo+ICAgICAgYWNjZXNzIHRvIHJlcG9ydFNhbXBsZWRDdXJyZW50UmVwb3J0 c1N0YXR1c1RhYmxlLiouPHVzZXI+LA0KPiAgICAgIHJlcG9ydFNhbXBsZWRDdXJyZW50UmVwb3J0 c1RhYmxlLiouPHVzZXI+LCBhbmQNCj4gICAgICByZXBvcnRTYW1wbGVkSGlzdG9yaWNhbFJlcG9y dHNUYWJsZS4qLjx1c2VyPikgaXMNCj4gICAgICBsaW1pdGVkIHRvIHRoZSA8dXNlcj4ncyBhcHBy b3ByaWF0ZSBWQUNNIGdyb3VwLg0KPiANCj4gT2RkcyBhbmQgZW5kczoNCj4gICBJdCdzIHByZXR0 eSBvYnZpb3VzIHRoYXQgdGhpcyBtb2R1bGUgaGFzIG5vdCBzZWVuIGEgTUlCIGNvbXBpbGVyDQo+ ICAgcmVjZW50bHkuICBJbiBhZGRpdGlvbiB0byB0aGUgc3ludGFjdGljIHByb2JsZW0sIHRoZXJl IGFyZSBzb21lDQo+ICAgZ2xhcmluZyBzdHlsaXN0aWMgaXNzdWVzIHRoYXQsIGlmIGZpeGVkIG5v dywgd2lsbCBtYWtlIGFuIGV2ZW50dWFsDQo+ICAgTUlCIGRvY3RvciByZXZpZXcgZ28gYSBsb3Qg c21vb3RoZXIuDQo+IA0KPiAgICAoMSkgVXNlIG9mIGRhdGEgdHlwZXMuICBFdmVyeSBzaW5nbGUg dXNlIG9mIEludGVnZXIzMiBpbiB0aGlzDQo+ICAgICAgICBtb2R1bGUgaXMgYXJndWFibHkgaW5j b3JyZWN0LiAgVW5zaWduZWQzMiB3b3VsZCBiZSBhIGJldHRlcg0KPiAgICAgICAgY2hvaWNlLCBz aW5jZSB0aGVzZSBhcmUgYWxsIHN1Yi10eXBlZCB0byBleGNsdWRlIG5lZ2F0aXZlDQo+ICAgICAg ICB2YWx1ZXMuDQo+IA0KPiAgICgyKSBVc2Ugb2YgZGF0YSB0eXBlcy4gIHJlcG9ydFNhbXBsZWRT dHVkeVNhbXBsaW5nSW50ZXJ2YWwNCj4gICAgICAgc2VlbXMgbGlrZSBpdCBzaG91bGQgbWFrZSB1 c2Ugb2YgUkZDIDI1NzkgVGltZUludGVydmFsLCBwZXJoYXBzDQo+ICAgICAgIGNvbnN0cmFpbmVk IHRvIGJlIGF0IGxlYXN0IDEwLg0KPiANCj4gICAoMykgVXNlIG9mIFVOSVRTLiAgVGhvdWdoIGl0 J3MgYSBsaXR0bGUgdW51c3VhbCAoYnV0IG5vdCB1bmhlYXJkLW9mKQ0KPiAgICAgICB0byB1c2Ug VU5JVFMgd2l0aCBub24tY291bnRlciB0eXBlcywgYSB2YWx1ZSBvZiAiY291bnQiIGluLA0KPiAg ICAgICBmb3IgZXhhbXBsZSwgcmVwb3J0U2FtcGxlZFN0dWR5TWF4aW11bU51bWJlck9mSGlzdG9y aWNhbFJlcG9ydHMsDQo+ICAgICAgIGlzIHJlYWxseSBub3QgaGVscGZ1bC4gIEluIHRoYXQgcGFy dGljdWxhciBjYXNlLCAicmVwb3J0cyINCj4gICAgICAgd291bGQgbWFrZSBtb3JlIHNlbnNlLg0K PiANCj4gICAoNCkgQXR0ZW50aW9uIHRvIGVycm9yIGNhc2VzOiB0aGVyZSBhcmUgYSBidW5jaCBv ZiBlcnJvciBzaXR1YXRpb25zDQo+ICAgICAgIHRoYXQgc2hvdWxkIGJlIGdpdmVuIGEgbGl0dGxl IGF0dGVudGlvbi4gIFdoYXQgaGFwcGVucyB3aGVuDQo+ICAgICAgIHRoZXJlJ3Mgbm8gbG9uZ2Vy IGVub3VnaCBtZW1vcnkgdG8ga2VlcCBhY2N1bXVsYXRpbmcgc3R1ZGllcz8NCj4gICAgICAgV2hh dCBoYXBwZW5zIHdoZW4gdGhlIG9iamVjdCBpbnN0YW5jZSByZWZlcnJlZCB0byBieQ0KPiAgICAg ICByZXBvcnRTYW1wbGVkU3R1ZHlPaWQgaXMgdGhlIHdyb25nIGRhdGEgdHlwZT8NCj4gDQo+ICAg KDUpIFRoZSB1c2Ugb2Ygbm9uLXZvbGF0aWxlIHN0b3JhZ2UgZG9lc24ndCBzZWVtIHRvIGhhdmUg YmVlbg0KPiAgICAgICBjb21wbGV0ZWx5IHRob3VnaHQgdGhyb3VnaC4gIEl0IGRvZXNuJ3QgbWFr ZSBzZW5zZSB0byBtZSwgZm9yDQo+ICAgICAgIGV4YW1wbGUsIHRvIGhhdmUgdGhlIGNvbnRyb2wg ZW50cmllcyBpbiBiYWNraW5nIHN0b3JhZ2UsIGJ1dA0KPiAgICAgICBub3QgdGhlICJhcmNoaXZh bCIgaGlzdG9yaWNhbCBkYXRhLiAgTGlrZXdpc2UsIGlmIGEgY29udHJvbA0KPiAgICAgICBlbnRy eSBpcyByZXN0b3JlZCBmcm9tIG5vbi12b2xhdGlsZSB1cG9uIHJlYm9vdCwgZG9lcyB0aGF0DQo+ ICAgICAgIGNhdXNlIGEgbmV3IHJlcG9ydCB0byBiZSBzdGFydGVkIG9yIGRvZXMgaXQgcGljayB1 cCB3aGVyZQ0KPiAgICAgICBpdCBsZWZ0IG9mZiBvbiBhIGV4aXN0aW5nIHJlcG9ydD8NCj4gDQo+ ICAgKDYpIE5vdGlmaWNhdGlvbiB0aHJvdHRsaW5nLg0KPiANCj4gUXVlc3Rpb25zIG9mIFBvd2Vy DQo+ICAgSSB0aGluayB0aGUgZGVjaXNpb24gdG8gbGltaXQgdGhlIG1vZHVsZSB0byBsb2NhbCBh Y2Nlc3MgaXMgcmVhc29uYWJsZQ0KPiAgIGdpdmVuIHRoZSBpbnRlbmRlZCBhcHBsaWNhYmlsaXR5 LiAgSSBkbyB0aGluaywgaG93ZXZlciwgdGhlcmUgc2hvdWxkDQo+ICAgYmUgYSBjbGVhciBleHBs YW5hdGlvbiBvZiB0aGUgcmF0aW9uYWxlIGJlaGluZCBsaW1pdGluZyBpdHMgZnVuY3Rpb25hbGl0 eQ0KPiAgIHRvIHRoZSBjdXJyZW50IFNOTVAgY29udGV4dCwgdW5saWtlIFJGQyAxOTgxLg0KPiAN Cj4gICBJIHRoaW5rIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gYXQgbGVhc3Qgc3VnZ2VzdCBob3cg aXQgaXMgZW52aXNpb25lZA0KPiAgIHRoYXQgZnV0dXJlICJzdGF0aXN0aWNhbCIgZnVuY3Rpb25z IGFsbHVkZWQgdG8gaW4gdGhlIHRleHQgd291bGQgd29yaw0KPiAgIHdpdGggdGhpcyBNSUIgbW9k dWxlIC0gICBhcmUgdGhleSBleHBlY3RlZCB0byBiZSBleHRlbnNpb25zIG9mIHRoaXMNCj4gICBt b2R1bGUgb3IgY29tcGxldGVseSBuZXcgb25lcz8NCj4gDQo+ICAgSSBob25lc3RseSBoYXZlIHNv bWUgZGlmZmljdWx0eSBzZWVpbmcgd2hhdCBnb29kIHRoaXMgbW9kdWxlIHdvdWxkDQo+ICAgZG87 IHBlcmhhcHMgdGhlIFdHIGhhcyBkaXNjdXNzZWQgY29uY3JldGUgdXNlIGNhc2VzLCBidXQgZG9u J3QgYmUNCj4gICBzdXJwaXNlZCBpZiBhIGZ1dHVyZSByZXZpZXdlciByYWlzZXMgcXVlc3Rpb25z IG9uIHRoaXMgcG9pbnQuDQo+IA0KPiBSYW5keQ0KDQo= From nobody Mon Apr 20 06:35:26 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0ED1A8731 for ; Mon, 20 Apr 2015 06:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 qCspqKmmNp0a for ; Mon, 20 Apr 2015 06:35:23 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (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 1BA891A8727 for ; Mon, 20 Apr 2015 06:35:23 -0700 (PDT) Received: by wgin8 with SMTP id n8so179027405wgi.0 for ; Mon, 20 Apr 2015 06:35:21 -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-type:content-transfer-encoding; bh=43swghu6BxIxwh74f1KauRkCtiOdJt6xP1Xkf5NsVsQ=; b=m5w/jsvvNfzVKe0oUtp8mX6yuVGXYUhyLQnMJWXeFUr7ZYnBZ9xjGuroLz8s3TFAk/ sA0Nq9I4Gbp+23+kqLcHE3oZhsqwe+mmc9u8nb+FhQ7L3jG5ZRw2xtw7ase+6mtxhz9J xsoPcWh2zVwMrN58vhlqG0Zfs87jrcDxx1bsIcRIfm3rMw9xiSsvc3Zh29umQ7O2oE0p vIRKz7ZzWFbnjk7DJu61lBl+OSduqxLXk7Nc0IIf/BPfNMKoOPLAElKZDMNoCOKjoGvB SdNyKzSjQ14mRitfeM10FPqBrvUpCoIYiEmczZ6FWJpsMcotxJVN6VGPoyme1J659ZAn 3QCg== X-Received: by 10.180.223.7 with SMTP id qq7mr24698242wic.21.1429536921580; Mon, 20 Apr 2015 06:35:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Mon, 20 Apr 2015 06:35:01 -0700 (PDT) In-Reply-To: References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <5534D9B4.5030408@fkie.fraunhofer.de> <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> <5534F744.80209@gmail.com> From: Henning Rogge Date: Mon, 20 Apr 2015 15:35:01 +0200 Message-ID: To: "Ratliff, Stanley" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:35:24 -0000 On Mon, Apr 20, 2015 at 3:26 PM, Ratliff, Stanley wr= ote: >> >> Section 4.1: >> >> - Latency is mandatory... is it okay to say "Latency 0" if you don't >> >> know or cannot calculate because of CSMA/CA? If yes we maybe should >> >> say that in the text. >> > Hmmm... I don't like the idea of latency 0, but I agree that there is >> > a potential problem with 'currently unmeasurable' latency. Thoughts >> anyone? > > My initial thought is "This is a fight/discussion that we had 2 YEARS ago= ; I thought we had actually settled it." I thought the same... >> I'd prefer it if the radio can return a rough order magnitude response o= n >> latency, just so the link can be characterised against the other local m= odems >> that do return latency figures. Similarly with modems that find it hard = to >> discuss bandwidth. However such a response might need an indication that >> this is a guide figure, but given that functions that feed off DLEP seem= (in my >> personal view) to work better with regularly updated rough estimates rat= her >> than precision responses, I don't think this will be necessary. > > So, I read that as "If you can't actually calculate latency, then give us= your best guess..." ????? ;-) > > Having gotten the snark out of my system (for now), Sorry for this... most likely it got drowned out by more important DLEP discussions. > I'd say the "real" answer is: > The only way to "fix" this is to make latency optional. If you can't (or = won't) calculate latency, then don't send it. Although an implementation co= uld choose a "default latency" that is sent in at the peer-level. This "def= ault" latency would have to be replicated into all sessions created through= the radio. If the radio subsequently can't (won't) calculate latency, then= the provided "default" gets used... and before you ask, "heuristics for ch= oosing an appropriate default latency value are left to the implementation"= . I would be okay with both... either we say "give it a best guess if you cannot measure/calculate/know it" or we make it optional. Henning From nobody Mon Apr 20 07:43:25 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDF81B2BDD for ; Mon, 20 Apr 2015 07:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 piH120YhfGqk for ; Mon, 20 Apr 2015 07:43:22 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADAA1B2E33 for ; Mon, 20 Apr 2015 07:43:21 -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; Mon, 20 Apr 2015 15:42:55 +0100 From: Rick Taylor To: Henning Rogge , "Ratliff, Stanley" Thread-Topic: [manet] DLEP-09 Thread-Index: AQHQe1e9XRRVNyUaJ0Ov4xg4whr8EQ== Date: Mon, 20 Apr 2015 14:42:53 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016753465D@tss-server1.home.tropicalstormsoftware.com> References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <5534D9B4.5030408@fkie.fraunhofer.de> <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> <5534F744.80209@gmail.com> 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: "manet@ietf.org" Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 14:43:24 -0000 On 20/04/15 14:35, Henning Rogge wrote:=0A= > On Mon, Apr 20, 2015 at 3:26 PM, Ratliff, Stanley = wrote:=0A= >>>>> Section 4.1:=0A= >>>>> - Latency is mandatory... is it okay to say "Latency 0" if you don't= =0A= >>>>> know or cannot calculate because of CSMA/CA? If yes we maybe should= =0A= >>>>> say that in the text.=0A= >>>> Hmmm... I don't like the idea of latency 0, but I agree that there is= =0A= >>>> a potential problem with 'currently unmeasurable' latency. Thoughts= =0A= >>> anyone?=0A= >>=0A= >> My initial thought is "This is a fight/discussion that we had 2 YEARS ag= o; I thought we had actually settled it."=0A= >=0A= > I thought the same...=0A= >=0A= >>> I'd prefer it if the radio can return a rough order magnitude response = on=0A= >>> latency, just so the link can be characterised against the other local = modems=0A= >>> that do return latency figures. Similarly with modems that find it hard= to=0A= >>> discuss bandwidth. However such a response might need an indication tha= t=0A= >>> this is a guide figure, but given that functions that feed off DLEP see= m (in my=0A= >>> personal view) to work better with regularly updated rough estimates ra= ther=0A= >>> than precision responses, I don't think this will be necessary.=0A= >>=0A= >> So, I read that as "If you can't actually calculate latency, then give u= s your best guess..." ????? ;-)=0A= >>=0A= >> Having gotten the snark out of my system (for now),=0A= > Sorry for this... most likely it got drowned out by more important=0A= > DLEP discussions.=0A= >=0A= >> I'd say the "real" answer is:=0A= >> The only way to "fix" this is to make latency optional. If you can't (or= won't) calculate latency, then don't send it. Although an implementation c= ould choose a "default latency" that is sent in at the peer-level. This "de= fault" latency would have to be replicated into all sessions created throug= h the radio. If the radio subsequently can't (won't) calculate latency, the= n the provided "default" gets used... and before you ask, "heuristics for c= hoosing an appropriate default latency value are left to the implementation= ".=0A= >=0A= > I would be okay with both... either we say "give it a best guess if=0A= > you cannot measure/calculate/know it" or we make it optional.=0A= >=0A= =0A= Having produced blood, sweat and tears to remove the =0A= 'mandatory/optional' mess we got into with previous drafts, I would be =0A= really keen to keep Latency as mandatory, and if it can't be calculated =0A= by the implementation then it must be set with a value from a 'best =0A= guestimate' or an implementation configured option, and (probably) =0A= announced at the peer level.=0A= =0A= Rick=0A= =0A= From nobody Mon Apr 20 07:48:22 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CFA1B2E5C for ; Mon, 20 Apr 2015 07:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 FcMA1x-LByEf for ; Mon, 20 Apr 2015 07:48:20 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (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 0D18A1B2E5B for ; Mon, 20 Apr 2015 07:48:20 -0700 (PDT) Received: by qcrf4 with SMTP id f4so59276473qcr.0 for ; Mon, 20 Apr 2015 07:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zgazmcwc8uwLoGmSdq3Nv8UsLOoB/S5xiUhSaGlqgIs=; b=ltnIBFZDwqT7peLBM7I3ZTHMgo24e9J1lg/7CqHVGOZjbivsXU4gBTQqVlNG6HxTb8 wMiwijultYnayVwrhgvEKyxCx23kT3sG9BAwJfRnU9yaOk7d7/BgK7C7Ik/oIl8vetsB mKSptmYyNYeFQe3vGV0BapeubPhEqzqHCMx0ZQtXenYRmlXhHcvvALDN4r6VqpxjFPex 84+tvnC888aOqUH1lZl008Ulo9nVpzqPLXF4uYgU2E5QoWbUaSLTxgfceT2+S3j1lpHB Q6BpApdVp6jqwKtlJwl8sHJqLeTjkiuakp4ouhegibNjH9p1wKe78TxsbmBK91F+SHv8 pDkA== MIME-Version: 1.0 X-Received: by 10.229.130.71 with SMTP id r7mr10697359qcs.13.1429541299298; Mon, 20 Apr 2015 07:48:19 -0700 (PDT) Received: by 10.140.84.105 with HTTP; Mon, 20 Apr 2015 07:48:18 -0700 (PDT) In-Reply-To: References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> Date: Mon, 20 Apr 2015 16:48:18 +0200 Message-ID: From: Abdussalam Baryun To: Justin Dean Content-Type: multipart/alternative; boundary=001a1132e2f856289605142905a9 Archived-At: Cc: Mobile Ad Hoc Networks mailing list Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 14:48:21 -0000 --001a1132e2f856289605142905a9 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 17, 2015 at 10:28 PM, Justin Dean wrote: > I've looked over the document and feel that the changes are minor enough > to continue the last call (due to the previous mix up). > Just quick look in the beginning. The abstract does not look like an abstract of the protocol, it seems like an introduction, I suggest that we look into amending/editing the abstract. AB --001a1132e2f856289605142905a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 17, 2015 at 10:28 PM, Justin Dean <bebemaster@gmail.com= > wrote:
= I've looked over the document and feel that the changes are minor enoug= h to continue the last call (due to the previous mix up).=C2=A0
<= /div>

Just quick look in the be= ginning. The abstract=C2=A0does not look like an abstract of the protocol, = it seems like an introduction,=C2=A0I suggest that we look into amending/ed= iting the abstract.

AB=C2=A0

=
--001a1132e2f856289605142905a9-- From nobody Mon Apr 20 07:53:32 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8791B2C05 for ; Mon, 20 Apr 2015 07:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 7lPKe_Hi3uBP for ; Mon, 20 Apr 2015 07:53:30 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 5503F1B2C02 for ; Mon, 20 Apr 2015 07:53:30 -0700 (PDT) Received: by qku63 with SMTP id 63so191824316qku.3 for ; Mon, 20 Apr 2015 07:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4XBJlnH+gJyZTUVUvbfKYRavNlblYWr/KNQRTHANsFw=; b=EIZ3JqvCPFfQ0Xr4UHTaFLiNBB2NYpcJh+xSTenqKK4XN+y8v4+ZGQXJkM5XxUUB9H auhL/0OhjynOP42zj5YwRbD3s6BpUA3kyPR/gGOsnW11fdsm0s1HCIT+agwfrpeHik9W hXISqnq/wlx6IbJvzZ7xRjH7zRxxW00VQLcew4/q8V6E9KcxVdogw0g9udQmAoWarUKd G7YNkjyq58ZYrkWIiJ5XSfeVhDaLLOaaZjcr+MClW/LgBUDo2cU54mI33KvgUv1iJbXl Skh+mYqQyGoUUbx2UxdxvBX9HQAN5jGc9guLnm6l7IqpflIeNXglnfINLHbtbzg7agRc oOCg== MIME-Version: 1.0 X-Received: by 10.55.31.218 with SMTP id n87mr28112049qkh.99.1429541609469; Mon, 20 Apr 2015 07:53:29 -0700 (PDT) Received: by 10.140.84.105 with HTTP; Mon, 20 Apr 2015 07:53:29 -0700 (PDT) In-Reply-To: References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <5534D9B4.5030408@fkie.fraunhofer.de> <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> <5534F744.80209@gmail.com> Date: Mon, 20 Apr 2015 16:53:29 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=001a1147e85ed2fcec051429171e Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 14:53:31 -0000 --001a1147e85ed2fcec051429171e Content-Type: text/plain; charset=UTF-8 On Mon, Apr 20, 2015 at 3:35 PM, Henning Rogge wrote: > On Mon, Apr 20, 2015 at 3:26 PM, Ratliff, Stanley > wrote: > > I'd say the "real" answer is: > > The only way to "fix" this is to make latency optional. If you can't (or > won't) calculate latency, then don't send it. Although an implementation > could choose a "default latency" that is sent in at the peer-level. This > "default" latency would have to be replicated into all sessions created > through the radio. If the radio subsequently can't (won't) calculate > latency, then the provided "default" gets used... and before you ask, > "heuristics for choosing an appropriate default latency value are left to > the implementation". > > I would be okay with both... either we say "give it a best guess if > you cannot measure/calculate/know it" or we make it optional. > IMO, if the above is ok then latency to be optional is the best decision for the protocol. AB --001a1147e85ed2fcec051429171e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 20, 2015 at 3:35 PM, Henning Rogge <hrogge@gmail.com>= ; wrote:
On Mon, Apr 20, 2015 at 3:26 PM, = Ratliff, Stanley <sratliff@idire= ct.net> wrote:
> I'd say the "real" answer is:
> The only way to "fix" this is to make latency optional. If y= ou can't (or won't) calculate latency, then don't send it. Alth= ough an implementation could choose a "default latency" that is s= ent in at the peer-level. This "default" latency would have to be= replicated into all sessions created through the radio. If the radio subse= quently can't (won't) calculate latency, then the provided "de= fault" gets used... and before you ask, "heuristics for choosing = an appropriate default latency value are left to the implementation".<= br>
I would be okay with both... either we say "give it a best gues= s if
you cannot measure/calculate/know it" or we make it optional.

IMO,=C2=A0if the above is ok then =C2=A0latency= to be optional is the best decision for the protocol.

=
AB

--001a1147e85ed2fcec051429171e-- From nobody Mon Apr 20 08:04:01 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9491B2E45 for ; Mon, 20 Apr 2015 08:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 riOBCP4_WmNU for ; Mon, 20 Apr 2015 08:03:44 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 2CCC31B2E3E for ; Mon, 20 Apr 2015 08:03:43 -0700 (PDT) Received: by qgdy78 with SMTP id y78so53760551qgd.0 for ; Mon, 20 Apr 2015 08:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3UlVzg6ZJ8GH/UXgTg1uezlG44nSXaTjWR/4VITx2Ks=; b=jevU3f+CMLjo/JpByhBrPZIL/+5wnqhx9Hda7naKMuGIOxtGgedGQU+MWrGIFFIV2B Dmh9BHJ6og3+tTgdNSH689MUxuA7qTudc0FfmzS1MdhdEji/6dWospJcDf4m7tyC94f7 aBiVA4uMUgTQy49M+SEy2GJvFHQb5iddLwWjgag+F0nAGyS+QSGQpaCvtJlvd+DMOBnW PChw1rsZmBjEnS5S/oYwrWXc5HvFD6ldFgmYtmgi9Ov9wVL5kzZIZ/pJP/tZ+G4+Gulh ySkv8IMcbeFeVfDuX82C3whVuH2NnykcInK1Pfkx59QX1AVUfGAUtABrWMpw5b2F1Fbp epLA== MIME-Version: 1.0 X-Received: by 10.140.135.18 with SMTP id 18mr2395341qhh.71.1429542222466; Mon, 20 Apr 2015 08:03:42 -0700 (PDT) Received: by 10.140.84.105 with HTTP; Mon, 20 Apr 2015 08:03:42 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016753465D@tss-server1.home.tropicalstormsoftware.com> References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <5534D9B4.5030408@fkie.fraunhofer.de> <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> <5534F744.80209@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016753465D@tss-server1.home.tropicalstormsoftware.com> Date: Mon, 20 Apr 2015 17:03:42 +0200 Message-ID: From: Abdussalam Baryun To: Rick Taylor Content-Type: multipart/alternative; boundary=001a1136fe625c92160514293cf4 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 15:03:51 -0000 --001a1136fe625c92160514293cf4 Content-Type: text/plain; charset=UTF-8 I think sometimes using optional items is more flexible than mandatory and gives advantages to the protocol. It should not create any problem in the protocol operations, because the protocol does not use it, but the router can use that information or leave it. Making it mandatory may mean that the protocol will be affected if not have its value but the protocol is not affected. AB On Mon, Apr 20, 2015 at 4:42 PM, Rick Taylor wrote: > On 20/04/15 14:35, Henning Rogge wrote: > > On Mon, Apr 20, 2015 at 3:26 PM, Ratliff, Stanley > wrote: > >>>>> Section 4.1: > >>>>> - Latency is mandatory... is it okay to say "Latency 0" if you don't > >>>>> know or cannot calculate because of CSMA/CA? If yes we maybe should > >>>>> say that in the text. > >>>> Hmmm... I don't like the idea of latency 0, but I agree that there is > >>>> a potential problem with 'currently unmeasurable' latency. Thoughts > >>> anyone? > >> > >> My initial thought is "This is a fight/discussion that we had 2 YEARS > ago; I thought we had actually settled it." > > > > I thought the same... > > > >>> I'd prefer it if the radio can return a rough order magnitude response > on > >>> latency, just so the link can be characterised against the other local > modems > >>> that do return latency figures. Similarly with modems that find it > hard to > >>> discuss bandwidth. However such a response might need an indication > that > >>> this is a guide figure, but given that functions that feed off DLEP > seem (in my > >>> personal view) to work better with regularly updated rough estimates > rather > >>> than precision responses, I don't think this will be necessary. > >> > >> So, I read that as "If you can't actually calculate latency, then give > us your best guess..." ????? ;-) > >> > >> Having gotten the snark out of my system (for now), > > Sorry for this... most likely it got drowned out by more important > > DLEP discussions. > > > >> I'd say the "real" answer is: > >> The only way to "fix" this is to make latency optional. If you can't > (or won't) calculate latency, then don't send it. Although an > implementation could choose a "default latency" that is sent in at the > peer-level. This "default" latency would have to be replicated into all > sessions created through the radio. If the radio subsequently can't (won't) > calculate latency, then the provided "default" gets used... and before you > ask, "heuristics for choosing an appropriate default latency value are left > to the implementation". > > > > I would be okay with both... either we say "give it a best guess if > > you cannot measure/calculate/know it" or we make it optional. > > > > Having produced blood, sweat and tears to remove the > 'mandatory/optional' mess we got into with previous drafts, I would be > really keen to keep Latency as mandatory, and if it can't be calculated > by the implementation then it must be set with a value from a 'best > guestimate' or an implementation configured option, and (probably) > announced at the peer level. > > Rick > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a1136fe625c92160514293cf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think sometimes using optional items is more flexib= le than mandatory and gives advantages to the protocol. It should not creat= e any problem in the protocol operations, because the protocol does not use= it, but=C2=A0the router can use that information or leave it. Making it ma= ndatory may mean that the protocol will be affected if not have its value b= ut the protocol is not affected.

AB

On Mon, Apr 20, 2015 a= t 4:42 PM, Rick Taylor <rick@tropicalstormsoftware.com>= ; wrote:
On 20/04/15 14:35, Henning Rogge wrote:
> On Mon, Apr 20, 2015 at 3:26 PM, Ratliff, Stanley <sratliff@idirect.net> wrote:
>>>>> Section 4.1:
>>>>> - Latency is mandatory... is it okay to say "Late= ncy 0" if you don't
>>>>> know or cannot calculate because of CSMA/CA? If yes we= maybe should
>>>>> say that in the text.
>>>> Hmmm... I don't like the idea of latency 0, but I agre= e that there is
>>>> a potential problem with 'currently unmeasurable' = latency.=C2=A0 Thoughts
>>> anyone?
>>
>> My initial thought is "This is a fight/discussion that we had= 2 YEARS ago; I thought we had actually settled it."
>
> I thought the same...
>
>>> I'd prefer it if the radio can return a rough order magnit= ude response on
>>> latency, just so the link can be characterised against the oth= er local modems
>>> that do return latency figures. Similarly with modems that fin= d it hard to
>>> discuss bandwidth. However such a response might need an indic= ation that
>>> this is a guide figure, but given that functions that feed off= DLEP seem (in my
>>> personal view) to work better with regularly updated rough est= imates rather
>>> than precision responses, I don't think this will be neces= sary.
>>
>> So, I read that as "If you can't actually calculate laten= cy, then give us your best guess..." ?????=C2=A0 ;-)
>>
>> Having gotten the snark out of my system (for now),
> Sorry for this... most likely it got drowned out by more important
> DLEP discussions.
>
>> I'd say the "real" answer is:
>> The only way to "fix" this is to make latency optional. = If you can't (or won't) calculate latency, then don't send it. = Although an implementation could choose a "default latency" that = is sent in at the peer-level. This "default" latency would have t= o be replicated into all sessions created through the radio. If the radio s= ubsequently can't (won't) calculate latency, then the provided &quo= t;default" gets used... and before you ask, "heuristics for choos= ing an appropriate default latency value are left to the implementation&quo= t;.
>
> I would be okay with both... either we say "give it a best guess = if
> you cannot measure/calculate/know it" or we make it optional.
>

Having produced blood, sweat and tears to remove the
'mandatory/optional' mess we got into with previous drafts, I would= be
really keen to keep Latency as mandatory, and if it can't be calculated=
by the implementation then it must be set with a value from a 'best
guestimate' or an implementation configured option, and (probably)
announced at the peer level.

Rick


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

--001a1136fe625c92160514293cf4-- From nobody Mon Apr 20 11:16:12 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9EB1A1A1D; Mon, 20 Apr 2015 11:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 QQtQYzE2-O0R; Mon, 20 Apr 2015 11:16:05 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA371A1A10; Mon, 20 Apr 2015 11:16:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=B2bM0MEq2TkmBxHon1irzRTi4zFC6urKSPZ8e+V+NcF9V5oQAoC1Wp2faqkiXlJe; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.51] (helo=mswamui-thinleaf.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YkGE2-000200-Qo; Mon, 20 Apr 2015 14:15:18 -0400 Received: from 76.254.48.97 by webmail.earthlink.net with HTTP; Mon, 20 Apr 2015 14:14:50 -0400 Message-ID: <15067240.1429553690764.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> Date: Mon, 20 Apr 2015 11:14:50 -0700 (GMT-07:00) From: Randy Presuhn To: "Cole,Robert G CIV USARMY CERDEC (US)" , "manet@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f89115376d7f1db1b680646c17222980ccabf53d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.51 Archived-At: Cc: "mib-doctors@ietf.org" , "disman@ietf.org" Subject: Re: [manet] [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 18:16:08 -0000 Hi - >From: "Cole, Robert G CIV USARMY CERDEC (US)" >Sent: Apr 20, 2015 6:29 AM >To: Randy Presuhn , "manet@ietf.org" >Cc: "mib-doctors@ietf.org" , "disman@ietf.org" >Subject: Re: [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04 ... >If OK with you, I would first like to address your question >on the utility of the module. If that question cannot be answered >in the positive, the rest of my efforts on fixing the module would >be moot. Don't give too much weight to my comments, but I'd hope this sort of question would be worked through by any working group considering the development of any MIB module. I think a single, fully-worked-through example of how this would be used with an implementation of RFC 2981 to do something useful would be sufficient. If the intent is to provide detailed history of samples resulting in a DISMAN-EVENT-MIB trigger, I think you need some additional magic to somehow synchronize the sampling performed by this module and that performed by DISMAN-EVENT-MIB. If it's to provide other context (i.e., the data recorded here is for some object other than the one causing the trigger), the issue of potential timing skew should be made explicit. >I'll write up a justification for the module, to be placed >in the introductory text. There's some already there, but it seems to be the rationale for DISMAN-EVENT-MIB rather than for *this* module. AFAICT, this module isn't really going to reduce polling traffic or permit operation with intermittant connectivity. Rather, it *looks* like its function is to record a sampling history to provide debugging/contextual information for a trigger notification. > Only when it passes (on not) your approval and that of the WG, > then I'll proceed with the rest of the comments and modifications. > Does this seem reasonable? The WG's voice is the one that matters. If the WG is convinced it's useful after working through the details of a use case, I'll be happy. Randy From nobody Mon Apr 20 13:38:25 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB301B3156 for ; Mon, 20 Apr 2015 13:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 muuwj9pxSoBy for ; Mon, 20 Apr 2015 13:38:22 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id D64251B3154 for ; Mon, 20 Apr 2015 13:38:21 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,610,1422939600"; d="ics'?scan'208,217";a="17283086" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport.idirect.net with ESMTP; 20 Apr 2015 16:38:21 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 20 Apr 2015 16:38:20 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Mon, 20 Apr 2015 16:38:20 -0400 From: "Ratliff, Stanley" To: "manet@ietf.org" Thread-Topic: (Forward to others) WebEx meeting invitation: MANET Working Group Interim Thread-Index: AQHQe6kbiZTYv51MN0aMlsGWwvz2zZ1WW5cA Date: Mon, 20 Apr 2015 20:38:19 +0000 Message-ID: References: <372821081.11203.1429561908825.JavaMail.nobody@jva2tc215.webex.com> In-Reply-To: <372821081.11203.1429561908825.JavaMail.nobody@jva2tc215.webex.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/mixed; boundary="_004_afa0d60b0c194c4d830ed8ea6ff169f9VAUSDITCHM2idirectnet_" MIME-Version: 1.0 Archived-At: Subject: [manet] FW: (Forward to others) WebEx meeting invitation: MANET Working Group Interim X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 20:38:24 -0000 --_004_afa0d60b0c194c4d830ed8ea6ff169f9VAUSDITCHM2idirectnet_ Content-Type: multipart/alternative; boundary="_000_afa0d60b0c194c4d830ed8ea6ff169f9VAUSDITCHM2idirectnet_" --_000_afa0d60b0c194c4d830ed8ea6ff169f9VAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gd29ya2luZyBncm91cCwNCg0KSGVyZSBpcyB0aGUgaW5mb3JtYXRpb24gb24gdGhlIE1B TkVUIFdHIGludGVyaW0gbWVldGluZywgc2NoZWR1bGVkIGZvciBNYXkgNi4NCg0KQXMgbWVudGlv bmVkIGVhcmxpZXIsIHRoZSB0ZW50YXRpdmUgYWdlbmRhIGZvciB0aGUgbWVldGluZyBpczoNCg0K MS4gICAgICAgRGlzY3VzcyBBT0RWdjIgbWlsZXN0b25lczsgcmVwb3J0IG9uIHRoZSBncm91cOKA mXMgc3RhdHVzDQoNCjIuICAgICAgIERpc2N1c3MgYW55IG9wZW4gaXNzdWVzIHdpdGggcmVnYXJk IHRvIERMRVAgTGFzdCBjYWxsDQoNCjMuICAgICAgIERpc2N1c3MgcG90ZW50aWFsIHJlLWNoYXJ0 ZXIgd29yayBpdGVtcw0KDQpQbGVhc2Ugc2VuZCBhbnkgYWdlbmRhLWJhc2hpbmcgdG8gdGhlIGxp c3QuIFdlIGhhdmUgYSAyLWhvdXIgc2xvdCwgYnV0IHdlIGRvbuKAmXQgKmhhdmUqIHRvIHVzZSBh bGwgb2YgdGhlIHRpbWXigKYgOy0pDQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KRnJvbTogTW9iaWxl IEFkLWhvYyBOZXR3b3JrcyBXb3JraW5nIEdyb3VwIFttYWlsdG86bWVzc2VuZ2VyQHdlYmV4LmNv bV0NClNlbnQ6IE1vbmRheSwgQXByaWwgMjAsIDIwMTUgNDozMiBQTQ0KVG86IG1hbmV0LWNoYWly c0BpZXRmLm9yZw0KU3ViamVjdDogKEZvcndhcmQgdG8gb3RoZXJzKSBXZWJFeCBtZWV0aW5nIGlu dml0YXRpb246IE1BTkVUIFdvcmtpbmcgR3JvdXAgSW50ZXJpbQ0KDQpZb3UgY2FuIGZvcndhcmQg dGhpcyBpbnZpdGF0aW9uIHRvIG90aGVycy4NCg0KDQpIZWxsbywNCg0KTW9iaWxlIEFkLWhvYyBO ZXR3b3JrcyBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJFeCBtZWV0 aW5nLg0KDQoNCg0KDQoNCk1BTkVUIFdvcmtpbmcgR3JvdXAgSW50ZXJpbQ0KDQpXZWRuZXNkYXks IE1heSA2LCAyMDE1DQoNCjExOjAwIGFtICB8ICBFYXN0ZXJuIERheWxpZ2h0IFRpbWUgKE5ldyBZ b3JrLCBHTVQtMDQ6MDApICB8ICAyIGhycw0KDQoNCg0KDQoNCkpvaW4gV2ViRXggbWVldGluZyA8 aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTk0YWI5Mzk3MWVlYzUyYWVh YWY5ZWJlZWNkOWYzYTBmPg0KDQoNCk1lZXRpbmcgbnVtYmVyOg0KDQo2NDkgNDE1IDYzOQ0KDQpN ZWV0aW5nIHBhc3N3b3JkOg0KDQoxMjM0NQ0KDQoNCg0KDQoNCkpvaW4gYnkgcGhvbmUNCg0KMS04 NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpDQoNCjEtNjUw LTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkNCg0KQWNjZXNzIGNvZGU6 IDY0OSA0MTUgNjM5DQoNClRvbGwtZnJlZSBjYWxsaW5nIHJlc3RyaWN0aW9uczxodHRwOi8vd3d3 LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZj4NCg0KDQoNCg0KDQpBZGQg dGhpcyBtZWV0aW5nPGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW03Mjg5 NjQyODBkNWQzNzVlOGFhNWNlYzUzMjRjOWYyMD4gdG8geW91ciBjYWxlbmRhci4NCg0KDQoNCg0K DQpDYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQuPGh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9tYz4NCg0KDQoNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90 ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0 aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUg ZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwg eW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBu b3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGgg dGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uDQoNCg0KDQoNCg== --_000_afa0d60b0c194c4d830ed8ea6ff169f9VAUSDITCHM2idirectnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglm b250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzY2NjY2NjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNl cmlmOw0KCWNvbG9yOiM2NjY2NjY7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LHNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExNDY3ODA3NjE7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0MTU2MDIwNDIgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9IiM2NjY2NjYiIHZsaW5rPSIjNjY2NjY2Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SGVsbG8gd29ya2luZyBncm91cCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SGVyZSBpcyB0aGUgaW5mb3JtYXRpb24gb24gdGhlIE1BTkVUIFdHIGludGVy aW0gbWVldGluZywgc2NoZWR1bGVkIGZvciBNYXkgNi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+QXMgbWVudGlvbmVkIGVhcmxpZXIsIHRoZSB0ZW50YXRpdmUg YWdlbmRhIGZvciB0aGUgbWVldGluZyBpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RGlzY3VzcyBBT0RWdjIgbWlsZXN0b25lczsgcmVwb3J0 IG9uIHRoZSBncm91cOKAmXMgc3RhdHVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRpc2N1c3MgYW55IG9wZW4gaXNzdWVzIHdpdGggcmVnYXJk IHRvIERMRVAgTGFzdCBjYWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkRpc2N1c3MgcG90ZW50aWFsIHJlLWNoYXJ0ZXIgd29yayBpdGVtczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHNlbmQgYW55 IGFnZW5kYS1iYXNoaW5nIHRvIHRoZSBsaXN0LiBXZSBoYXZlIGEgMi1ob3VyIHNsb3QsIGJ1dCB3 ZSBkb27igJl0ICo8Yj5oYXZlPC9iPiogdG8gdXNlIGFsbCBvZiB0aGUgdGltZeKApiA7LSkNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+U3RhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNb2Jp bGUgQWQtaG9jIE5ldHdvcmtzIFdvcmtpbmcgR3JvdXAgW21haWx0bzptZXNzZW5nZXJAd2ViZXgu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXByaWwgMjAsIDIwMTUgNDozMiBQTTxi cj4NCjxiPlRvOjwvYj4gbWFuZXQtY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IChGb3J3YXJkIHRvIG90aGVycykgV2ViRXggbWVldGluZyBpbnZpdGF0aW9uOiBNQU5FVCBXb3Jr aW5nIEdyb3VwIEludGVyaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dGFibGUgY2xhc3M9 Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0ibGVmdCIg d2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjMuNzVwdCAwaW4gMGluIDBpbiI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1h bFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0ibGVmdCIgd2lkdGg9IjUy NSIgc3R5bGU9IndpZHRoOjM5My43NXB0O21hcmdpbi1sZWZ0OjMuNzVwdCI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPllv dSBjYW4gZm9yd2FyZCB0aGlzIGludml0YXRpb24gdG8gb3RoZXJzLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVs ZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxl bWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9u dGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhz cGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZl cnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNv LWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNEQ0RDREIj5IZWxs bywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjcuNXB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0RDRENEQiPk1v YmlsZSBBZC1ob2MgTmV0d29ya3MgV29ya2luZyBHcm91cCBpbnZpdGVzIHlvdSB0byBqb2luIHRo aXMgV2ViRXggbWVldGluZy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1 cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBh cmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1y dWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJs ZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5 My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9 InBhZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDoxNS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBi b3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4w JSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1l bnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFw OmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50 LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNEQ0RDREIj5NQU5FVCBXb3JraW5nIEdyb3VwIEludGVyaW08L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0RDRE NEQiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5 bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPldl ZG5lc2RheSwgTWF5IDYsIDIwMTUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3Ry Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21z by1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNv LWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9y aXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNjY2NjY2Ij4xMTowMCBhbSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDtFYXN0ZXJuIERh eWxpZ2h0IFRpbWUgKE5ldyBZb3JrLCBHTVQtMDQ6MDApJm5ic3A7Jm5ic3A7fCZuYnNwOyZuYnNw OzIgaHJzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8 L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDtt c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVt ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0i MCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8 dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBp biAwaW4gMGluIDBpbjtoZWlnaHQ6MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUt aHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3It dmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjtt c28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFi bGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1l bGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowaW47d2lkdGg6YXV0byFpbXBv cnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1l bGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQt d3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxl bWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwQUZGOSI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01U SUQ9bTk0YWI5Mzk3MWVlYzUyYWVhYWY5ZWJlZWNkOWYzYTBmIj48Yj48c3BhbiBzdHlsZT0iY29s b3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iY29sb3I6IzAwQUZGOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+DQo8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4N CjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjAiIHN0eWxlPSJ3aWR0aDowaW47d2lkdGg6YXV0 byFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAzLjc1 cHQgMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij5NZWV0aW5nIG51bWJlcjoNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7 bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjY0OSA0MTUgNjM5DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4g My43NXB0IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0 O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJh Z3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVs ZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+TWVldGluZyBwYXNzd29y ZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4xMjM0NTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1l bGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVs ZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpv bnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRh YmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lk dGg9IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVp Z2h0OjE1LjBwdCI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDox NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDtt c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVt ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2 NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUg Y2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0i NTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Sm9pbiBieSBwaG9uZTwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzY2NjY2NiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1l bnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVu dC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFs OmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM2NjY2NjYiPjEtODc3LTY2OC00NDkzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2 NjY2NjYiPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBp biAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7 bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFn cmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxl OmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4xLTY1MC00NzktMzIw ODwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDtDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+ DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNv LWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28t ZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jp em9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM2NjY2NjYiPkFjY2VzcyBjb2RlOiZuYnNwOzY0OSA0MTUgNjM5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7 bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPjxhIGhyZWY9Imh0dHA6Ly93d3cud2Vi ZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtjb2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlvbjpub25lIj5Ub2xsLWZyZWUg Y2FsbGluZyByZXN0cmljdGlvbnM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv dGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rp c3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJN c29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5 bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0ciBzdHlsZT0iaGVpZ2h0OjE1LjBwdCI+ DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluO2hlaWdodDoxNS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpm cmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJv dW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5j aG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxh eTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0i d2lkdGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUu MHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNv LWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFw aDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij48YSBocmVmPSJodHRwczovL2ll dGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNzI4OTY0MjgwZDVkMzc1ZThhYTVjZWM1MzI0 YzlmMjAiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBBRkY5O3RleHQtZGVjb3JhdGlvbjpub25lIj5B ZGQgdGhpcyBtZWV0aW5nPC9zcGFuPjwvYT4gdG8geW91ciBjYWxlbmRhci48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28t ZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1l bGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6 b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdp ZHRoPSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9Imhl aWdodDoxNS4wcHQiPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtoZWlnaHQ6 MTUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7 bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxl bWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21z by1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3Rs eSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVt ZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxl IGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9 IjUyNSIgc3R5bGU9IndpZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0i cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh Y2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Q2FuJ3Qg am9pbiB0aGUgbWVldGluZz8NCjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9t YyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMEFGRjk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPkNvbnRh Y3Qgc3VwcG9ydC48L3NwYW4+PC9hPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNl OjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGlj YWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpu b25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1h bFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0id2lk dGg6MzkzLjc1cHQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6Ny41cHQiPg0KPHRkIHN0 eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbjtoZWlnaHQ6Ny41cHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6Ny41cHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8 L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFj ZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRp Y2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhl aWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6 bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjUyNSIgc3R5bGU9Indp ZHRoOjM5My43NXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBw dDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1l bGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7 bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFj dGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojQTBBMEEwIj5JTVBPUlRBTlQgTk9USUNFOiBQbGVh c2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGlu Zm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBt YXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nDQogdGhpcyBz ZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYg eW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2Vy bnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+ DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_afa0d60b0c194c4d830ed8ea6ff169f9VAUSDITCHM2idirectnet_-- --_004_afa0d60b0c194c4d830ed8ea6ff169f9VAUSDITCHM2idirectnet_ Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=3872; creation-date="Mon, 20 Apr 2015 20:32:24 GMT"; modification-date="Mon, 20 Apr 2015 20:32:24 GMT" Content-ID: Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJNb2JpbGUgQWQtaG9j IE5ldHdvcmtzIFdvcmtpbmcgR3JvdXAiO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1JTVlA9VFJVRTpN QUlMVE86bWFuZXQtY2hhaXJzQGlldGYub3JnCk9SR0FOSVpFUjtDTj0iTW9iaWxlIEFkLWhvYyBO ZXR3b3JrcyBXb3JraW5nIEdyb3VwIjpNQUlMVE86bWFuZXQtY2hhaXJzQGlldGYub3JnCkRUU1RB UlQ7VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE1MDUwNlQxMTAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVy biBUaW1lIjoyMDE1MDUwNlQxMzAwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MTQyOTU2MTkwOApVSUQ6M2QzNGFjMzEtNzc5My00 MDg1LTk1ZjgtMjBhMTY3ZjllYTBmCkRUU1RBTVA6MjAxNTA1MDZUMTUwMDAwWgpERVNDUklQVElP TjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9q LnBocD9NVElEPW01YWRiMzBiMDQ2N2U3ZGI1ZGJlZDA1MGMxZjc1MGQ4ZlxuTWVldGluZyBudW1i ZXI6IDY0OSA0MTUgNjM5XG5NZWV0aW5nIHBhc3N3b3JkOiAxMjM0NVxuXG5cbkpPSU4gQlkgUEhP TkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKSBc bjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcbkFjY2VzcyBj b2RlOiA2NDkgNDE1IDYzOVxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6IFxuaHR0 cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZcblxuXG5cbkNh bid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhh dCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBz ZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2Nv dmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBh dXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNv bnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBo b3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuClgtQUxULURFU0M7Rk1UVFlQRT10ZXh0 L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+IDxGT05UIFNJWkU9 IjQiIEZBQ0U9IkFSSUFMIj4JCTxhCQkJCQlocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tNWFkYjMwYjA0NjdlN2RiNWRiZWQwNTBjMWY3NTBkOGYiPjxGT05UIFNJ WkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9G T05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyOjwvRk9OVD4JCQkJCTwv dGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj42NDkgNDE1IDYzOTwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90YWJsZT4JCQk8 dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi Pk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIiICBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPjEyMzQ1PC9GT05UPjwvdGQ+PC90cj48L3RhYmxlPgkJPC9G T05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+Jm5ic3A7PEJSPjwvRk9O VD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0la RT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEtODc3LTY2OC00NDkz PC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05U PiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48 c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIG51bWJlciAo VVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+QWNjZXNzIGNvZGU6IDY0OSA0MTUgNjM5PC9GT05UPiZuYnNwOyA8QlI+ PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5w ZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9sbC1mcmVl IGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+PEJSPjxC Uj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi PgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9 IkFyaWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxCUj48 Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJ Q0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQg b3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQs IHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcg dGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5n cy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIg Y29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48L0ZPTlQ+ PC9GT05UPgpTVU1NQVJZOk1BTkVUIFdvcmtpbmcgR3JvdXAgSW50ZXJpbQpQUklPUklUWTo1CkNM QVNTOlBVQkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQ1TQpBQ1RJT046RElTUExBWQpERVND UklQVElPTjpSZW1pbmRlcgpFTkQ6VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo= --_004_afa0d60b0c194c4d830ed8ea6ff169f9VAUSDITCHM2idirectnet_-- From nobody Mon Apr 20 14:11:33 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C7F1B31C8; Mon, 20 Apr 2015 14:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 zGnRsIi7bUu4; Mon, 20 Apr 2015 14:11:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C89781B3139; Mon, 20 Apr 2015 14:11:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150420211128.30629.58872.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 14:11:28 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 20 Apr 2015 21:11:30 -0000 The Mobile Ad-hoc Networks (manet) working group will hold a virtual interim meeting as follows: Date: Wednesday, May 6, 2015 Time: 1100-1300 EDT (1500-1700 UTC) JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m2f5c335024d36b7e80e2653ea0774769 Meeting number: 649 415 639 Meeting password: 12345 JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 415 639 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Add this meeting to your calendar: https://ietf.webex.com/ietf/j.php?MTID=m0e3fb44d1bbbef98f5b0cf9e4651cd1e Can't join the meeting? Contact support here: https://ietf.webex.com/ietf/mc IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. From nobody Tue Apr 21 01:07:07 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4791B3730; Tue, 21 Apr 2015 01:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 RcXiqAn7Lsfy; Tue, 21 Apr 2015 01:07:02 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B541B372A; Tue, 21 Apr 2015 01:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10443; q=dns/txt; s=iport; t=1429603622; x=1430813222; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XhBKRFVrqoMUHs9/LeDFACGANzNQTK+NpiMCg2S7XmE=; b=E53UElAZuHxUDN40HQME/vJGjr+whZ5oFeWVO+5uLrKod9g2/1k4SuQD AJ+OSMBv1n/VeSqYl72Q5KEUG3YeDPRikP9UOZG27JfeRuDcHXINwR4Ju h6pYu4bKuBu1+fKH4lrXXOnRsk+li9MGuglCBwPkOhURX/5iLj/jz9YJz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BxFQCDBDZV/xbLJq1VBoNeXMYdgUUKC4V5AoF5EgEBAQEBAQF9QQODXQEBBAEBATU2CgEQCxIPFg8JAwIBAgEVIg4GAQwBBQIBAYgnDcoKAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLN4EjgwgBCQYGQweELQEEhGWKLYpDggKBIIYJijGDTiKBZBwegVc8MYECAR+BIgEBAQ X-IronPort-AV: E=Sophos;i="5.11,614,1422921600"; d="scan'208";a="441632913" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 21 Apr 2015 08:06:59 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3L86xHL019237; Tue, 21 Apr 2015 08:06:59 GMT Message-ID: <55360555.4020403@cisco.com> Date: Tue, 21 Apr 2015 10:07:49 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Randy Presuhn , manet@ietf.org References: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> In-Reply-To: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mib-doctors@ietf.org, disman@ietf.org Subject: Re: [manet] [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 08:07:06 -0000 Thanks Randy for your time. draft-ietf-manet-report-mib authors, What really concerns me is Randy's comment: "It's pretty obvious that this module has not seen a MIB compiler recently." This is inappropriate to ask for a MIB doctor review for a MIB module that doesn't even compile. Regards, Benoit > Hi - > > I was asked to take a look at draft-ietf-manet-report-mib-04. > This is *not* a full MIB doctor review; in my opinion some > fundamental issues need to be resolved before a detailed > review (either from a MIB doctor or disman perspective) > would be worthwhile. > > These are mostly just top-level issues that absolutely need to > be resolved. I fear that even though the questions aren't > terribly difficult, the fixes may result in significant document > churn. There are also some odds and ends that jumped out that > should be fixed before bothering with a serious review. I didn't > go into a lot of detail because the sheer number of problems > would make any such attempt seem like a DoS attack. The categories > here are: > (1) data type difficulties > (2) time stamping > (3) access control > (4) odds and ends > (5) questions of power > > Data Type Difficulties > > Location: Abstract and elswhere > > Example of Current text: > In particular, it describes objects for configuring autonomous report > generation on any device that supports MIBs containing objects that > resolve to type Integer32 (i.e., Integer32, Counter, Gauge, or > TimeTicks). to be used for performance monitoring. > > Problems: > - typographical nit: misplaced "." after ")" > - technical: "Counter" is not an SMIv2 type. I assume > "Counter32" is intended. If inclusion of > Counter64 is also intended, there are other problems. > - technical: "Gauge" is not an SMIv2 type. I assume > "Gauge32" is intended. > - technical: the range of type Integer32 (defined in RFC 2578) > does not cover the entire ranges of type Counter32, > Gauge32, or TimeTicks, as defined in RFC 3416. > The SMI type *Unsigned32* does cover the same ranges. > - technical: the use of "resolve" is questionable, since all > of the data types mentioned have distinct ASN.1 > tags. (RFC 3416 section 3) > > It gets worse. The definitions for reportSampledCurrentMeasurementValue > and reportSampledHistoricalReportsValue limit their ranges to > 1 to 2,147,483,647. This means that samples of Counter32, Gauge32, > and TimeTicks with values of 0 or anything in the range from > 2,147,483,647 to 4,294,967,295 cannot be represented. > > The reportSampledCurrentMeasurementStatus and the > reportSampledHistoricalMeasurementStatus OBJECT-TYPEs appear > to be an attempt to address this problem, and would *almost* > work if the MeasurementValue were of type Unsigned32, and > if its range were not constrained. However, if the module > functioned as though sampled data, regardless of type, were > "cast" to Unsigned32, then the valuePositive(2) and valueNegative(3) > aren't really needed, since the signedness of the sampled values > can be recovered from reportSampledStudyOid. > > > Time Stamping > There are a bunch of concerns related to time stamping. > > - several OBJECT-TYPE definitions have impossible syntaxes. > "sysUptime" is not a syntax. It should not be IMPORTed. > For reportSampledCurrentMeasurementTime and for > reportSampledHistoricalMeasurementTime you intend to > use a syntax of "TimeStamp" > > - HOWEVER, there is a health warning attached to the > TimeStamp textual convention in RFC 2579, and it applies > here. Firstly, it applies because the set of values > permitted for reportSampledStudySamplingInterval means > it is possible to construct a single report in which > the sample times are ambiguous. More significantly, > for historical reports, especially for "archival" purposes, > the sample times are almost certainly ambiguous. Consequently, > I think there needs to be a re-think of whether this is > the correct data type for the intended use. > > - Many counter objects have "discontinuity indicators" other > than sysUpTime. This module does not provide a straightforward > way to cope with these. See RFC 2981 (search for "discontinuity") > to see one approach. > > - reportSampledStudySamplingInterval may be modified during a > report. This means that conventional algorithms for detecting > sysUpTime discontinuities within a report may not work. > > Access Control > There are a couple of ways in which access control considerations > might affect the design of this module. The presence of > reportSampledStudyOwner suggests that someone was thinking about > this, but some changes are needed to make things work. > > (1) reportSampledControlEntry should have an INDEX of > { reportSampledStudyOwner, reportSampledStudyIndex } > This is necessary if you want to be able to limit access > to specific studies to specific users in a reasonable way, > and to prevent collisions between users during the creation > of studies. > > (2) Likewise, reportSampledCurrentReportsStatusEntry should > also have an INDEX of > { reportSampledStudyOwner, reportSampledStudyIndex }, > reportSampledCurrentReportsEntry should have > { reportSampledStudyIndex, reportSampledCurrentMeasurementIndex } > reportSampledHistoricalReportsEntry should have > { reportSampledStudyOwner, reportSampledStudyIndex, > reportSampledHistoricalReportIndex, > reportSampledHistoricalMeasurementIndex } > > (3) A consequence is that (for example) reportSampledStudyIndex > only needs to be unique for a given owner, and not among > all studies. > > Note that reportSampledDataCollectionFailure suffers from the > "who's buried in Grant's Tomb" problem, and can be simplified. > > A second way in which access control matters here is that the > sampling process should not circumvent access control. I strongly > urge putting in explicit language about this. I'd suggest the following > as a starting point for discussion: > > Security for local access effectively requires recording appropriate > security credentials of the creator of a reportSampledControlEntry > and using those to access the local objects. These security > credentials are parameters necessary as inputs to isAccessAllowed > from the Architecture for Describing SNMP Management Frameworks. > The system MUST (conceptually) use isAccessAllowed at the time of > each access (not just creation of the reportSampledControlEntry) > to ensure that it does not permit unauthorized access. > > When using VACM, the security administrator SHOULD ensure that > access permitted to the collected data and notifications (that is, > access to reportSampledCurrentReportsStatusTable.*., > reportSampledCurrentReportsTable.*., and > reportSampledHistoricalReportsTable.*.) is > limited to the 's appropriate VACM group. > > Odds and ends: > It's pretty obvious that this module has not seen a MIB compiler > recently. In addition to the syntactic problem, there are some > glaring stylistic issues that, if fixed now, will make an eventual > MIB doctor review go a lot smoother. > > (1) Use of data types. Every single use of Integer32 in this > module is arguably incorrect. Unsigned32 would be a better > choice, since these are all sub-typed to exclude negative > values. > > (2) Use of data types. reportSampledStudySamplingInterval > seems like it should make use of RFC 2579 TimeInterval, perhaps > constrained to be at least 10. > > (3) Use of UNITS. Though it's a little unusual (but not unheard-of) > to use UNITS with non-counter types, a value of "count" in, > for example, reportSampledStudyMaximumNumberOfHistoricalReports, > is really not helpful. In that particular case, "reports" > would make more sense. > > (4) Attention to error cases: there are a bunch of error situations > that should be given a little attention. What happens when > there's no longer enough memory to keep accumulating studies? > What happens when the object instance referred to by > reportSampledStudyOid is the wrong data type? > > (5) The use of non-volatile storage doesn't seem to have been > completely thought through. It doesn't make sense to me, for > example, to have the control entries in backing storage, but > not the "archival" historical data. Likewise, if a control > entry is restored from non-volatile upon reboot, does that > cause a new report to be started or does it pick up where > it left off on a existing report? > > (6) Notification throttling. > > Questions of Power > I think the decision to limit the module to local access is reasonable > given the intended applicability. I do think, however, there should > be a clear explanation of the rationale behind limiting its functionality > to the current SNMP context, unlike RFC 1981. > > I think it would be helpful to at least suggest how it is envisioned > that future "statistical" functions alluded to in the text would work > with this MIB module - are they expected to be extensions of this > module or completely new ones? > > I honestly have some difficulty seeing what good this module would > do; perhaps the WG has discussed concrete use cases, but don't be > surpised if a future reviewer raises questions on this point. > > Randy > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > . > From nobody Tue Apr 21 05:24:38 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D621ACC8F for ; Tue, 21 Apr 2015 05:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 Ig2KGZTebfPM for ; Tue, 21 Apr 2015 05:24:35 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::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 13C751ACCDA for ; Tue, 21 Apr 2015 05:24:35 -0700 (PDT) Received: by wgin8 with SMTP id n8so211182892wgi.0 for ; Tue, 21 Apr 2015 05:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=hCL41e2zA+9Ev5Hj9qO+oq5oJ6zzHoaCltmE+T56R+E=; b=l9elsBrM6XdI4Aajf47lUFx5pxCwUyHvtscittbJjfTU1tHbOCHKnXiJlaTiJwXIaV xWs0Lm0Ap76MMf8MH9DF+CZFkLxAgWlCbmVd5IBgTmP79YZVVSLTLpg5FBu0mC3B5krL nQQaed1HALH/b1LZydrSBf54s4a7w8VGIVc02Rgj4CFoIV8pFRSb2iaFNy1aR3ul/OJ2 q4yEabv8XEiJOwgMB4+dh463g2Am0k9uW+TUaGvZlD49fMK9AaO3rX9u8KuWDjKkK2aN NH8B8a5V6GfRt5hCXo5CTwkwg3X8lXkHNu6pZEDTIghGZFCvVFPYJJ1jkH8x0M6/P38D /Zsg== X-Received: by 10.194.77.230 with SMTP id v6mr41372568wjw.25.1429619073829; Tue, 21 Apr 2015 05:24:33 -0700 (PDT) Received: from [10.0.4.178] ([217.158.48.187]) by mx.google.com with ESMTPSA id go4sm19499816wib.1.2015.04.21.05.24.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2015 05:24:33 -0700 (PDT) Message-ID: <55364180.6010902@gmail.com> Date: Tue, 21 Apr 2015 13:24:32 +0100 From: John Dowdell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: manet@ietf.org References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <5534D9B4.5030408@fkie.fraunhofer.de> <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> <5534F744.80209@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016753465D@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 12:24:37 -0000 AB, that's not the point. In order for DLEP to be useful to upstream protocols, it has to be relied upon to deliver something. At the moment, the something includes bandwidth (in its various forms) and latency. If you don't know the modem's best guess about those, it's very difficult for DLEP to be useful in calculating forwarding decisions. Essentially you are back to routing in the dark. If a modem cannot, for whatever reasons, report either bandwidth or latency, the network implementers have to administratively add a figure, based on how they think the link performs. DLEP is very useful in creating plug and play networks, so if the modem can report a rough order of magnitude, that is so much better than no guess at all. John On 20/04/15 16:03, Abdussalam Baryun wrote: > I think sometimes using optional items is more flexible than mandatory > and gives advantages to the protocol. It should not create any problem > in the protocol operations, because the protocol does not use it, > but the router can use that information or leave it. Making it > mandatory may mean that the protocol will be affected if not have its > value but the protocol is not affected. > > AB > From nobody Tue Apr 21 05:43:31 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9D81ACD2F; Tue, 21 Apr 2015 05:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gfL2Wvm20o0B; Tue, 21 Apr 2015 05:43:21 -0700 (PDT) Received: from ucol19pa13.eemsg.mail.mil (ucol19pa13.eemsg.mail.mil [214.24.24.86]) by ietfa.amsl.com (Postfix) with ESMTP id ABF6F1ACD3C; Tue, 21 Apr 2015 05:43:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,615,1422921600"; d="scan'208";a="144291235" Received: from edge-eurd01.mail.mil ([214.24.180.6]) by ucol19pa13.eemsg.mail.mil with ESMTP; 21 Apr 2015 12:43:18 +0000 Received: from UPDCHU30.easf.csd.disa.mil (214.24.180.162) by edge-eurd01.mail.mil (214.24.180.6) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 21 Apr 2015 12:43:20 +0000 Received: from UCOLHPMM.easf.csd.disa.mil (131.64.104.41) by UPDCHU30.easf.csd.disa.mil (214.24.180.162) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 21 Apr 2015 12:43:19 +0000 Received: from UCOLHPKT.easf.csd.disa.mil ([169.254.2.143]) by ucolhpmm.easf.csd.disa.mil ([131.64.104.41]) with mapi id 14.03.0224.002; Tue, 21 Apr 2015 12:43:17 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: Benoit Claise , Randy Presuhn , "manet@ietf.org" Thread-Topic: [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04 Thread-Index: AQHQfApB4PkU+fOlpU6ptluNDDGHfZ1XZ89Q Date: Tue, 21 Apr 2015 12:43:17 +0000 Message-ID: References: <18699062.1429399645552.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <55360555.4020403@cisco.com> In-Reply-To: <55360555.4020403@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.22.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mib-doctors@ietf.org" , "disman@ietf.org" Subject: Re: [manet] [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 12:43:28 -0000 Hi Benoit, This review of the report MIB was not intended to be the MIB Doctor's revie= w. The module has not reached WG last call. Instead, I wanted someone with DISMAN knowledge to review the structure of = the MIB to ensure its design leverages (correctly) the Capabilities from the DISMAN MIB Modules and provides the desired functiona= lity. Further, the WG has not put a lot of eyes on the module development= and we have gone through a lot of major revisions to get to this point whe= re we are using existing DISMAN capabilities. I will clean up the MIB (based upon Randy's detailed comments) and ensure i= t passes a MIB compiler in the next revision. Thanks, Bob US Army CERDEC QUEST Program, S&TCD APG, MD (c) 443.910.4420 (o) 443.395.8744 robert.g.cole@us.army.mil > -----Original Message----- > From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Beno= it Claise > Sent: Tuesday, April 21, 2015 4:08 AM > To: Randy Presuhn; manet@ietf.org > Cc: mib-doctors@ietf.org; disman@ietf.org > Subject: Re: [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04 >=20 > Thanks Randy for your time. >=20 > draft-ietf-manet-report-mib authors, > What really concerns me is Randy's comment: "It's pretty obvious that thi= s module has not seen a MIB compiler recently." > This is inappropriate to ask for a MIB doctor review for a MIB module tha= t doesn't even compile. >=20 > Regards, Benoit > > Hi - > > > > I was asked to take a look at draft-ietf-manet-report-mib-04. > > This is *not* a full MIB doctor review; in my opinion some fundamental > > issues need to be resolved before a detailed review (either from a MIB > > doctor or disman perspective) would be worthwhile. > > > > These are mostly just top-level issues that absolutely need to be > > resolved. I fear that even though the questions aren't terribly > > difficult, the fixes may result in significant document churn. There > > are also some odds and ends that jumped out that should be fixed > > before bothering with a serious review. I didn't go into a lot of > > detail because the sheer number of problems would make any such > > attempt seem like a DoS attack. The categories here are: > > (1) data type difficulties > > (2) time stamping > > (3) access control > > (4) odds and ends > > (5) questions of power > > > > Data Type Difficulties > > > > Location: Abstract and elswhere > > > > Example of Current text: > > In particular, it describes objects for configuring autonomous rep= ort > > generation on any device that supports MIBs containing objects tha= t > > resolve to type Integer32 (i.e., Integer32, Counter, Gauge, or > > TimeTicks). to be used for performance monitoring. > > > > Problems: > > - typographical nit: misplaced "." after ")" > > - technical: "Counter" is not an SMIv2 type. I assume > > "Counter32" is intended. If inclusion of > > Counter64 is also intended, there are other probl= ems. > > - technical: "Gauge" is not an SMIv2 type. I assume > > "Gauge32" is intended. > > - technical: the range of type Integer32 (defined in RFC 2578) > > does not cover the entire ranges of type Counter= 32, > > Gauge32, or TimeTicks, as defined in RFC 3416. > > The SMI type *Unsigned32* does cover the same ra= nges. > > - technical: the use of "resolve" is questionable, since all > > of the data types mentioned have distinct ASN.1 > > tags. (RFC 3416 section 3) > > > > It gets worse. The definitions for reportSampledCurrentMeasurementV= alue > > and reportSampledHistoricalReportsValue limit their ranges to > > 1 to 2,147,483,647. This means that samples of Counter32, Gauge32, > > and TimeTicks with values of 0 or anything in the range from > > 2,147,483,647 to 4,294,967,295 cannot be represented. > > > > The reportSampledCurrentMeasurementStatus and the > > reportSampledHistoricalMeasurementStatus OBJECT-TYPEs appear > > to be an attempt to address this problem, and would *almost* > > work if the MeasurementValue were of type Unsigned32, and > > if its range were not constrained. However, if the module > > functioned as though sampled data, regardless of type, were > > "cast" to Unsigned32, then the valuePositive(2) and valueNegative(3) > > aren't really needed, since the signedness of the sampled values > > can be recovered from reportSampledStudyOid. > > > > > > Time Stamping > > There are a bunch of concerns related to time stamping. > > > > - several OBJECT-TYPE definitions have impossible syntaxes. > > "sysUptime" is not a syntax. It should not be IMPORTed. > > For reportSampledCurrentMeasurementTime and for > > reportSampledHistoricalMeasurementTime you intend to > > use a syntax of "TimeStamp" > > > > - HOWEVER, there is a health warning attached to the > > TimeStamp textual convention in RFC 2579, and it applies > > here. Firstly, it applies because the set of values > > permitted for reportSampledStudySamplingInterval means > > it is possible to construct a single report in which > > the sample times are ambiguous. More significantly, > > for historical reports, especially for "archival" purposes, > > the sample times are almost certainly ambiguous. Consequently, > > I think there needs to be a re-think of whether this is > > the correct data type for the intended use. > > > > - Many counter objects have "discontinuity indicators" other > > than sysUpTime. This module does not provide a straightforward > > way to cope with these. See RFC 2981 (search for "discontinuity") > > to see one approach. > > > > - reportSampledStudySamplingInterval may be modified during a > > report. This means that conventional algorithms for detecting > > sysUpTime discontinuities within a report may not work. > > > > Access Control > > There are a couple of ways in which access control considerations > > might affect the design of this module. The presence of > > reportSampledStudyOwner suggests that someone was thinking about > > this, but some changes are needed to make things work. > > > > (1) reportSampledControlEntry should have an INDEX of > > { reportSampledStudyOwner, reportSampledStudyIndex } > > This is necessary if you want to be able to limit access > > to specific studies to specific users in a reasonable way, > > and to prevent collisions between users during the creation > > of studies. > > > > (2) Likewise, reportSampledCurrentReportsStatusEntry should > > also have an INDEX of > > { reportSampledStudyOwner, reportSampledStudyIndex }, > > reportSampledCurrentReportsEntry should have > > { reportSampledStudyIndex, reportSampledCurrentMeasurementInde= x } > > reportSampledHistoricalReportsEntry should have > > { reportSampledStudyOwner, reportSampledStudyIndex, > > reportSampledHistoricalReportIndex, > > reportSampledHistoricalMeasurementIndex } > > > > (3) A consequence is that (for example) reportSampledStudyIndex > > only needs to be unique for a given owner, and not among > > all studies. > > > > Note that reportSampledDataCollectionFailure suffers from the > > "who's buried in Grant's Tomb" problem, and can be simplified. > > > > A second way in which access control matters here is that the > > sampling process should not circumvent access control. I strongly > > urge putting in explicit language about this. I'd suggest the follo= wing > > as a starting point for discussion: > > > > Security for local access effectively requires recording appropri= ate > > security credentials of the creator of a reportSampledControlEntr= y > > and using those to access the local objects. These security > > credentials are parameters necessary as inputs to isAccessAllowed > > from the Architecture for Describing SNMP Management Frameworks. > > The system MUST (conceptually) use isAccessAllowed at the time of > > each access (not just creation of the reportSampledControlEntry) > > to ensure that it does not permit unauthorized access. > > > > When using VACM, the security administrator SHOULD ensure that > > access permitted to the collected data and notifications (that is= , > > access to reportSampledCurrentReportsStatusTable.*., > > reportSampledCurrentReportsTable.*., and > > reportSampledHistoricalReportsTable.*.) is > > limited to the 's appropriate VACM group. > > > > Odds and ends: > > It's pretty obvious that this module has not seen a MIB compiler > > recently. In addition to the syntactic problem, there are some > > glaring stylistic issues that, if fixed now, will make an eventual > > MIB doctor review go a lot smoother. > > > > (1) Use of data types. Every single use of Integer32 in this > > module is arguably incorrect. Unsigned32 would be a better > > choice, since these are all sub-typed to exclude negative > > values. > > > > (2) Use of data types. reportSampledStudySamplingInterval > > seems like it should make use of RFC 2579 TimeInterval, perhaps > > constrained to be at least 10. > > > > (3) Use of UNITS. Though it's a little unusual (but not unheard-of) > > to use UNITS with non-counter types, a value of "count" in, > > for example, reportSampledStudyMaximumNumberOfHistoricalReports, > > is really not helpful. In that particular case, "reports" > > would make more sense. > > > > (4) Attention to error cases: there are a bunch of error situations > > that should be given a little attention. What happens when > > there's no longer enough memory to keep accumulating studies? > > What happens when the object instance referred to by > > reportSampledStudyOid is the wrong data type? > > > > (5) The use of non-volatile storage doesn't seem to have been > > completely thought through. It doesn't make sense to me, for > > example, to have the control entries in backing storage, but > > not the "archival" historical data. Likewise, if a control > > entry is restored from non-volatile upon reboot, does that > > cause a new report to be started or does it pick up where > > it left off on a existing report? > > > > (6) Notification throttling. > > > > Questions of Power > > I think the decision to limit the module to local access is reasonab= le > > given the intended applicability. I do think, however, there should > > be a clear explanation of the rationale behind limiting its function= ality > > to the current SNMP context, unlike RFC 1981. > > > > I think it would be helpful to at least suggest how it is envisioned > > that future "statistical" functions alluded to in the text would wor= k > > with this MIB module - are they expected to be extensions of this > > module or completely new ones? > > > > I honestly have some difficulty seeing what good this module would > > do; perhaps the WG has discussed concrete use cases, but don't be > > surpised if a future reviewer raises questions on this point. > > > > Randy > > > > _______________________________________________ > > MIB-DOCTORS mailing list > > MIB-DOCTORS@ietf.org > > https://www.ietf.org/mailman/listinfo/mib-doctors > > . > > >=20 > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors From nobody Tue Apr 21 06:18:54 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6161A1A6B for ; Tue, 21 Apr 2015 06:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EriI7tvzYU5o for ; Tue, 21 Apr 2015 06:18:40 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 0319F1A1A82 for ; Tue, 21 Apr 2015 06:18:39 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,616,1422939600"; d="scan'208";a="17286441" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport.idirect.net with ESMTP; 21 Apr 2015 09:18:39 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 21 Apr 2015 09:18:38 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Tue, 21 Apr 2015 09:18:38 -0400 From: "Ratliff, Stanley" To: John Dowdell , "manet@ietf.org" Thread-Topic: [manet] DLEP-09 Thread-Index: AdB5Dijsuf08P0oXRc6vubghpHd05gCjo64AACy7iwAABpjIUA== Date: Tue, 21 Apr 2015 13:18:36 +0000 Message-ID: References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> <5534D9B4.5030408@fkie.fraunhofer.de> <38A5475DE83986499AEACD2CFAFC3F980167534069@tss-server1.home.tropicalstormsoftware.com> <5534F744.80209@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016753465D@tss-server1.home.tropicalstormsoftware.com> <55364180.6010902@gmail.com> In-Reply-To: <55364180.6010902@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 13:18:45 -0000 John,=20 I think we've reached rough consensus that text should be added to say impl= ementations MUST provide at a minimum a reasonable representation of latenc= y during the Peer Init/Peer Init ACK sequence. This "reasonable representat= ion" represents the "best guess" you are referring to, and would under the = existing document be used as the default value for all destinations reachab= le via the radio peer.=20 Regards, Stan > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of John Dowdell > Sent: Tuesday, April 21, 2015 8:25 AM > To: manet@ietf.org > Subject: Re: [manet] DLEP-09 >=20 > AB, that's not the point. In order for DLEP to be useful to upstream prot= ocols, > it has to be relied upon to deliver something. At the moment, the somethi= ng > includes bandwidth (in its various forms) and latency. If you don't know = the > modem's best guess about those, it's very difficult for DLEP to be useful= in > calculating forwarding decisions. Essentially you are back to routing in = the > dark. >=20 > If a modem cannot, for whatever reasons, report either bandwidth or > latency, the network implementers have to administratively add a figure, > based on how they think the link performs. DLEP is very useful in creatin= g > plug and play networks, so if the modem can report a rough order of > magnitude, that is so much better than no guess at all. >=20 > John >=20 > On 20/04/15 16:03, Abdussalam Baryun wrote: > > I think sometimes using optional items is more flexible than mandatory > > and gives advantages to the protocol. It should not create any problem > > in the protocol operations, because the protocol does not use it, but > > the router can use that information or leave it. Making it mandatory > > may mean that the protocol will be affected if not have its value but > > the protocol is not affected. > > > > AB > > >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue Apr 21 07:14:28 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1B41A8992 for ; Tue, 21 Apr 2015 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JBlhWsDmvs2j for ; Tue, 21 Apr 2015 07:14:24 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 24CDB1A86E3 for ; Tue, 21 Apr 2015 07:14:24 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,616,1422939600"; d="jpg'145?scan'145,208,217,145";a="6888170" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport2.idirect.net with ESMTP; 21 Apr 2015 10:14:23 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 21 Apr 2015 10:14:22 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Tue, 21 Apr 2015 10:14:22 -0400 From: "Ratliff, Stanley" To: "manet@ietf.org" Thread-Topic: DLEP-09 Last Call issue Thread-Index: AdB8PJ33ex26dcY6Rl+Hyitow1TE3Q== Date: Tue, 21 Apr 2015 14:14:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/related; boundary="_004_dcf2ffb3d9fe433aba9be04c53c058a9VAUSDITCHM2idirectnet_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [manet] DLEP-09 Last Call issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 14:14:27 -0000 --_004_dcf2ffb3d9fe433aba9be04c53c058a9VAUSDITCHM2idirectnet_ Content-Type: multipart/alternative; boundary="_000_dcf2ffb3d9fe433aba9be04c53c058a9VAUSDITCHM2idirectnet_" --_000_dcf2ffb3d9fe433aba9be04c53c058a9VAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group Participants, It was noted during a private discussion that there could be an issue with = DLEP and Heartbeats. Specifically, the scenario mentioned was: 1. Peer Discovery/Peer Offer processing takes place with no errors or= issues. 2. Router uses information received from Peer Offer, and connects a s= ocket to the modem. Router sends Peer Initialization, with a Heartbeat TLV. 3. Modem, for whatever reason, *fails* to respond to Peer Initializat= ion. The question/issue is that Heartbeats (if used at all) aren't fully establi= shed at that point, since they require the Peer Initialization/Peer Initial= ization ACK sequence. So what to do? Here is the proposed fix - the following text will be inserted into the Pee= r Initialization section: "It should be noted that Heartbeats (if used) are not fully established unt= il both the Peer Initialization and Peer Initialization ACK messages have b= een sent and successfully processed by the appropriate recipient. This leav= es the possibility for timing issues to occur (e.g. a Peer Initialization m= essage is sent from router to modem, but no Peer Initialization ACK is rece= ived). Prior to the establishment of the Heartbeat interval, heuristics for= determining the amount of time to wait for a specific message, or to decla= re the session inoperative, are left to implementers. However, it is recomm= ended that an implementation select some reasonable multiple of its own pro= posed Heartbeat interval in these cases, in order to minimize the number of= inputs to the implementation." Other opinions are welcome. Regards, Stan ________________________________ Stan Ratliff | Architect, Applied Research VT iDirect | 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, US= A T: +1 703 544-8520 | F: +1 222 123-4567 sratliff@idirect.net | www.idirect.net Connect with iDirect: Twitter.com/iDirect | = Facebook.com/iDirect [cid:image001.jpg@01D07C1B.D55C6DB0] Advancing a Connected World --_000_dcf2ffb3d9fe433aba9be04c53c058a9VAUSDITCHM2idirectnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Working Group Participants,

 

It was noted during a private discussion that there = could be an issue with DLEP and Heartbeats. Specifically, the scenario ment= ioned was:

 

1.     &= nbsp; Peer Discovery/Peer Offer processing takes place wi= th no errors or issues.

2.     &= nbsp; Router uses information received from Peer Offer, a= nd connects a socket to the modem. Router sends Peer Initialization, with a= Heartbeat TLV.

3.     &= nbsp; Modem, for whatever reason, *fails* to respo= nd to Peer Initialization.

 

The question/issue is that Heartbeats (if used at al= l) aren’t fully established at that point, since they require the Pee= r Initialization/Peer Initialization ACK sequence. So what to do?

 

Here is the proposed fix – the following text = will be inserted into the Peer Initialization section:

 

"It should be noted that Heartbeats (if used) a= re not fully established until both the Peer Initialization and Peer Initia= lization ACK messages have been sent and successfully processed by the appr= opriate recipient. This leaves the possibility for timing issues to occur (e.g. a Peer Initialization message is sent fro= m router to modem, but no Peer Initialization ACK is received). Prior to th= e establishment of the Heartbeat interval, heuristics for determining the a= mount of time to wait for a specific message, or to declare the session inoperative, are left to implementers. = However, it is recommended that an implementation select some reasonable mu= ltiple of its own proposed Heartbeat interval in these cases, in order to m= inimize the number of inputs to the implementation."

 

 

Other opinions are welcome.

 

Regards,

Stan

Stan Ratliff  |  Architect, Applied Research<= /span>

VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Hernd= on, VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 123-4567

sratliff@i= direct.net  |  www.idirect.net

Connect with iDirect: Twitter.com/iDi= rect  |  Facebook.com/i= Direct

 

<= /p>

Advancing a Connected World

 <= /span>

 

--_000_dcf2ffb3d9fe433aba9be04c53c058a9VAUSDITCHM2idirectnet_-- --_004_dcf2ffb3d9fe433aba9be04c53c058a9VAUSDITCHM2idirectnet_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3003; creation-date="Tue, 21 Apr 2015 14:14:20 GMT"; modification-date="Tue, 21 Apr 2015 14:14:20 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --_004_dcf2ffb3d9fe433aba9be04c53c058a9VAUSDITCHM2idirectnet_-- From nobody Tue Apr 21 09:48:41 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028431AD305 for ; Tue, 21 Apr 2015 09:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 85ZzG4WThDfA for ; Tue, 21 Apr 2015 09:48:35 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id C86F51B29B9 for ; Tue, 21 Apr 2015 09:45:23 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t3LGjLi2025039; Tue, 21 Apr 2015 12:45:21 -0400 From: "Wiggins, David - 0665 - MITLL" To: "Ratliff, Stanley" , "manet@ietf.org" Thread-Topic: DLEP-09 Last Call issue Thread-Index: AdB8PJ33ex26dcY6Rl+Hyitow1TE3QAFPsCw Date: Tue, 21 Apr 2015 16:45:20 +0000 Message-ID: <051CC8AC48CA52479811BF267278633A1323BB23@LLE2K10-MBX01.mitll.ad.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.147] Content-Type: multipart/related; boundary="_004_051CC8AC48CA52479811BF267278633A1323BB23LLE2K10MBX01mit_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-21_06:2015-04-21,2015-04-21,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504210175 Archived-At: Subject: Re: [manet] DLEP-09 Last Call issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 16:48:39 -0000 --_004_051CC8AC48CA52479811BF267278633A1323BB23LLE2K10MBX01mit_ Content-Type: multipart/alternative; boundary="_000_051CC8AC48CA52479811BF267278633A1323BB23LLE2K10MBX01mit_" --_000_051CC8AC48CA52479811BF267278633A1323BB23LLE2K10MBX01mit_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Several other signals that expect ACKs have words like: "The sender of the = Destination Up signal is free to define its retry heuristics in event of a = timeout." I see that Peer Initialization does not say this, but perhaps it= should. Wouldn't that fix the problem, and be more in line with the rest = of the draft? David From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ratliff, Stanley Sent: Tuesday, April 21, 2015 10:14 AM To: manet@ietf.org Subject: [manet] DLEP-09 Last Call issue Working Group Participants, It was noted during a private discussion that there could be an issue with = DLEP and Heartbeats. Specifically, the scenario mentioned was: 1. Peer Discovery/Peer Offer processing takes place with no errors or= issues. 2. Router uses information received from Peer Offer, and connects a s= ocket to the modem. Router sends Peer Initialization, with a Heartbeat TLV. 3. Modem, for whatever reason, *fails* to respond to Peer Initializat= ion. The question/issue is that Heartbeats (if used at all) aren't fully establi= shed at that point, since they require the Peer Initialization/Peer Initial= ization ACK sequence. So what to do? Here is the proposed fix - the following text will be inserted into the Pee= r Initialization section: "It should be noted that Heartbeats (if used) are not fully established unt= il both the Peer Initialization and Peer Initialization ACK messages have b= een sent and successfully processed by the appropriate recipient. This leav= es the possibility for timing issues to occur (e.g. a Peer Initialization m= essage is sent from router to modem, but no Peer Initialization ACK is rece= ived). Prior to the establishment of the Heartbeat interval, heuristics for= determining the amount of time to wait for a specific message, or to decla= re the session inoperative, are left to implementers. However, it is recomm= ended that an implementation select some reasonable multiple of its own pro= posed Heartbeat interval in these cases, in order to minimize the number of= inputs to the implementation." Other opinions are welcome. Regards, Stan ________________________________ Stan Ratliff | Architect, Applied Research VT iDirect | 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, US= A T: +1 703 544-8520 | F: +1 222 123-4567 sratliff@idirect.net | www.idirect.net Connect with iDirect: Twitter.com/iDirect | = Facebook.com/iDirect [cid:image001.jpg@01D07C30.8DBE2E70] Advancing a Connected World --_000_051CC8AC48CA52479811BF267278633A1323BB23LLE2K10MBX01mit_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Several other signals that expect ACKs have words like: &=
#8220;The sender of the Destination Up signal is free to define its retry h=
euristics in event of a timeout.”  I see that Peer Initializatio=
n does not say this, but perhaps it should.  Wouldn’t that fix t=
he problem, and be more in line with the rest of the draft?
 
David

 

 

From: manet [m= ailto:manet-bounces@ietf.org] On Behalf Of Ratliff, Stanley
Sent: Tuesday, April 21, 2015 10:14 AM
To: manet@ietf.org
Subject: [manet] DLEP-09 Last Call issue

 

Working Group Participants,

 

It was noted during a private discussion that there = could be an issue with DLEP and Heartbeats. Specifically, the scenario ment= ioned was:

 

1.       Peer Discovery/Peer Offer processing takes place with no errors or i= ssues.

2.       Router uses information received from Peer Offer, and connects a soc= ket to the modem. Router sends Peer Initialization, with a Heartbeat TLV.

3.       Modem, for whatever reason, *fails* to respond to Peer Initia= lization.

 

The question/issue is that Heartbeats (if used at al= l) aren’t fully established at that point, since they require the Pee= r Initialization/Peer Initialization ACK sequence. So what to do?

 

Here is the proposed fix – the following text = will be inserted into the Peer Initialization section:

 

"It should be noted that Heartbeats (if used) a= re not fully established until both the Peer Initialization and Peer Initia= lization ACK messages have been sent and successfully processed by the appr= opriate recipient. This leaves the possibility for timing issues to occur (e.g. a Peer Initialization message is sent fro= m router to modem, but no Peer Initialization ACK is received). Prior to th= e establishment of the Heartbeat interval, heuristics for determining the a= mount of time to wait for a specific message, or to declare the session inoperative, are left to implementers. = However, it is recommended that an implementation select some reasonable mu= ltiple of its own proposed Heartbeat interval in these cases, in order to m= inimize the number of inputs to the implementation."

 

 

Other opinions are welcome.

 

Regards,

Stan

Stan Ratliff  |  Architect, Applied Research

VT iDirect  |  13861 Sunrise Valley Drive, Suit= e 300, Herndon, VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 = 123-4567

sratliff@idirect.net  |  www.idirect.net

Connect with iDirect: Twi= tter.com/iDirect  |  Fa= cebook.com/iDirect<= /b>

 

=

Advancing a Connected World

&= nbsp;

 

--_000_051CC8AC48CA52479811BF267278633A1323BB23LLE2K10MBX01mit_-- --_004_051CC8AC48CA52479811BF267278633A1323BB23LLE2K10MBX01mit_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3003; creation-date="Tue, 21 Apr 2015 16:45:20 GMT"; modification-date="Tue, 21 Apr 2015 16:45:20 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --_004_051CC8AC48CA52479811BF267278633A1323BB23LLE2K10MBX01mit_-- From nobody Tue Apr 21 09:52:39 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699BC1A005A for ; Tue, 21 Apr 2015 09:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9e9gNCAonTP0 for ; Tue, 21 Apr 2015 09:52:27 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id DB3C61AD2A4 for ; Tue, 21 Apr 2015 09:51:56 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,617,1422939600"; d="jpg'145?scan'145,208,217,145";a="6891596" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport2.idirect.net with ESMTP; 21 Apr 2015 12:51:56 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 21 Apr 2015 12:51:54 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Tue, 21 Apr 2015 12:51:54 -0400 From: "Ratliff, Stanley" To: "Wiggins, David - 0665 - MITLL" , "manet@ietf.org" Thread-Topic: DLEP-09 Last Call issue Thread-Index: AdB8PJ33ex26dcY6Rl+Hyitow1TE3QAFPsCwAABqZNA= Date: Tue, 21 Apr 2015 16:51:54 +0000 Message-ID: <7a7b8cf4c7744589aa0967970b9d7211@VAUSDITCHM2.idirect.net> References: <051CC8AC48CA52479811BF267278633A1323BB23@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <051CC8AC48CA52479811BF267278633A1323BB23@LLE2K10-MBX01.mitll.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/related; boundary="_004_7a7b8cf4c7744589aa0967970b9d7211VAUSDITCHM2idirectnet_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP-09 Last Call issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 16:52:37 -0000 --_004_7a7b8cf4c7744589aa0967970b9d7211VAUSDITCHM2idirectnet_ Content-Type: multipart/alternative; boundary="_000_7a7b8cf4c7744589aa0967970b9d7211VAUSDITCHM2idirectnet_" --_000_7a7b8cf4c7744589aa0967970b9d7211VAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, I'm OK with doing it that way as well. Are there other opinions out there? Send 'em if you got 'em - I'd like to c= lose on this. Regards, Stan From: Wiggins, David - 0665 - MITLL [mailto:David.Wiggins@ll.mit.edu] Sent: Tuesday, April 21, 2015 12:45 PM To: Ratliff, Stanley; manet@ietf.org Subject: RE: DLEP-09 Last Call issue Several other signals that expect ACKs have words like: "The sender of the = Destination Up signal is free to define its retry heuristics in event of a = timeout." I see that Peer Initialization does not say this, but perhaps it= should. Wouldn't that fix the problem, and be more in line with the rest = of the draft? David From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ratliff, Stanley Sent: Tuesday, April 21, 2015 10:14 AM To: manet@ietf.org Subject: [manet] DLEP-09 Last Call issue Working Group Participants, It was noted during a private discussion that there could be an issue with = DLEP and Heartbeats. Specifically, the scenario mentioned was: 1. Peer Discovery/Peer Offer processing takes place with no errors or= issues. 2. Router uses information received from Peer Offer, and connects a s= ocket to the modem. Router sends Peer Initialization, with a Heartbeat TLV. 3. Modem, for whatever reason, *fails* to respond to Peer Initializat= ion. The question/issue is that Heartbeats (if used at all) aren't fully establi= shed at that point, since they require the Peer Initialization/Peer Initial= ization ACK sequence. So what to do? Here is the proposed fix - the following text will be inserted into the Pee= r Initialization section: "It should be noted that Heartbeats (if used) are not fully established unt= il both the Peer Initialization and Peer Initialization ACK messages have b= een sent and successfully processed by the appropriate recipient. This leav= es the possibility for timing issues to occur (e.g. a Peer Initialization m= essage is sent from router to modem, but no Peer Initialization ACK is rece= ived). Prior to the establishment of the Heartbeat interval, heuristics for= determining the amount of time to wait for a specific message, or to decla= re the session inoperative, are left to implementers. However, it is recomm= ended that an implementation select some reasonable multiple of its own pro= posed Heartbeat interval in these cases, in order to minimize the number of= inputs to the implementation." Other opinions are welcome. Regards, Stan ________________________________ Stan Ratliff | Architect, Applied Research VT iDirect | 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, US= A T: +1 703 544-8520 | F: +1 222 123-4567 sratliff@idirect.net | www.idirect.net Connect with iDirect: Twitter.com/iDirect | = Facebook.com/iDirect [cid:image001.jpg@01D07C31.F0F2A560] Advancing a Connected World --_000_7a7b8cf4c7744589aa0967970b9d7211VAUSDITCHM2idirectnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David,

 

I’m OK with doin= g it that way as well.

 

Are there other opinio= ns out there? Send ‘em if you got ‘em – I’d like to= close on this.

 

Regards,

Stan=

 

 

From: Wiggins, David - 0665 - MITLL [mailto:D= avid.Wiggins@ll.mit.edu]
Sent: Tuesday, April 21, 2015 12:45 PM
To: Ratliff, Stanley; manet@ietf.org
Subject: RE: DLEP-09 Last Call issue

 

Several other signals that expect ACKs have words like: “The se=
nder of the Destination Up signal is free to define its retry heuristics in=
 event of a timeout.”  I see that Peer Initialization does not s=
ay this, but perhaps it should.  Wouldn’t that fix the problem, =
and be more in line with the rest of the draft?
 
David

 

 

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Ratliff, Stanley
Sent: Tuesday, April 21, 2015 10:14 AM
To: manet@ietf.org
Subject: [manet] DLEP-09 Last Call issue

 

Working Group Participants,

 

It was noted during a private discussion that there = could be an issue with DLEP and Heartbeats. Specifically, the scenario ment= ioned was:

 

1.  = ;     Peer Discovery/Peer Offer processing takes place with no errors or i= ssues.

2.  = ;     Router uses information received from Peer Offer, and connects a soc= ket to the modem. Router sends Peer Initialization, with a Heartbeat TLV.

3.  = ;     Modem, for whatever reason, *fails* to respond to Peer Initia= lization.

 

The question/issue is that Heartbeats (if used at al= l) aren’t fully established at that point, since they require the Pee= r Initialization/Peer Initialization ACK sequence. So what to do?

 

Here is the proposed fix – the following text = will be inserted into the Peer Initialization section:

 

"It should be noted that Heartbeats (if used) a= re not fully established until both the Peer Initialization and Peer Initia= lization ACK messages have been sent and successfully processed by the appr= opriate recipient. This leaves the possibility for timing issues to occur (e.g. a Peer Initialization message is sent fro= m router to modem, but no Peer Initialization ACK is received). Prior to th= e establishment of the Heartbeat interval, heuristics for determining the a= mount of time to wait for a specific message, or to declare the session inoperative, are left to implementers. = However, it is recommended that an implementation select some reasonable mu= ltiple of its own proposed Heartbeat interval in these cases, in order to m= inimize the number of inputs to the implementation."

 

 

Other opinions are welcome.

 

Regards,

Stan

Stan Ratliff  |  Architect, Applied Research<= /span>

VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Hernd= on, VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 123-4567

sratliff@i= direct.net  |  www.idirect.net

Connect with iDirect: Twitter.com/iDi= rect  |  Facebook.com/i= Direct

 

<= /p>

Advancing a Connected World

 <= /span>

 

--_000_7a7b8cf4c7744589aa0967970b9d7211VAUSDITCHM2idirectnet_-- --_004_7a7b8cf4c7744589aa0967970b9d7211VAUSDITCHM2idirectnet_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3003; creation-date="Tue, 21 Apr 2015 16:51:53 GMT"; modification-date="Tue, 21 Apr 2015 16:51:53 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --_004_7a7b8cf4c7744589aa0967970b9d7211VAUSDITCHM2idirectnet_-- From nobody Tue Apr 21 10:45:46 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6161A871E for ; Tue, 21 Apr 2015 10:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 DvMRopvZAYDc for ; Tue, 21 Apr 2015 10:45:43 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 94B441A8703 for ; Tue, 21 Apr 2015 10:45:43 -0700 (PDT) Received: by widdi4 with SMTP id di4so30374147wid.0 for ; Tue, 21 Apr 2015 10:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=TMLiHpzXesPWTMFRJr5g91n1bxFffmihl3Azwa6QTME=; b=NX1NkEJDBIaNRn/T/Uw7vEgPrpUxWJexKsdlz+eINdIlY4vvf6S/tatzyuyKdwm0B5 EHomF9iy0PsWVSI6H7v2bRTIjxKmk0eju/fGMj6RLnCLVfSmQUiGt8tqalcmRARDwak7 3zq7Me9x/e/e5djBUIBGjBlPFiXUcHskxMAssZPDqEB5Xh2QR6er1gJq4AD8WpzMVuht eBg2syG5reBEVK9VsshpHMofFT1w6rxHsUuUegeQ4IbpvUCv08O7dxwy+Vi+UiaLo70a EDqWVcUYJoX9tG1760HZ23qWDmPrrgoH+l8YwHcHTu309jttKqJORYKyzuFXTZ301T7e Z+MQ== X-Received: by 10.180.94.100 with SMTP id db4mr37249496wib.26.1429638342227; Tue, 21 Apr 2015 10:45:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Tue, 21 Apr 2015 10:45:21 -0700 (PDT) In-Reply-To: <051CC8AC48CA52479811BF267278633A1323BB23@LLE2K10-MBX01.mitll.ad.local> References: <051CC8AC48CA52479811BF267278633A1323BB23@LLE2K10-MBX01.mitll.ad.local> From: Henning Rogge Date: Tue, 21 Apr 2015 19:45:21 +0200 Message-ID: To: "Wiggins, David - 0665 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-09 Last Call issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 17:45:45 -0000 On Tue, Apr 21, 2015 at 6:45 PM, Wiggins, David - 0665 - MITLL wrote: > > Several other signals that expect ACKs have words like: =E2=80=9CThe send= er of the Destination Up signal is free to define its retry heuristics in e= vent of a timeout.=E2=80=9D I see that Peer Initialization does not say th= is, but perhaps it should. Wouldn=E2=80=99t that fix the problem, and be m= ore in line with the rest of the draft? I think the Peer Discovery/Peer Offer case is even more important because they are not protected by the Heartbeat. For every other signal if the implementation misses to send the ACK (or the ACK is lost) the protocol will still work somehow or it will be resetted by a missing Heartbeat. If the TCP session is activated but one of the Peer Signals get lost or is not handled correctly, DLEP will just do nothing until the TCP timeout will save you... which might take a couple of minutes. If your DLEP radio or router does only allow a single connection at the same time, all you could do is to reset both devices. So I think the longer text Stan suggested is better for this case. Henning Rogge From nobody Tue Apr 21 12:19:12 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02ED61B2A6D; Tue, 21 Apr 2015 12:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 uYnnVIkq45ZX; Tue, 21 Apr 2015 12:19:07 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6781D1B2A6F; Tue, 21 Apr 2015 12:19:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=F58CKRIoQwqen38LtXlfrAVVAD4dExB2D7tt8ivS9aWb4+wuXjK5U84VGftbkdyY; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1YkdhJ-0006NB-EB; Tue, 21 Apr 2015 15:19:05 -0400 Received: from 76.254.54.242 by webmail.earthlink.net with HTTP; Tue, 21 Apr 2015 15:19:05 -0400 Message-ID: <21091172.1429643945433.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Date: Tue, 21 Apr 2015 12:19:05 -0700 (GMT-07:00) From: Randy Presuhn To: Benoit Claise , manet@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b65b6112f89115379af53944a38a708884189f6b645529d7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.33 Archived-At: Cc: mib-doctors@ietf.org, disman@ietf.org Subject: Re: [manet] [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 19:19:09 -0000 Hi - >From: Benoit Claise >Sent: Apr 21, 2015 1:07 AM >To: Randy Presuhn , manet@ietf.org >Cc: disman@ietf.org, mib-doctors@ietf.org >Subject: Re: [MIB-DOCTORS] comments on draft-ietf-manet-report-mib-04 ... >This is inappropriate to ask for a MIB doctor review for a MIB module >that doesn't even compile. ... I wrote: >> This is *not* a full MIB doctor review; in my opinion some ... Sorry if that misled anyone. The reasons I CC-ed the mib-doctors@ietf.org list as well as the disman@ietf.org list were: 1) to let folks outside of manet@ietf.org know that *someone* had looked at this 2) to make sure that no one had a problem with my suggestions regarding how the work could fit in with disman infrastructure and accepted MIB practice. I think the timestamping issues in particular are of general concern, so if there is consensus among practitioners regarding the best way to deal with those issues beyond what we did with the Log MIB (the nlmLogTime and nlmLogDateAndTime hack) it would be good to be able to make a specific recommendation to the manet folk. That would be a lot more helpful than my comments, which amount to "this is busted." Kinda tangentially... (3) Given the current emphasis on Netconf, and this module is primarily about configuring functionality, is anyone prepared to argue that this MIB module should instead be a Yang module and managed via Netconf protocol? I think it would be a terrible fit, but that's not my problem. Randy From nobody Tue Apr 21 23:45:10 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745B21B31DF; Tue, 21 Apr 2015 23:45:09 -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 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 rRQaUI-vLPLY; Tue, 21 Apr 2015 23:45:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DE11B31F3; Tue, 21 Apr 2015 23:45:06 -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.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422064506.15307.76274.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 23:45:06 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 06:45:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Packet Sequence Number based directional airtime metric for OLSRv2 Authors : Henning Rogge Emmanuel Baccelli Filename : draft-ietf-manet-olsrv2-dat-metric-05.txt Pages : 17 Date : 2015-04-21 Abstract: This document specifies an directional airtime link metric for usage in OLSRv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-dat-metric/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-manet-olsrv2-dat-metric-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-dat-metric-05 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 Apr 21 23:48:43 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5584F1B3201 for ; Tue, 21 Apr 2015 23:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 aSHDpwTXVbSu for ; Tue, 21 Apr 2015 23:48:36 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 62ACE1B31FD for ; Tue, 21 Apr 2015 23:48:36 -0700 (PDT) Received: by wiun10 with SMTP id n10so45717270wiu.1 for ; Tue, 21 Apr 2015 23:48:35 -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-type; bh=yyttZdbyOOM0nT8WsLR7swpsNUEKOd+bk14T24VU0vo=; b=sT3DBhCL2S7/9E0d9D4ZfysBkCmE5TNUVdNO7086mKnwAVoPdBwyDQwwAy0CTcwARe aEnM1bNR9SY0qnAulOTmf4L4N+iWjYNVm6z11faBfkgbsI/QOGlpJBZK2c1ysLs2IgMp DO3vRsWwSkd6bf8sbF0iqXjg7i+gI5hG3Bxb04iJcaLFIGM17z5em8DukVvNwkm73BA5 a3d7rINZAGAeZv1seJDPCGufOah3I5feVPZgwzBrlutg6YH5O8tRXwhn+wtsXETXhsrY L7J0AXNjFcODoIuYoxuAlwMoyiDWD4+BAGBpg21mPY83U6mgSgeydzdLLxa6LTkFZr4B HvlQ== X-Received: by 10.181.29.36 with SMTP id jt4mr2988987wid.21.1429685315171; Tue, 21 Apr 2015 23:48:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Tue, 21 Apr 2015 23:48:14 -0700 (PDT) In-Reply-To: <20150422064506.15307.76274.idtracker@ietfa.amsl.com> References: <20150422064506.15307.76274.idtracker@ietfa.amsl.com> From: Henning Rogge Date: Wed, 22 Apr 2015 08:48:14 +0200 Message-ID: To: MANET IETF Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Fabian Nack Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 06:48:40 -0000 On Wed, Apr 22, 2015 at 8:45 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. > > Title : Packet Sequence Number based directional airtime metric for OLSRv2 > Authors : Henning Rogge > Emmanuel Baccelli > Filename : draft-ietf-manet-olsrv2-dat-metric-05.txt > Pages : 17 > Date : 2015-04-21 Hi, I posted a last revision of the DAT metric draft based on a review I got from Fabian Nack. The change is small, I renamed two variables to make their usage more clear and fixed a mixup between two variable names in the metric update. I think DAT should be ready for last call... Henning Rogge From nobody Wed Apr 22 02:25:24 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD341B3361 for ; Wed, 22 Apr 2015 02:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 0hyN9ErncuFM for ; Wed, 22 Apr 2015 02:25:21 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 D8A2D1B335A for ; Wed, 22 Apr 2015 02:25:20 -0700 (PDT) Received: by wizk4 with SMTP id k4so170125556wiz.1 for ; Wed, 22 Apr 2015 02:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=P2eIJjPcOMsDP8h++0eQtAoX53LbwWquKwMqrb8r5ts=; b=UB7r2CxmH2YvoWFx5cPwhrWZXdz4YKfqb9PBKbiVXUxuShCF2UYyJvBC/1KvA8q3rf zP6gaKroHNdwm4hfQT4fzxRSfJQwcFHNuC4B/lOy/vVfyIWOpFF1trXqyWjUOalEcfOY jZMMJnJ8ess4wcuKLjX1GSCLoTv0Q7Enj3HfCNFFlJWHNkuYl+JsCHYNFL3Ufi0UuT7R BYBdX6rn0vLfm3SPlpMDkT76ZVyzCTTGRBnHFyK2pMBY5su+rwvZI18tzfwcFX1XcNAj BUnm22wKWnJ6LoyhsNL6M42MqnYf8WbqMjCotR29/AnPMqFJzLPNXr0ymJIWQs6KXsMJ HAIg== X-Received: by 10.194.57.209 with SMTP id k17mr31242356wjq.33.1429694719023; Wed, 22 Apr 2015 02:25:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Wed, 22 Apr 2015 02:24:58 -0700 (PDT) From: Henning Rogge Date: Wed, 22 Apr 2015 11:24:58 +0200 Message-ID: To: MANET IETF Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [manet] RFC5444 best practice "cheat sheet" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 09:25:22 -0000 Hi, I know that people on this ML have planned to write a draft about this topic for some time, but after answering a lot of questions about do/don't for RFC5444 I put together a short list of things I think as "best practices" for using RFC5444. https://docs.google.com/document/d/13Oki2GGrExT6KULv-kTfU7XPwGsXF1Xs6qn1jkl8QrQ/edit?usp=sharing I don't plan to extend this into a RFC at the moment. Henning Rogge From nobody Wed Apr 22 03:15:41 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2836F1A1A60 for ; Wed, 22 Apr 2015 03:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 T9DBiTM3OYCQ for ; Wed, 22 Apr 2015 03:15:38 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 555881B33BD for ; Wed, 22 Apr 2015 03:15:35 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so176217983lbb.0 for ; Wed, 22 Apr 2015 03:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yzNCY+FjP14iXMdqxLDUOccfAI5xsWwOKzuAnChEerY=; b=SPv/toNHwthXzFamy+9sY/++9htWDbFg9P+2oJ2tbThZMYS5KJcbzNtVXnySIJOvkt znopaO8L4mKd2kvNkrYQpPHF0Fkls0z0DUo2pZBpf0k0MI8C+dzIzkTCj+KZMtFFBdV4 q8YzViiuAOXIMmwhYmqAzh8PM0jPrN5HUKENrr3YCQC1F0nCo6F1SzMxTn3FKKmic51/ l9Y8Gnu0nISkyg8FzQWeYRUnF8l+UL6+VefRf8f2GrhAdQ11yz7P4LD2tCzCOan5nmhl cEy+WCkJQNP2hCKau7XCcE4Vqf1LKFLk4L6Qz4TFAvGECHKSplRFe7vo7f/p2eoQzLuM B4Ow== MIME-Version: 1.0 X-Received: by 10.112.146.97 with SMTP id tb1mr24408862lbb.12.1429697733715; Wed, 22 Apr 2015 03:15:33 -0700 (PDT) Received: by 10.112.252.4 with HTTP; Wed, 22 Apr 2015 03:15:33 -0700 (PDT) In-Reply-To: <7a7b8cf4c7744589aa0967970b9d7211@VAUSDITCHM2.idirect.net> References: <051CC8AC48CA52479811BF267278633A1323BB23@LLE2K10-MBX01.mitll.ad.local> <7a7b8cf4c7744589aa0967970b9d7211@VAUSDITCHM2.idirect.net> Date: Wed, 22 Apr 2015 11:15:33 +0100 Message-ID: From: Victoria Mercieca To: "Ratliff, Stanley" , manet@ietf.org Content-Type: multipart/related; boundary=047d7b3a85a08e01d605144d7177 Archived-At: Subject: Re: [manet] DLEP-09 Last Call issue X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 10:15:40 -0000 --047d7b3a85a08e01d605144d7177 Content-Type: multipart/alternative; boundary=047d7b3a85a08e01d305144d7176 --047d7b3a85a08e01d305144d7176 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stan, hi all, >From Section 4.3 and 4.5, it's pretty clear that heartbeats begin to flow _after_ a Peer Initialization ACK is received with a success status code, so no heartbeat-related timers would be started on the router until the Peer Initialization ACK is received. However, the modem receiving the Peer Initialization would start up the heartbeat timer when it sends the Peer Initialization ACK. In case the ACK was lost, the router should have some timeout behaviour on the Peer Initialization, like David Wiggins says. I think your suggested text effectively says this but in a much more complicated way? Also, if the router is not "in-session", because no Peer Initialization ACK was received, would the router respond to any other signals from the modem (including Heartbeat) with a Peer Termination anyway? You mention earlier in section 4.4 that any other signals received when expecting the Peer Offer would be silently dropped, but you dont have a similar comment for the Initialization signals. Sending a Peer Termination would fit with the other comments in the document that any unexpected/invalid signal should cause a termination, and you have a status code for this too. So the problem would be resolved by Peer Termination when any other signal is received from the modem. Alternatively, but I suppose the delay is undesirable, the modem will terminate the session after 2 of its own heartbeat intervals anyway, since the router will not send any DLEP signals while waiting for the Peer Initialization ACK. Kind regards, Victoria. On Tue, Apr 21, 2015 at 5:51 PM, Ratliff, Stanley wrote: > David, > > > > I=E2=80=99m OK with doing it that way as well. > > > > Are there other opinions out there? Send =E2=80=98em if you got =E2=80=98= em =E2=80=93 I=E2=80=99d like to > close on this. > > > > Regards, > > Stan > > > > > > *From:* Wiggins, David - 0665 - MITLL [mailto:David.Wiggins@ll.mit.edu] > *Sent:* Tuesday, April 21, 2015 12:45 PM > *To:* Ratliff, Stanley; manet@ietf.org > *Subject:* RE: DLEP-09 Last Call issue > > > > Several other signals that expect ACKs have words like: =E2=80=9CThe send= er of the Destination Up signal is free to define its retry heuristics in e= vent of a timeout.=E2=80=9D I see that Peer Initialization does not say th= is, but perhaps it should. Wouldn=E2=80=99t that fix the problem, and be m= ore in line with the rest of the draft? > > > > David > > > > > > *From:* manet [mailto:manet-bounces@ietf.org ] *O= n > Behalf Of *Ratliff, Stanley > *Sent:* Tuesday, April 21, 2015 10:14 AM > *To:* manet@ietf.org > *Subject:* [manet] DLEP-09 Last Call issue > > > > Working Group Participants, > > > > It was noted during a private discussion that there could be an issue wit= h > DLEP and Heartbeats. Specifically, the scenario mentioned was: > > > > 1. Peer Discovery/Peer Offer processing takes place with no errors > or issues. > > 2. Router uses information received from Peer Offer, and connects a > socket to the modem. Router sends Peer Initialization, with a Heartbeat T= LV. > > 3. Modem, for whatever reason, **fails** to respond to Peer > Initialization. > > > > The question/issue is that Heartbeats (if used at all) aren=E2=80=99t ful= ly > established at that point, since they require the Peer Initialization/Pee= r > Initialization ACK sequence. So what to do? > > > > Here is the proposed fix =E2=80=93 the following text will be inserted in= to the > Peer Initialization section: > > > > "It should be noted that Heartbeats (if used) are not fully established > until both the Peer Initialization and Peer Initialization ACK messages > have been sent and successfully processed by the appropriate recipient. > This leaves the possibility for timing issues to occur (e.g. a Peer > Initialization message is sent from router to modem, but no Peer > Initialization ACK is received). Prior to the establishment of the > Heartbeat interval, heuristics for determining the amount of time to wait > for a specific message, or to declare the session inoperative, are left t= o > implementers. However, it is recommended that an implementation select so= me > reasonable multiple of its own proposed Heartbeat interval in these cases= , > in order to minimize the number of inputs to the implementation." > > > > > > Other opinions are welcome. > > > > Regards, > > Stan > ------------------------------ > > *Stan Ratliff *| Architect, Applied Research > > *VT iDirect *| 13861 Sunrise Valley Drive, Suite 300, Herndon, VA > 20171, USA > > T: +1 703 544-8520 | F: +1 222 123-4567 > > sratliff@idirect.net | www.idirect.net > > *Connect with iDirect: *Twitter.com/iDirect > | Facebook.com/iDirect > > > > *Advancing a Connected World* > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --047d7b3a85a08e01d305144d7176 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --f46d043be09c20f0e20514663580-- From nobody Thu Apr 23 09:44:47 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8F51AC3D7 for ; Thu, 23 Apr 2015 09:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 aHdeNVpAkdr7 for ; Thu, 23 Apr 2015 09:44:43 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 188521A8AB8 for ; Thu, 23 Apr 2015 09:44:43 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,632,1422939600"; d="scan'208,217";a="6921577" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport2.idirect.net with ESMTP; 23 Apr 2015 12:44:42 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 23 Apr 2015 12:44:41 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Thu, 23 Apr 2015 12:44:41 -0400 From: "Ratliff, Stanley" To: "James A. (Jim) Stevens" , "manet@ietf.org" Thread-Topic: [manet] DLEP versus PPPoE Thread-Index: AQHQfeIqTUpiK/XB/U6Gu2DdLj2hDZ1azFbw Date: Thu, 23 Apr 2015 16:44:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/alternative; boundary="_000_ba9336ef76014476b47054c2e3d9c9a4VAUSDITCHM2idirectnet_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 16:44:46 -0000 --_000_ba9336ef76014476b47054c2e3d9c9a4VAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmltLA0KDQpSRkM1NTc4IGlzIGFuIOKAnEluZm9ybWF0aW9uYWzigJ0gUkZDLiBUaGUgcGxhbiBh bGwgYWxvbmcgaGFzIGJlZW4gZm9yIERMRVAgdG8gYmUgYSDigJxTdGFuZGFyZHMgVHJhY2vigJ0g UkZDLiBJZiBzb21lb25lIGltcGxlbWVudHMgdGhlIG9wdGlvbmFsIGNyZWRpdCB3aW5kb3dpbmcg dGhhdCBpcyBpbiB0aGUgc3BlYywgSSB3b3VsZCBjb250ZW5kIHRoYXQgRExFUCBoYXMgYSBzdXBl cnNldCBvZiB0aGUgZmVhdHVyZXMgaW4gUkZDNTU3OC4gV2hlbiB2aWV3ZWQgaW4gdGhhdCBsaWdo dCAoYm90aCB0aGUgZmVhdHVyZS9mdW5jdGlvbiBzZXQsIGFuZCBpbiBJbmZvcm1hdGlvbmFsIHZz LiBTdGFuZGFyZHMgVHJhY2spLCBJIHdvdWxkIGFzc3VtZSB0aGF0IERMRVAgd291bGQsIGluZGVl ZCwgYmUgc2VlbiBhcyB0aGUg4oCccHJlZmVycmVk4oCdIHByb3RvY29sLiBIYXZpbmcgc2FpZCB0 aGF0LCB0aGUgaW1wbGVtZW50YXRpb24gaXMgYWx3YXlzIHVwIHRvIHRoZSBpbXBsZW1lbnRlciwg YW5kIGlmIGNpcmN1bXN0YW5jZXMgZGljdGF0ZSBhIFBQUG9FLWJhc2VkIGFwcHJvYWNoLCB0aGVu IFJGQzU1NzggaXMgc3RpbGwgYW4gYXBwcm9hY2guDQoNClJlZ2FyZHMsDQpTdGFuDQoNCg0KRnJv bTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFt ZXMgQS4gKEppbSkgU3RldmVucw0KU2VudDogVGh1cnNkYXksIEFwcmlsIDIzLCAyMDE1IDExOjQ4 IEFNDQpUbzogbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFttYW5ldF0gRExFUCB2ZXJzdXMgUFBQ b0UNCg0KU3RhbiwNCg0KSSB1bmRlcnN0YW5kIHlvdXIgYW5zd2VyLCBidXQgSSBwcmVzdW1lIHRo YXQgRGVlcGFrIExhbCB3YXMgYXNraW5nIGFib3V0IHdoYXQgaXMgdGhlIGJlc3QvcmVjb21tZW5k ZWQgcHJvdG9jb2wgdG8gdXNlIGZvciByYWRpbyB0byByb3V0ZXIuIChNeSBhc3N1bXB0aW9uIGlz IHdoeSBpbXBsZW1lbnQgUFBQb0Ugb3RoZXJ3aXNlLikNCg0KSSB3b3VsZCBoYXZlIGV4cGVjdGVk IHlvdSB0byBzYXkgdGhhdCB0aGUgaWV0ZiBtYW5ldCB3b3JraW5nIGdyb3VwIHJlY29tbWVuZHMg RExFUCBhcyB0aGUgcHJlZmVycmVkIHJhZGlvIHRvIHJvdXRlciBwcm90b2NvbCAob3Igd2lsbCBy ZWNvbW1lbmQgdGhhdCBvbmNlIERMRVAgYmVjb21lcyBhbiBSRkMpLg0KDQpEbyB5b3UgYWdyZWU/ ICBkaXNhZ3JlZT8NCg0KSmltDQoNCkRhdGU6IFRodSwgMjMgQXByIDIwMTUgMTU6MTk6MTMgKzAw MDANCkZyb206ICJSYXRsaWZmLCBTdGFubGV5IiA8c3JhdGxpZmZAaWRpcmVjdC5uZXQ8bWFpbHRv OnNyYXRsaWZmQGlkaXJlY3QubmV0Pj4NClRvOiAiTGFsLCBEZWVwYWsgKE1UTCkiIDxEZWVwYWsu TGFsQFVsdHJhLVRDUy5jb208bWFpbHRvOkRlZXBhay5MYWxAVWx0cmEtVENTLmNvbT4+LCAibWFu ZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPiINCiAgICAgICAgPG1hbmV0QGlldGYu b3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW21hbmV0XSBSZXF1aXJl IGNsYXJpZmljYXRpb24oZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLTA5IHZzDQogICAgICAgIFJGQyA0 OTM4L1JGQzU1NzgpDQpNZXNzYWdlLUlEOiA8N2M0MjIxZDc1OTY1NGNjY2E0MDE0ODEyZGRjYzc3 N2JAVkFVU0RJVENITTIuaWRpcmVjdC5uZXQ8bWFpbHRvOjdjNDIyMWQ3NTk2NTRjY2NhNDAxNDgx MmRkY2M3NzdiQFZBVVNESVRDSE0yLmlkaXJlY3QubmV0Pj4NCg0KRGVlcGFrLA0KDQpETEVQIGRv ZXNuJ3Qgc3VwZXJzZWRlIFJGQzU1NzguIFJGQzU1NzggaXMgZm9yIFBQUG9FLWJhc2VkIGNvbm5l Y3Rpb25zIGJldHdlZW4gcm91dGVyIGFuZCByYWRpby4gRExFUCBzcGVjaWZpZXMgYSBUQ1AtYmFz ZWQgY29ubmVjdGlvbiwgd2l0aCBVRFAgdXNlZCBmb3IgZGlzY292ZXJ5LiBBbmQgSSBiZWxpZXZl IHRoZSBDcmVkaXQgZmxvd3MgKmFyZSogZG9jdW1lbnRlZCBpbiBETEVQLCBhcyBhbiBleHRlbnNp b24uDQoNClJlZ2FyZHMsDQpTdGFuDQoNCkZyb206IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBM YWwsIERlZXBhayAoTVRMKQ0KU2VudDogVGh1cnNkYXksIEFwcmlsIDIzLCAyMDE1IDEwOjQ5IEFN DQpUbzogbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KU3ViamVjdDogW21h bmV0XSBSZXF1aXJlIGNsYXJpZmljYXRpb24oZHJhZnQtaWV0Zi1tYW5ldC1kbGVwLTA5IHZzIFJG QyA0OTM4L1JGQzU1NzgpDQoNCkkgYW0gbm90IGNsZWFyIGFib3V0IHRoZSBkaXN0aW5jdGlvbi4g RG9lcyBNQU5FVC1ETEVQLTA5IHN1cGVyc2VkZSB0aGUgUFBQb0UgYmFzZWQgUkZDNDkzOC9SRkM1 NTc4IGltcGxlbWVudGF0aW9ucz8NClRoZXJlIGlzIG5vIG1lbnRpb24gb2YgQ3JlZGl0IEZsb3dz LCBldGMuIG9uIE1BTkVULURMRVAtMDkuDQoNClRoYW5rIHlvdQ0KLS0NCkphbWVzIEEuIChKaW0p IFN0ZXZlbnMsIFBoRA0KTmV0d29yayBBcmNoaXRlY3QgLyBUZWNobmljYWwgRmVsbG93DQpSb2Nr d2VsbCBDb2xsaW5zIEdvdmVybm1lbnQgU3lzdGVtcw0KamFtZXMuYS5zdGV2ZW5zQHJvY2t3ZWxs Y29sbGlucy5jb208bWFpbHRvOmphbWVzLmEuc3RldmVuc0Byb2Nrd2VsbGNvbGxpbnMuY29tPg0K OTcyLTcwNS0zNDc1IChvZmZpY2UpDQoyMTQtMzkyLTIyNzMgKGNlbGwpDQo= --_000_ba9336ef76014476b47054c2e3d9c9a4VAUSDITCHM2idirectnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkppbSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UkZDNTU3OCBpcyBhbiDigJxJbmZvcm1hdGlvbmFs4oCd IFJGQy4gVGhlIHBsYW4gYWxsIGFsb25nIGhhcyBiZWVuIGZvciBETEVQIHRvIGJlIGEg4oCcU3Rh bmRhcmRzIFRyYWNr4oCdIFJGQy4gSWYgc29tZW9uZSBpbXBsZW1lbnRzIHRoZSBvcHRpb25hbCBj cmVkaXQgd2luZG93aW5nIHRoYXQNCiBpcyBpbiB0aGUgc3BlYywgSSB3b3VsZCBjb250ZW5kIHRo YXQgRExFUCBoYXMgYSBzdXBlcnNldCBvZiB0aGUgZmVhdHVyZXMgaW4gUkZDNTU3OC4gV2hlbiB2 aWV3ZWQgaW4gdGhhdCBsaWdodCAoYm90aCB0aGUgZmVhdHVyZS9mdW5jdGlvbiBzZXQsIGFuZCBp biBJbmZvcm1hdGlvbmFsIHZzLiBTdGFuZGFyZHMgVHJhY2spLCBJIHdvdWxkIGFzc3VtZSB0aGF0 IERMRVAgd291bGQsIGluZGVlZCwgYmUgc2VlbiBhcyB0aGUg4oCccHJlZmVycmVk4oCdIHByb3Rv Y29sLg0KIEhhdmluZyBzYWlkIHRoYXQsIHRoZSBpbXBsZW1lbnRhdGlvbiBpcyBhbHdheXMgdXAg dG8gdGhlIGltcGxlbWVudGVyLCBhbmQgaWYgY2lyY3Vtc3RhbmNlcyBkaWN0YXRlIGEgUFBQb0Ut YmFzZWQgYXBwcm9hY2gsIHRoZW4gUkZDNTU3OCBpcyBzdGlsbCBhbiBhcHByb2FjaC4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8YnI+DQpTdGFu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG1hbmV0IFttYWlsdG86bWFuZXQt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFtZXMgQS4gKEppbSkgU3Rl dmVuczxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMTUgMTE6NDggQU08 YnI+DQo8Yj5Ubzo8L2I+IG1hbmV0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFttYW5l dF0gRExFUCB2ZXJzdXMgUFBQb0U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U3Rhbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgdW5kZXJzdGFuZCB5b3VyIGFuc3dlciwgYnV0IEkgcHJlc3VtZSB0aGF0 IERlZXBhayBMYWwgd2FzIGFza2luZyBhYm91dCB3aGF0IGlzIHRoZSBiZXN0L3JlY29tbWVuZGVk IHByb3RvY29sIHRvIHVzZSBmb3IgcmFkaW8gdG8gcm91dGVyLiAoTXkgYXNzdW1wdGlvbiBpcyB3 aHkgaW1wbGVtZW50IFBQUG9FIG90aGVyd2lzZS4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgaGF2ZSBleHBlY3RlZCB5b3UgdG8g c2F5IHRoYXQgdGhlIGlldGYgbWFuZXQgd29ya2luZyBncm91cCByZWNvbW1lbmRzIERMRVAgYXMg dGhlIHByZWZlcnJlZCByYWRpbyB0byByb3V0ZXIgcHJvdG9jb2wgKG9yIHdpbGwgcmVjb21tZW5k IHRoYXQgb25jZSBETEVQIGJlY29tZXMgYW4gUkZDKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8geW91IGFncmVlPyAmbmJzcDtkaXNhZ3Jl ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SmltPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ RGF0ZTogVGh1LCAyMyBBcHIgMjAxNSAxNToxOToxMyAmIzQzOzAwMDA8YnI+DQpGcm9tOiAmcXVv dDtSYXRsaWZmLCBTdGFubGV5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3JhdGxpZmZAaWRp cmVjdC5uZXQiPnNyYXRsaWZmQGlkaXJlY3QubmV0PC9hPiZndDs8YnI+DQpUbzogJnF1b3Q7TGFs LCBEZWVwYWsgKE1UTCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpEZWVwYWsuTGFsQFVsdHJh LVRDUy5jb20iPkRlZXBhay5MYWxAVWx0cmEtVENTLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVm PSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPiZxdW90Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYu b3JnIj5tYW5ldEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFttYW5ldF0gUmVx dWlyZSBjbGFyaWZpY2F0aW9uKGRyYWZ0LWlldGYtbWFuZXQtZGxlcC0wOSB2czxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSRkMgNDkzOC9SRkM1NTc4KTxicj4NCk1lc3NhZ2UtSUQ6 ICZsdDs8YSBocmVmPSJtYWlsdG86N2M0MjIxZDc1OTY1NGNjY2E0MDE0ODEyZGRjYzc3N2JAVkFV U0RJVENITTIuaWRpcmVjdC5uZXQiPjdjNDIyMWQ3NTk2NTRjY2NhNDAxNDgxMmRkY2M3NzdiQFZB VVNESVRDSE0yLmlkaXJlY3QubmV0PC9hPiZndDs8YnI+DQo8YnI+DQpEZWVwYWssPGJyPg0KPGJy Pg0KRExFUCBkb2Vzbid0IHN1cGVyc2VkZSBSRkM1NTc4LiBSRkM1NTc4IGlzIGZvciBQUFBvRS1i YXNlZCBjb25uZWN0aW9ucyBiZXR3ZWVuIHJvdXRlciBhbmQgcmFkaW8uIERMRVAgc3BlY2lmaWVz IGEgVENQLWJhc2VkIGNvbm5lY3Rpb24sIHdpdGggVURQIHVzZWQgZm9yIGRpc2NvdmVyeS4gQW5k IEkgYmVsaWV2ZSB0aGUgQ3JlZGl0IGZsb3dzICphcmUqIGRvY3VtZW50ZWQgaW4gRExFUCwgYXMg YW4gZXh0ZW5zaW9uLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KU3Rhbjxicj4NCjxicj4NCkZy b206IG1hbmV0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmci Pm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTGFsLCBEZWVwYWsgKE1U TCk8YnI+DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjMsIDIwMTUgMTA6NDkgQU08YnI+DQpUbzog PGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQpT dWJqZWN0OiBbbWFuZXRdIFJlcXVpcmUgY2xhcmlmaWNhdGlvbihkcmFmdC1pZXRmLW1hbmV0LWRs ZXAtMDkgdnMgUkZDIDQ5MzgvUkZDNTU3OCk8YnI+DQo8YnI+DQpJIGFtIG5vdCBjbGVhciBhYm91 dCB0aGUgZGlzdGluY3Rpb24uIERvZXMgTUFORVQtRExFUC0wOSBzdXBlcnNlZGUgdGhlIFBQUG9F IGJhc2VkIFJGQzQ5MzgvUkZDNTU3OCBpbXBsZW1lbnRhdGlvbnM/PGJyPg0KVGhlcmUgaXMgbm8g bWVudGlvbiBvZiBDcmVkaXQgRmxvd3MsIGV0Yy4gb24gTUFORVQtRExFUC0wOS48YnI+DQo8YnI+ DQpUaGFuayB5b3U8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkphbWVzIEEuIChKaW0pIFN0ZXZlbnMsIFBoRDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5ldHdvcmsgQXJjaGl0ZWN0IC8gVGVjaG5pY2Fs IEZlbGxvdzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Um9ja3dlbGwgQ29sbGlucyBHb3Zlcm5tZW50IFN5c3RlbXM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpqYW1lcy5h LnN0ZXZlbnNAcm9ja3dlbGxjb2xsaW5zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmphbWVzLmEuc3Rl dmVuc0Byb2Nrd2VsbGNvbGxpbnMuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OTcyLTcwNS0zNDc1IChvZmZpY2UpPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMTQtMzkyLTIyNzMgKGNl bGwpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ba9336ef76014476b47054c2e3d9c9a4VAUSDITCHM2idirectnet_-- From nobody Thu Apr 23 09:45:46 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37AF1A9121 for ; Thu, 23 Apr 2015 09:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 e8Fq3702g9sy for ; Thu, 23 Apr 2015 09:45:43 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 A29BD1A92FB for ; Thu, 23 Apr 2015 09:45:37 -0700 (PDT) Received: by wizk4 with SMTP id k4so223166168wiz.1 for ; Thu, 23 Apr 2015 09:45:36 -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-type; bh=5OwYzIoXumApTf1+ljv8ybyPUbOsyOl6H5eVG/c/HsY=; b=tRbDCBA9yAOQlMoVsfDskXyNNXSVqgfjbFpxH2rbYJtAvEPJBCKNs3OnJcG5HtYb4M 2/Rx1FuO5sUPTj+WuB34YMwmAoZkHBR97j/S1mKkUHE7z4q4p3i1bIWfUCV3F24mEoSt NKmYj/drV0iz7lkHMihcnPcFoCj2AfObn5oej8RVSf1C177pbRWRQ7+hFG7Ggs5XHJ7f /d4h8XcEK8r4+tFTCzJcB+hKzo6wJu3ygrMPTdnQdFDqUmJL7gy6WK7f5pnjbFSRPLM7 0vriB8qbOKmbF9MfMAA+bEZn/otOPcXO0Uu1eapdxV81KwZPm6w5Y3q2b/ntuZ1SWVLU xXpg== X-Received: by 10.194.184.45 with SMTP id er13mr7234295wjc.71.1429807536420; Thu, 23 Apr 2015 09:45:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Thu, 23 Apr 2015 09:45:16 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Thu, 23 Apr 2015 18:45:16 +0200 Message-ID: To: "James A. (Jim) Stevens" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 16:45:45 -0000 On Thu, Apr 23, 2015 at 5:48 PM, James A. (Jim) Stevens wrote: > Stan, > > I understand your answer, but I presume that Deepak Lal was asking about > what is the best/recommended protocol to use for radio to router. (My > assumption is why implement PPPoE otherwise.) > > I would have expected you to say that the ietf manet working group > recommends DLEP as the preferred radio to router protocol (or will recommend > that once DLEP becomes an RFC). My personal opinion: PPPoE is only "good" for point-to-point connections... its downright bad if you need multicast/broadcast, especially with wireless radios. There is also the fact that PPPoE with RFC5578 has only a few metrics, and some of them have strange defaults (if you cannot judge the quality of your link, pretend it is perfect). And PPPoE introduce an over-the-air overhead. I would say DLEP is better for connecting radios (or anything with point-to-multipoint) to routers. Henning From nobody Thu Apr 23 10:19:39 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5199A1ACE01 for ; Thu, 23 Apr 2015 10:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 LBew-iX-a9NQ for ; Thu, 23 Apr 2015 10:19:35 -0700 (PDT) Received: from mail.ultra-tcs.com (mx1.ultra-tcs.com [207.253.158.244]) by ietfa.amsl.com (Postfix) with ESMTP id 456151ACE05 for ; Thu, 23 Apr 2015 10:19:13 -0700 (PDT) X-ASG-Debug-ID: 1429809552-03a3c40f4f163790001-Rp4q3q Received: from SRVEXCH1.ultratcs.ca ([172.20.63.185]) by mail.ultra-tcs.com with ESMTP id nHLCWmA7ZO3ldPeX; Thu, 23 Apr 2015 13:19:12 -0400 (EDT) X-Barracuda-Envelope-From: Deepak.Lal@Ultra-TCS.com Received: from SRVEXCH1.ultratcs.ca ([fe80::6de2:32ff:bbe1:4b9a]) by SRVEXCH1.ultratcs.ca ([fe80::6de2:32ff:bbe1:4b9a%10]) with mapi id 14.02.0387.000; Thu, 23 Apr 2015 13:19:09 -0400 From: "Lal, Deepak (MTL)" To: Henning Rogge , "James A. (Jim) Stevens" Thread-Topic: [manet] DLEP versus PPPoE X-ASG-Orig-Subj: RE: [manet] DLEP versus PPPoE Thread-Index: AQHQfeIhY41ARJT76ka4DnNr2Mw+YZ1bEQoA///EI3A= Date: Thu, 23 Apr 2015 17:19:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [200.200.70.21] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[172.20.63.185] X-Barracuda-Start-Time: 1429809552 X-Barracuda-URL: http://172.20.128.4:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ultra-tcs.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18270 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Cc: MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:19:37 -0000 Thank you gentlemen for your responses and clarifications. For me a UDP/TCP= based (DLEP) architecture is more appealing than the PPPoE/PPP architectur= e.=20 Can anyone shed any light on what and how long it would take for the DLEP t= o become a standard and what is the industries approach to DLEP?=20 We want to begin implementing DLEP in our radios and the question is whethe= r the commercial routers (Cisco I guess) will follow suit? If we end up wit= h a draft-09 based implementation, will there be someone out there making r= outers we can talk to? Or is it better to wait for DLEP to be ratified as a RFC before proceeding = with any implementation? Does anyone know Cisco's implementation vis-=E0-vis radio/router is? It see= ms to me that is PPPoE based. Thank you -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Henning Rogge Sent: Thursday, April 23, 2015 12:45 PM To: James A. (Jim) Stevens Cc: MANET IETF Subject: Re: [manet] DLEP versus PPPoE On Thu, Apr 23, 2015 at 5:48 PM, James A. (Jim) Stevens wrote: > Stan, > > I understand your answer, but I presume that Deepak Lal was asking=20 > about what is the best/recommended protocol to use for radio to=20 > router. (My assumption is why implement PPPoE otherwise.) > > I would have expected you to say that the ietf manet working group=20 > recommends DLEP as the preferred radio to router protocol (or will=20 > recommend that once DLEP becomes an RFC). My personal opinion: PPPoE is only "good" for point-to-point connections... its downright bad if= you need multicast/broadcast, especially with wireless radios. There is also the fact that PPPoE with RFC5578 has only a few metrics, and = some of them have strange defaults (if you cannot judge the quality of your= link, pretend it is perfect). And PPPoE introduce an over-the-air overhead. I would say DLEP is better for connecting radios (or anything with point-to-multipoint) to routers. Henning _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------------------=0D This e-mail from Ultra Electronics and any attachments to it are confidenti= al to the intended recipient and may also be privileged.=0D If you have received it in error please notify the sender and delete it fro= m your system.=0D If you are not the intended recipient you must not copy it or use it for an= y purpose nor disclose or distribute its contents to any other person.=0D All communications may be subject to interception or monitoring for operati= onal and/or security purposes.=0D Please rely on your own virus checking as the sender cannot accept any liab= ility for any damage arising from any bug or virus infection.=0D =0D =0D Ce courriel de Ultra Electronics est destine a la personne a laquelle il es= t adresse et peut contenir des renseignements privilegies et confidentiels.= =0D Si vous avez recu ce courriel par erreur, veuillez aviser l'expediteur et l= 'effacer de votre systeme. =0D Si vous n'etes pas le destinataire, vous ne devez ni copier, ni l'utiliser = pour quel qu'usage que ce soit, ni le faire suivre a d'autres.=0D Toutes les communications sont assujetties a une surveillance et/ou interce= ption pour des besoins operationnels et/ou de securite.=0D Vous etes tenu de vous fier a votre anti-virus car l'expediteur n'acceptera= aucune responsabilite des dommages causes par un virus ou un bogue.=0D ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------------------=0D From nobody Thu Apr 23 10:30:06 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5151B30AD for ; Thu, 23 Apr 2015 10:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 YWvLHz4FQt7i for ; Thu, 23 Apr 2015 10:30:03 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 3968D1B2E95 for ; Thu, 23 Apr 2015 10:29:16 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so17542645wic.1 for ; Thu, 23 Apr 2015 10:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HOvi8GPlR+OuIUWNZhlx2UStnUCSc27ZATdZz84tKgY=; b=kB8bSghuNba5yLtVSq+8pXnSCOhOEwhk5JOjFYkg8yfgQqDe9gVJVG0zZ4Ph13SqIM sjqDc0AJuLpwVtwiIi7myfIocEXakFioEFer7W6kHRabZbNgefTd8ezocGxLRZht/sHm qPCPSHeLuYylqQ2xlQEUuoksGjJJzKhHDn1D+Wd25Za6oXMC5ldIMJHU00q8WIvwQian z/WP0cNa1kJNIYfeGZLD+DXdh0H1xPJIU1d7Iqdj0pNp9wTnetjzcdEIi+hCaTrpgfrh MSN0slZewBluU3ng5ZHrXY1JqWOb9R8AeHtDfA1E7ok8eMOQk7gq+J2jD34gyUqB1A7+ Nw+A== X-Received: by 10.180.210.171 with SMTP id mv11mr11353831wic.61.1429810154994; Thu, 23 Apr 2015 10:29:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Thu, 23 Apr 2015 10:28:54 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Thu, 23 Apr 2015 19:28:54 +0200 Message-ID: To: "Lal, Deepak (MTL)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "James A. \(Jim\) Stevens" , MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:30:04 -0000 On Thu, Apr 23, 2015 at 7:19 PM, Lal, Deepak (MTL) wrote: > Thank you gentlemen for your responses and clarifications. For me a UDP/TCP based (DLEP) architecture is more appealing than the PPPoE/PPP architecture. and UDP/TCP is only between the local router and the local radio of DLEP... DLEP has no "over-the-air" component and no mandatory tunnel. > Can anyone shed any light on what and how long it would take for the DLEP to become a standard and what is the industries approach to DLEP? I think there are already a number of companies working on their DLEP implementation for their radios. Henning Rogge From nobody Thu Apr 23 10:36:57 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB37C1ACDCD for ; Thu, 23 Apr 2015 10:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 69gjpO8YPHG2 for ; Thu, 23 Apr 2015 10:36:55 -0700 (PDT) Received: from mail.ultra-tcs.com (mx1.ultra-tcs.com [207.253.158.244]) by ietfa.amsl.com (Postfix) with ESMTP id E58DC1B2D05 for ; Thu, 23 Apr 2015 10:36:25 -0700 (PDT) X-ASG-Debug-ID: 1429810585-03a3c40f4f163ac0001-Rp4q3q Received: from SRVEXCH1.ultratcs.ca ([172.20.63.185]) by mail.ultra-tcs.com with ESMTP id PadlkWa0Kl1TbpbQ; Thu, 23 Apr 2015 13:36:25 -0400 (EDT) X-Barracuda-Envelope-From: Deepak.Lal@Ultra-TCS.com Received: from SRVEXCH1.ultratcs.ca ([fe80::6de2:32ff:bbe1:4b9a]) by SRVEXCH1.ultratcs.ca ([fe80::6de2:32ff:bbe1:4b9a%10]) with mapi id 14.02.0387.000; Thu, 23 Apr 2015 13:36:22 -0400 From: "Lal, Deepak (MTL)" To: Henning Rogge Thread-Topic: [manet] DLEP versus PPPoE X-ASG-Orig-Subj: RE: [manet] DLEP versus PPPoE Thread-Index: AQHQfeIhY41ARJT76ka4DnNr2Mw+YZ1bEQoA///EI3CAAEgOAP//vTXQ Date: Thu, 23 Apr 2015 17:36:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [200.200.70.21] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[172.20.63.185] X-Barracuda-Start-Time: 1429810585 X-Barracuda-URL: http://172.20.128.4:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ultra-tcs.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18270 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Cc: "James A. \(Jim\) Stevens" , MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 17:36:56 -0000 PiAgLi4uIERMRVAgaGFzIG5vICJvdmVyLXRoZS1haXIiIGNvbXBvbmVudCBh bmQgbm8gbWFuZGF0b3J5IHR1bm5lbA0KDQpJIHVuZGVyc3RhbmQgdGhlICJt YW5kYXRvcnkgdHVubmVsIiBzdGF0ZW1lbnQuDQpCdXQgdG8gY2xhcmlmeSwg ZXZlbiB0aG91Z2ggIERMRVAgaXRzZWxmIG1heSBub3QgdHJhdmVsICJvdmVy LXRoZS1haXIiLCBpdCBtYXkgdHJhbnNtaXQgaW5mb3JtYXRpb24gbG9jYWxs eSBhYm91dCB0aGUgcmVtb3RlIGRlc3RpbmF0aW9uIHRoYXQgaXMgcmVhY2hh YmxlIG92ZXItdGhlLWFpci4gSXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0 Pw0KDQpBbHNvIEkgYXNzdW1lIHRoYXQgeW91IG1hZGUgdGhpcyBkaXN0aW5j dGlvbiBpbiBvcmRlciB0byBjb21wYXJlIERMRVAgd2l0aCB0aGUgUkZDNTU3 OCBpbiB3aGljaCBhIFBQUCBsaW5rIGlzIHNldHVwIGJldHdlZW4gcm91dGVy cyBhdCB0aGUgdHdvIGVuZHMgb2YgYW4gYWlyIGxpbmsuIElzIHRoYXQgY29y cmVjdD8NCg0KVGhhbmtzDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEhlbm5pbmcgUm9nZ2UgW21haWx0bzpocm9nZ2VAZ21haWwu Y29tXSANClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyMywgMjAxNSAxOjI5IFBN DQpUbzogTGFsLCBEZWVwYWsgKE1UTCkNCkNjOiBKYW1lcyBBLiAoSmltKSBT dGV2ZW5zOyBNQU5FVCBJRVRGDQpTdWJqZWN0OiBSZTogW21hbmV0XSBETEVQ IHZlcnN1cyBQUFBvRQ0KDQpPbiBUaHUsIEFwciAyMywgMjAxNSBhdCA3OjE5 IFBNLCBMYWwsIERlZXBhayAoTVRMKSA8RGVlcGFrLkxhbEB1bHRyYS10Y3Mu Y29tPiB3cm90ZToNCj4gVGhhbmsgeW91IGdlbnRsZW1lbiBmb3IgeW91ciBy ZXNwb25zZXMgYW5kIGNsYXJpZmljYXRpb25zLiBGb3IgbWUgYSBVRFAvVENQ IGJhc2VkIChETEVQKSBhcmNoaXRlY3R1cmUgaXMgbW9yZSBhcHBlYWxpbmcg dGhhbiB0aGUgUFBQb0UvUFBQIGFyY2hpdGVjdHVyZS4NCg0KYW5kIFVEUC9U Q1AgaXMgb25seSBiZXR3ZWVuIHRoZSBsb2NhbCByb3V0ZXIgYW5kIHRoZSBs b2NhbCByYWRpbyBvZiBETEVQLi4uIERMRVAgaGFzIG5vICJvdmVyLXRoZS1h aXIiIGNvbXBvbmVudCBhbmQgbm8gbWFuZGF0b3J5IHR1bm5lbC4NCg0KPiBD YW4gYW55b25lIHNoZWQgYW55IGxpZ2h0IG9uIHdoYXQgYW5kIGhvdyBsb25n IGl0IHdvdWxkIHRha2UgZm9yIHRoZSBETEVQIHRvIGJlY29tZSBhIHN0YW5k YXJkIGFuZCB3aGF0IGlzIHRoZSBpbmR1c3RyaWVzIGFwcHJvYWNoIHRvIERM RVA/DQoNCkkgdGhpbmsgdGhlcmUgYXJlIGFscmVhZHkgYSBudW1iZXIgb2Yg Y29tcGFuaWVzIHdvcmtpbmcgb24gdGhlaXIgRExFUCBpbXBsZW1lbnRhdGlv biBmb3IgdGhlaXIgcmFkaW9zLg0KDQpIZW5uaW5nIFJvZ2dlDQoKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KVGhpcyBlLW1haWwgZnJvbSBVbHRyYSBFbGVjdHJv bmljcyBhbmQgYW55IGF0dGFjaG1lbnRzIHRvIGl0IGFyZSBjb25maWRlbnRp YWwgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9y IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGl0IGZyb20g eW91ciBzeXN0ZW0uDQpJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IHlvdSBtdXN0IG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55 IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yIGRpc3RyaWJ1dGUgaXRzIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQpBbGwgY29tbXVuaWNhdGlvbnMg bWF5IGJlIHN1YmplY3QgdG8gaW50ZXJjZXB0aW9uIG9yIG1vbml0b3Jpbmcg Zm9yIG9wZXJhdGlvbmFsIGFuZC9vciBzZWN1cml0eSBwdXJwb3Nlcy4NClBs ZWFzZSByZWx5IG9uIHlvdXIgb3duIHZpcnVzIGNoZWNraW5nIGFzIHRoZSBz ZW5kZXIgY2Fubm90IGFjY2VwdCBhbnkgbGlhYmlsaXR5IGZvciBhbnkgZGFt YWdlIGFyaXNpbmcgZnJvbSBhbnkgYnVnIG9yIHZpcnVzIGluZmVjdGlvbi4N Cg0KDQpDZSBjb3VycmllbCBkZSBVbHRyYSBFbGVjdHJvbmljcyBlc3QgZGVz dGluZSBhIGxhIHBlcnNvbm5lIGEgbGFxdWVsbGUgaWwgZXN0IGFkcmVzc2Ug ZXQgcGV1dCBjb250ZW5pciBkZXMgcmVuc2VpZ25lbWVudHMgcHJpdmlsZWdp ZXMgZXQgY29uZmlkZW50aWVscy4NClNpIHZvdXMgYXZleiByZWN1IGNlIGNv dXJyaWVsIHBhciBlcnJldXIsIHZldWlsbGV6IGF2aXNlciBsJ2V4cGVkaXRl dXIgZXQgbCdlZmZhY2VyIGRlIHZvdHJlIHN5c3RlbWUuIA0KU2kgdm91cyBu J2V0ZXMgcGFzIGxlIGRlc3RpbmF0YWlyZSwgdm91cyBuZSBkZXZleiBuaSBj b3BpZXIsIG5pIGwndXRpbGlzZXIgcG91ciBxdWVsIHF1J3VzYWdlIHF1ZSBj ZSBzb2l0LCBuaSBsZSBmYWlyZSBzdWl2cmUgYSBkJ2F1dHJlcy4NClRvdXRl cyBsZXMgY29tbXVuaWNhdGlvbnMgc29udCBhc3N1amV0dGllcyBhIHVuZSBz dXJ2ZWlsbGFuY2UgZXQvb3UgaW50ZXJjZXB0aW9uIHBvdXIgZGVzIGJlc29p bnMgb3BlcmF0aW9ubmVscyBldC9vdSBkZSBzZWN1cml0ZS4NClZvdXMgZXRl cyB0ZW51IGRlIHZvdXMgZmllciBhIHZvdHJlIGFudGktdmlydXMgY2FyIGwn ZXhwZWRpdGV1ciBuJ2FjY2VwdGVyYSBhdWN1bmUgcmVzcG9uc2FiaWxpdGUg ZGVzIGRvbW1hZ2VzIGNhdXNlcyBwYXIgdW4gdmlydXMgb3UgdW4gYm9ndWUu DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoK From nobody Thu Apr 23 11:08:32 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811BF1B3172 for ; Thu, 23 Apr 2015 11:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 JYrnO6ke0Jz3 for ; Thu, 23 Apr 2015 11:08:28 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 10ED11B315A for ; Thu, 23 Apr 2015 11:08:16 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.203 as permitted sender) identity=mailfrom; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,633,1422939600"; d="scan'208";a="17299807" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.203]) by ironport.idirect.net with ESMTP; 23 Apr 2015 14:08:17 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 23 Apr 2015 14:08:15 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Thu, 23 Apr 2015 14:08:15 -0400 From: "Ratliff, Stanley" To: "Lal, Deepak (MTL)" , Henning Rogge Thread-Topic: [manet] DLEP versus PPPoE Thread-Index: AQHQfeIqTUpiK/XB/U6Gu2DdLj2hDZ1bEQoAgAAJd4CAAAK5AIAAAhWA///FCOA= Date: Thu, 23 Apr 2015 18:08:15 +0000 Message-ID: <3cb66bf7eac946e487b43287cecd9424@VAUSDITCHM2.idirect.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "James A. \(Jim\) Stevens" , MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 18:08:30 -0000 Deepak,=20 DLEP itself does not define any "over-the-air" signaling. However, you are = correct in that some of the data that flows between a radio and it's *local= ly* attached router implies that OTA signaling has, indeed, occurred. Speci= fically, the radio knows about the remote MAC address of the destination - = it had to have obtained that information somehow. ;-) The same thing appli= es to the optional Layer 3 addresses on the remote side. We don't specify h= ow a radio would come to know the IP address(es) of something on the other = end of the air link, but if you happen to know of them, DLEP will let you s= ignal that information to your local router.=20 Regards, Stan > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lal, Deepak > (MTL) > Sent: Thursday, April 23, 2015 1:36 PM > To: Henning Rogge > Cc: James A. (Jim) Stevens; MANET IETF > Subject: Re: [manet] DLEP versus PPPoE >=20 > > ... DLEP has no "over-the-air" component and no mandatory tunnel >=20 > I understand the "mandatory tunnel" statement. > But to clarify, even though DLEP itself may not travel "over-the-air", i= t may > transmit information locally about the remote destination that is reachab= le > over-the-air. Is my understanding correct? >=20 > Also I assume that you made this distinction in order to compare DLEP wit= h > the RFC5578 in which a PPP link is setup between routers at the two ends = of > an air link. Is that correct? >=20 > Thanks >=20 >=20 > -----Original Message----- > From: Henning Rogge [mailto:hrogge@gmail.com] > Sent: Thursday, April 23, 2015 1:29 PM > To: Lal, Deepak (MTL) > Cc: James A. (Jim) Stevens; MANET IETF > Subject: Re: [manet] DLEP versus PPPoE >=20 > On Thu, Apr 23, 2015 at 7:19 PM, Lal, Deepak (MTL) tcs.com> wrote: > > Thank you gentlemen for your responses and clarifications. For me a > UDP/TCP based (DLEP) architecture is more appealing than the PPPoE/PPP > architecture. >=20 > and UDP/TCP is only between the local router and the local radio of DLEP.= .. > DLEP has no "over-the-air" component and no mandatory tunnel. >=20 > > Can anyone shed any light on what and how long it would take for the DL= EP > to become a standard and what is the industries approach to DLEP? >=20 > I think there are already a number of companies working on their DLEP > implementation for their radios. >=20 > Henning Rogge >=20 > -------------------------------------------------------------------------= --------------------- > -------------------------------------------------------------------------= --------------------- > ----------- > This e-mail from Ultra Electronics and any attachments to it are confiden= tial > to the intended recipient and may also be privileged. > If you have received it in error please notify the sender and delete it f= rom > your system. > If you are not the intended recipient you must not copy it or use it for = any > purpose nor disclose or distribute its contents to any other person. > All communications may be subject to interception or monitoring for > operational and/or security purposes. > Please rely on your own virus checking as the sender cannot accept any > liability for any damage arising from any bug or virus infection. >=20 >=20 > Ce courriel de Ultra Electronics est destine a la personne a laquelle il = est > adresse et peut contenir des renseignements privilegies et confidentiels. > Si vous avez recu ce courriel par erreur, veuillez aviser l'expediteur et > l'effacer de votre systeme. > Si vous n'etes pas le destinataire, vous ne devez ni copier, ni l'utilise= r pour > quel qu'usage que ce soit, ni le faire suivre a d'autres. > Toutes les communications sont assujetties a une surveillance et/ou > interception pour des besoins operationnels et/ou de securite. > Vous etes tenu de vous fier a votre anti-virus car l'expediteur n'accepte= ra > aucune responsabilite des dommages causes par un virus ou un bogue. > -------------------------------------------------------------------------= --------------------- > -------------------------------------------------------------------------= --------------------- > ----------- >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Apr 23 11:09:42 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9A71B314E for ; Thu, 23 Apr 2015 11:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 HYhdSjXmv9Np for ; Thu, 23 Apr 2015 11:09:40 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (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 60A7E1B3162 for ; Thu, 23 Apr 2015 11:09:03 -0700 (PDT) Received: by wgso17 with SMTP id o17so27019881wgs.1 for ; Thu, 23 Apr 2015 11:09:02 -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-type; bh=PHLey5yESYw70ObgAKpI+JQh9FrliYGSc6NRyhcob2U=; b=q8mKupYWzfr5hsPsJooRzuG136YjzAJc7o38MZJYtC01SSbwZ6B/OUxpXuM28tbJ9c W+/Ge9qwX8q2jul8K4mfVWMzHQ+tK7JblfDvWvNxb8LvkjXrKvubnduIyFeayzqI32dl uJE9RejrKJAWxzsRV5kvLy0Tm/TYnGHV3m+z/AZqYHQgz7VXd/Gh2YRr0uwnGo2PEWeI XiT307TFq3EmRQZbIwR/vMVExVyeoHD2444dvOn+vkLVjglYR3UkctpVM2E45s4lCQK3 K0VRSHqNbhV8XMnFXuk+Z30JaGPEZ4+eSHE8Kw23Rv4lXdckslh6rbtx0aTaAo9U/eK0 LhGA== X-Received: by 10.194.184.45 with SMTP id er13mr7951365wjc.71.1429812542196; Thu, 23 Apr 2015 11:09:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Thu, 23 Apr 2015 11:08:41 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Thu, 23 Apr 2015 20:08:41 +0200 Message-ID: To: "Lal, Deepak (MTL)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "James A. \(Jim\) Stevens" , MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 18:09:41 -0000 On Thu, Apr 23, 2015 at 7:36 PM, Lal, Deepak (MTL) wrote: >> ... DLEP has no "over-the-air" component and no mandatory tunnel > > I understand the "mandatory tunnel" statement. > But to clarify, even though DLEP itself may not travel "over-the-air", it may transmit information locally about the remote destination that is reachable over-the-air. Is my understanding correct? Yes. DLEP is just about transmitting information from the local radio to the local router and the other way around. > Also I assume that you made this distinction in order to compare DLEP with the RFC5578 in which a PPP link is setup between routers at the two ends of an air link. Is that correct? Yes. Henning Rogge From nobody Thu Apr 23 11:18:05 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72AF41B3161 for ; Thu, 23 Apr 2015 11:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CjOnMznXGaPA for ; Thu, 23 Apr 2015 11:18:01 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2561E1B312C for ; Thu, 23 Apr 2015 11:17:43 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,633,1422939600"; d="scan'208";a="17299831" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport.idirect.net with ESMTP; 23 Apr 2015 14:17:43 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 23 Apr 2015 14:17:42 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Thu, 23 Apr 2015 14:17:41 -0400 From: "Ratliff, Stanley" To: "Lal, Deepak (MTL)" , Henning Rogge Thread-Topic: [manet] DLEP versus PPPoE Thread-Index: AQHQfeIqTUpiK/XB/U6Gu2DdLj2hDZ1bEQoAgAAJd4CAAAK5AIAAAhWA///F5TA= Date: Thu, 23 Apr 2015 18:17:41 +0000 Message-ID: <98f4940cc70748f3a892a646e546f32f@VAUSDITCHM2.idirect.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "James A. \(Jim\) Stevens" , MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 18:18:03 -0000 Deepak,=20 Sorry for the multiple responses - I just saw your other question...=20 Yes, the distinction is *somewhat* in comparison to RFC5578. A good example= of that is the remote IP addresses - in the RFC5578 "split-stack" approach= , the remote IP addresses are known, since the PPPoE partners have complete= d IPCP/IPv6CP. So transmission of IP address(es) over-the-air occurred as a= result of that negotiation.=20 With DLEP, I (as an author) has always envisioned IP address communication = to occur something like this:=20 1. A radio establishes a connection with it's locally attached router. The = "Peer Initialization" message contains the layer 3 address(es) of the route= r. It is *possible* for the radio to treat those TLVs as "opaque informatio= n" - no understanding of what the information is (an IP address) is actuall= y required, the radio can just "hang onto it" as an opaque block of informa= tion.=20 2. The radio establishes link-level communication with another radio. The t= wo radios could theoretically then trade their "opaque information" with ea= ch other, using OTA signaling.=20 3. The received "opaque information" is then inserted via direct copy into = a "Destination Up" signal, bound for my locally attached router.=20 4. The receiving router then knows how to decode the address information.=20 As I mentioned in the earlier email - none of this is *required*, but it's = a technique available if an implementation chooses to do so. Regards, Stan > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lal, Deepak > (MTL) > Sent: Thursday, April 23, 2015 1:36 PM > To: Henning Rogge > Cc: James A. (Jim) Stevens; MANET IETF > Subject: Re: [manet] DLEP versus PPPoE >=20 > > ... DLEP has no "over-the-air" component and no mandatory tunnel >=20 > I understand the "mandatory tunnel" statement. > But to clarify, even though DLEP itself may not travel "over-the-air", i= t may > transmit information locally about the remote destination that is reachab= le > over-the-air. Is my understanding correct? >=20 > Also I assume that you made this distinction in order to compare DLEP wit= h > the RFC5578 in which a PPP link is setup between routers at the two ends = of > an air link. Is that correct? >=20 > Thanks >=20 >=20 > -----Original Message----- > From: Henning Rogge [mailto:hrogge@gmail.com] > Sent: Thursday, April 23, 2015 1:29 PM > To: Lal, Deepak (MTL) > Cc: James A. (Jim) Stevens; MANET IETF > Subject: Re: [manet] DLEP versus PPPoE >=20 > On Thu, Apr 23, 2015 at 7:19 PM, Lal, Deepak (MTL) tcs.com> wrote: > > Thank you gentlemen for your responses and clarifications. For me a > UDP/TCP based (DLEP) architecture is more appealing than the PPPoE/PPP > architecture. >=20 > and UDP/TCP is only between the local router and the local radio of DLEP.= .. > DLEP has no "over-the-air" component and no mandatory tunnel. >=20 > > Can anyone shed any light on what and how long it would take for the DL= EP > to become a standard and what is the industries approach to DLEP? >=20 > I think there are already a number of companies working on their DLEP > implementation for their radios. >=20 > Henning Rogge >=20 > -------------------------------------------------------------------------= --------------------- > -------------------------------------------------------------------------= --------------------- > ----------- > This e-mail from Ultra Electronics and any attachments to it are confiden= tial > to the intended recipient and may also be privileged. > If you have received it in error please notify the sender and delete it f= rom > your system. > If you are not the intended recipient you must not copy it or use it for = any > purpose nor disclose or distribute its contents to any other person. > All communications may be subject to interception or monitoring for > operational and/or security purposes. > Please rely on your own virus checking as the sender cannot accept any > liability for any damage arising from any bug or virus infection. >=20 >=20 > Ce courriel de Ultra Electronics est destine a la personne a laquelle il = est > adresse et peut contenir des renseignements privilegies et confidentiels. > Si vous avez recu ce courriel par erreur, veuillez aviser l'expediteur et > l'effacer de votre systeme. > Si vous n'etes pas le destinataire, vous ne devez ni copier, ni l'utilise= r pour > quel qu'usage que ce soit, ni le faire suivre a d'autres. > Toutes les communications sont assujetties a une surveillance et/ou > interception pour des besoins operationnels et/ou de securite. > Vous etes tenu de vous fier a votre anti-virus car l'expediteur n'accepte= ra > aucune responsabilite des dommages causes par un virus ou un bogue. > -------------------------------------------------------------------------= --------------------- > -------------------------------------------------------------------------= --------------------- > ----------- >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Thu Apr 23 12:37:22 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FA31B29CB for ; Thu, 23 Apr 2015 12:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5QmQTp7kjZK6 for ; Thu, 23 Apr 2015 12:37:19 -0700 (PDT) Received: from mail.ultra-tcs.com (mx1.ultra-tcs.com [207.253.158.244]) by ietfa.amsl.com (Postfix) with ESMTP id 766211B31B4 for ; Thu, 23 Apr 2015 12:37:06 -0700 (PDT) X-ASG-Debug-ID: 1429817825-03a3c40f4f1653c0001-Rp4q3q Received: from SRVEXCH1.ultratcs.ca ([172.20.63.185]) by mail.ultra-tcs.com with ESMTP id yZkoVaZMkcVZd0XF; Thu, 23 Apr 2015 15:37:05 -0400 (EDT) X-Barracuda-Envelope-From: Deepak.Lal@Ultra-TCS.com Received: from SRVEXCH1.ultratcs.ca ([fe80::6de2:32ff:bbe1:4b9a]) by SRVEXCH1.ultratcs.ca ([fe80::6de2:32ff:bbe1:4b9a%10]) with mapi id 14.02.0387.000; Thu, 23 Apr 2015 15:37:02 -0400 From: "Lal, Deepak (MTL)" To: "Ratliff, Stanley" , Henning Rogge Thread-Topic: [manet] DLEP versus PPPoE X-ASG-Orig-Subj: RE: [manet] DLEP versus PPPoE Thread-Index: AQHQfeIhY41ARJT76ka4DnNr2Mw+YZ1bEQoA///EI3CAAEgOAP//vTXQgABQbID//87OEA== Date: Thu, 23 Apr 2015 19:37:01 +0000 Message-ID: References: <98f4940cc70748f3a892a646e546f32f@VAUSDITCHM2.idirect.net> In-Reply-To: <98f4940cc70748f3a892a646e546f32f@VAUSDITCHM2.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [200.200.70.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[172.20.63.185] X-Barracuda-Start-Time: 1429817825 X-Barracuda-URL: http://172.20.128.4:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ultra-tcs.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18274 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Cc: "James A. \(Jim\) Stevens" , MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 19:37:21 -0000 Excellent. Thanks to everyone for clarifications. Other than the dlep_tools, is anyone aware of any other open source impleme= ntations? -----Original Message----- From: Ratliff, Stanley [mailto:sratliff@idirect.net]=20 Sent: Thursday, April 23, 2015 2:18 PM To: Lal, Deepak (MTL); Henning Rogge Cc: James A. (Jim) Stevens; MANET IETF Subject: RE: [manet] DLEP versus PPPoE Deepak,=20 Sorry for the multiple responses - I just saw your other question...=20 Yes, the distinction is *somewhat* in comparison to RFC5578. A good example= of that is the remote IP addresses - in the RFC5578 "split-stack" approach= , the remote IP addresses are known, since the PPPoE partners have complete= d IPCP/IPv6CP. So transmission of IP address(es) over-the-air occurred as a= result of that negotiation.=20 With DLEP, I (as an author) has always envisioned IP address communication = to occur something like this:=20 1. A radio establishes a connection with it's locally attached router. The = "Peer Initialization" message contains the layer 3 address(es) of the route= r. It is *possible* for the radio to treat those TLVs as "opaque informatio= n" - no understanding of what the information is (an IP address) is actuall= y required, the radio can just "hang onto it" as an opaque block of informa= tion.=20 2. The radio establishes link-level communication with another radio. The t= wo radios could theoretically then trade their "opaque information" with ea= ch other, using OTA signaling.=20 3. The received "opaque information" is then inserted via direct copy into = a "Destination Up" signal, bound for my locally attached router.=20 4. The receiving router then knows how to decode the address information.= =20 As I mentioned in the earlier email - none of this is *required*, but it's = a technique available if an implementation chooses to do so. Regards, Stan > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lal, Deepak > (MTL) > Sent: Thursday, April 23, 2015 1:36 PM > To: Henning Rogge > Cc: James A. (Jim) Stevens; MANET IETF > Subject: Re: [manet] DLEP versus PPPoE >=20 > > ... DLEP has no "over-the-air" component and no mandatory tunnel >=20 > I understand the "mandatory tunnel" statement. > But to clarify, even though DLEP itself may not travel=20 > "over-the-air", it may transmit information locally about the remote=20 > destination that is reachable over-the-air. Is my understanding correct? >=20 > Also I assume that you made this distinction in order to compare DLEP=20 > with the RFC5578 in which a PPP link is setup between routers at the=20 > two ends of an air link. Is that correct? >=20 > Thanks >=20 >=20 > -----Original Message----- > From: Henning Rogge [mailto:hrogge@gmail.com] > Sent: Thursday, April 23, 2015 1:29 PM > To: Lal, Deepak (MTL) > Cc: James A. (Jim) Stevens; MANET IETF > Subject: Re: [manet] DLEP versus PPPoE >=20 > On Thu, Apr 23, 2015 at 7:19 PM, Lal, Deepak (MTL) tcs.com> wrote: > > Thank you gentlemen for your responses and clarifications. For me a > UDP/TCP based (DLEP) architecture is more appealing than the PPPoE/PPP=20 > architecture. >=20 > and UDP/TCP is only between the local router and the local radio of DLEP.= .. > DLEP has no "over-the-air" component and no mandatory tunnel. >=20 > > Can anyone shed any light on what and how long it would take for the=20 > > DLEP > to become a standard and what is the industries approach to DLEP? >=20 > I think there are already a number of companies working on their DLEP=20 > implementation for their radios. >=20 > Henning Rogge >=20 > ---------------------------------------------------------------------- > ------------------------ > ---------------------------------------------------------------------- > ------------------------ > ----------- > This e-mail from Ultra Electronics and any attachments to it are=20 > confidential to the intended recipient and may also be privileged. > If you have received it in error please notify the sender and delete=20 > it from your system. > If you are not the intended recipient you must not copy it or use it=20 > for any purpose nor disclose or distribute its contents to any other pers= on. > All communications may be subject to interception or monitoring for=20 > operational and/or security purposes. > Please rely on your own virus checking as the sender cannot accept any=20 > liability for any damage arising from any bug or virus infection. >=20 >=20 > Ce courriel de Ultra Electronics est destine a la personne a laquelle=20 > il est adresse et peut contenir des renseignements privilegies et confide= ntiels. > Si vous avez recu ce courriel par erreur, veuillez aviser l'expediteur=20 > et l'effacer de votre systeme. > Si vous n'etes pas le destinataire, vous ne devez ni copier, ni=20 > l'utiliser pour quel qu'usage que ce soit, ni le faire suivre a d'autres. > Toutes les communications sont assujetties a une surveillance et/ou=20 > interception pour des besoins operationnels et/ou de securite. > Vous etes tenu de vous fier a votre anti-virus car l'expediteur=20 > n'acceptera aucune responsabilite des dommages causes par un virus ou un = bogue. > ---------------------------------------------------------------------- > ------------------------ > ---------------------------------------------------------------------- > ------------------------ > ----------- >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------------------=0D This e-mail from Ultra Electronics and any attachments to it are confidenti= al to the intended recipient and may also be privileged.=0D If you have received it in error please notify the sender and delete it fro= m your system.=0D If you are not the intended recipient you must not copy it or use it for an= y purpose nor disclose or distribute its contents to any other person.=0D All communications may be subject to interception or monitoring for operati= onal and/or security purposes.=0D Please rely on your own virus checking as the sender cannot accept any liab= ility for any damage arising from any bug or virus infection.=0D =0D =0D Ce courriel de Ultra Electronics est destine a la personne a laquelle il es= t adresse et peut contenir des renseignements privilegies et confidentiels.= =0D Si vous avez recu ce courriel par erreur, veuillez aviser l'expediteur et l= 'effacer de votre systeme. =0D Si vous n'etes pas le destinataire, vous ne devez ni copier, ni l'utiliser = pour quel qu'usage que ce soit, ni le faire suivre a d'autres.=0D Toutes les communications sont assujetties a une surveillance et/ou interce= ption pour des besoins operationnels et/ou de securite.=0D Vous etes tenu de vous fier a votre anti-virus car l'expediteur n'acceptera= aucune responsabilite des dommages causes par un virus ou un bogue.=0D ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------------------=0D From nobody Thu Apr 23 12:39:06 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BE91B29E9 for ; Thu, 23 Apr 2015 12:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 VqXIfOppgasU for ; Thu, 23 Apr 2015 12:39:03 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::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 C9DBE1B31B4 for ; Thu, 23 Apr 2015 12:38:47 -0700 (PDT) Received: by widdi4 with SMTP id di4so228215605wid.0 for ; Thu, 23 Apr 2015 12:38:46 -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-type; bh=ew+H1lrRVr3QtvMOMu3rVKJys8sKvDeyICPX/94TAj0=; b=Z+G7zNvaT5qBEJzT6ZDJxdxTDBaUa26ul7nUbMMqONOoFWm6j1gS2YIFp0Yy+ivQ5M pcl5AcURo2uIZ1CN/iB53+ywzHzAeb/spitWNBxtSe4jj1jeE3bCu6Mso0Thi8b0zr+9 4mbUUJSKjYyXU47GM5pS7T/3CsenairfuC4B88ZzaJejGes47vOuLnCHC/xCgM82iQQj 8MEIsD1/4lM1nRwZYdXlPobx2QB5L1JQ/mh6qTvxzkybzc+ilFIudb7RDp+xyCsAgzoD kLpNA+GxmLNtvl1Rj/BdrW7xn6Kb8k/6sj0z2QreCRHhCPrTpaFQ7CbGpoqjHD4EDPKk LYAw== X-Received: by 10.180.84.65 with SMTP id w1mr18060945wiy.20.1429817926643; Thu, 23 Apr 2015 12:38:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Thu, 23 Apr 2015 12:38:25 -0700 (PDT) In-Reply-To: References: <98f4940cc70748f3a892a646e546f32f@VAUSDITCHM2.idirect.net> From: Henning Rogge Date: Thu, 23 Apr 2015 21:38:25 +0200 Message-ID: To: "Lal, Deepak (MTL)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "James A. \(Jim\) Stevens" , MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 19:39:05 -0000 On Thu, Apr 23, 2015 at 9:37 PM, Lal, Deepak (MTL) wrote: > Excellent. Thanks to everyone for clarifications. > > Other than the dlep_tools, is anyone aware of any other open source implementations? This one is mine (BSD style licence): http://www.olsr.org/mediawiki/index.php/DLEP Henning Rogge From nobody Fri Apr 24 01:24:46 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056B41B35CE for ; Fri, 24 Apr 2015 01:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 8jk1oev0SH27 for ; Fri, 24 Apr 2015 01:24:43 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::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 8F8051B35BA for ; Fri, 24 Apr 2015 01:24:36 -0700 (PDT) Received: by qcbii10 with SMTP id ii10so22134259qcb.2 for ; Fri, 24 Apr 2015 01:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fdccFepPO9hk64KxkKkz8CMG3VNN1Sx733L38zNEFDk=; b=O6/Zf9CpNH6VLWU1Cb6gMYr758PyglSSgRIw4bha/GUmrIsph4oZgfXMSRf1jJT1jD b4uaWW1EBdPPIdXJdsNBmpXh4Ok7k1sGESq8/14XIJY0aqZEcnirHfYMwUGwNCDdUT+0 twPspJ4anxbI+srTD5HqD+Ri8ILEZ44lmhG2ixCPF9Kf3oskl8UIGZFgIQ5tmaPbDPza FKcDpXI2dSKQDT6peY0BHMcY8bSOxVbtVz7IiS4BOs47qW62c566nMK1PAZpfJ885uvD lc6GNMFaqThkLpGEhaLiRBOquQSll7aq/bI1k+OkfqYfnr9PiBvY7DmKG+hV+tbaCPAQ V4Ag== MIME-Version: 1.0 X-Received: by 10.140.135.18 with SMTP id 18mr8315037qhh.71.1429863875859; Fri, 24 Apr 2015 01:24:35 -0700 (PDT) Received: by 10.140.84.105 with HTTP; Fri, 24 Apr 2015 01:24:35 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Apr 2015 10:24:35 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=001a1136fe6265d8a205147420fe Archived-At: Cc: "James A. \(Jim\) Stevens" , MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 08:24:45 -0000 --001a1136fe6265d8a205147420fe Content-Type: text/plain; charset=UTF-8 Thanks Henning, AB On Thu, Apr 23, 2015 at 8:08 PM, Henning Rogge wrote: > On Thu, Apr 23, 2015 at 7:36 PM, Lal, Deepak (MTL) > wrote: > >> ... DLEP has no "over-the-air" component and no mandatory tunnel > > > > I understand the "mandatory tunnel" statement. > > But to clarify, even though DLEP itself may not travel "over-the-air", > it may transmit information locally about the remote destination that is > reachable over-the-air. Is my understanding correct? > > Yes. DLEP is just about transmitting information from the local radio > to the local router and the other way around. > > > Also I assume that you made this distinction in order to compare DLEP > with the RFC5578 in which a PPP link is setup between routers at the two > ends of an air link. Is that correct? > > Yes. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a1136fe6265d8a205147420fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Henning,

AB

On Thu, Apr 23,= 2015 at 8:08 PM, Henning Rogge <hrogge@gmail.com> wrote:
=
On Thu, Apr 23, 2015 at 7:36 PM, Lal, = Deepak (MTL)
<Deepak.Lal@ultra-tcs.com> wrote:
>>=C2=A0 ... DLEP has no "over-the-air" component and no ma= ndatory tunnel
>
> I understand the "mandatory tunnel" statement.
> But to clarify, even though=C2=A0 DLEP itself may not travel "ove= r-the-air", it may transmit information locally about the remote desti= nation that is reachable over-the-air. Is my understanding correct?

Yes. DLEP is just about transmitting information from the local radi= o
to the local router and the other way around.

> Also I assume that you made this distinction in order to compare DLEP = with the RFC5578 in which a PPP link is setup between routers at the two en= ds of an air link. Is that correct?

Yes.

Henning Rogge

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

--001a1136fe6265d8a205147420fe-- From nobody Fri Apr 24 01:29:46 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE431B3604 for ; Fri, 24 Apr 2015 01:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 Zc-pOZqipuku for ; Fri, 24 Apr 2015 01:29:42 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::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 B40F91B35ED for ; Fri, 24 Apr 2015 01:28:42 -0700 (PDT) Received: by widdi4 with SMTP id di4so11867053wid.0 for ; Fri, 24 Apr 2015 01:28:41 -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-type; bh=ztrht3hxj22Lc34BtE7QAtYiP9BxM+j3lTqAdxodYNM=; b=E8AO8A8bhJaivWJjNmfLOpb4lWXOcv4SfWKaQNBTPd5BOeAgq37NLpFgv/yXuhCYZV rGWr5hW78qZhy0d3r6sxQqee8AvSUMp1ROjLF1i9TxVYKtQ+hLTD4OmAj+uDurKxqQzq 0YJZUvBJAkCu0FrxLyuSDNOQexRAY8joM0MFXwefiCFFf2OB96K5Fd4EFSkyHTRx5kgo FTmfuCuHAspNzRQBPlsUybdMb5sQkppFhjREsSfeh0TIrCCpB0Rem3N7h7NUiBXge8i/ t1/SDd76Nt/fyqTwr6fTYG+k4kd55tsZs8QZf1e49t8ef8xaWcWPvoDiQR6rCi3B75ur rYAw== X-Received: by 10.194.19.197 with SMTP id h5mr13253474wje.109.1429864121526; Fri, 24 Apr 2015 01:28:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Fri, 24 Apr 2015 01:28:21 -0700 (PDT) In-Reply-To: References: <98f4940cc70748f3a892a646e546f32f@VAUSDITCHM2.idirect.net> From: Henning Rogge Date: Fri, 24 Apr 2015 10:28:21 +0200 Message-ID: To: "Lal, Deepak (MTL)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "James A. \(Jim\) Stevens" , MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 08:29:44 -0000 Oh, just one additional thing. My code got updated to DLEP-09 yesterday, so it might still contain a few quirks. I tested it between two VMs, but I will do more testing over the next week. Henning Rogge On Thu, Apr 23, 2015 at 9:38 PM, Henning Rogge wrote: > On Thu, Apr 23, 2015 at 9:37 PM, Lal, Deepak (MTL) > wrote: >> Excellent. Thanks to everyone for clarifications. >> >> Other than the dlep_tools, is anyone aware of any other open source implementations? > > This one is mine (BSD style licence): > > http://www.olsr.org/mediawiki/index.php/DLEP > > Henning Rogge From nobody Fri Apr 24 01:57:07 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D509D1B367B for ; Fri, 24 Apr 2015 01:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham 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 bH2GPO9BHNo0 for ; Fri, 24 Apr 2015 01:57:02 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (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 45A291B3667 for ; Fri, 24 Apr 2015 01:56:35 -0700 (PDT) Received: by qcrf4 with SMTP id f4so22407824qcr.0 for ; Fri, 24 Apr 2015 01:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1qz55pZw9/T4PaeAghRIcIHlwMP+/wNrvlaxuynXItE=; b=05Qn5/XqVFi/1Djeaxv3YbQb/lWUEsD1BJnsgF7z3wwIcpSr6E1a7rp9r5FSnoBTfv 4T0JRpq/u10+zPiCj8s9ITNIJMF+EmJ9d5WqyS5Oe6m+ZvqmBu5wTiSUCuWXOTvMOoo0 yRN61NB5mFETXZEKXYDkx0YSXmes5RlSenErqv0nE8F1fzc2LKq5EUV6RQNHFFRittlJ 8XY4MOBOQ7IGzLXopC++Qh/2U44Oee3/+qgwhy3xFwBfyuXjuxqq3A2utPK8q+24PU8E IbxE/quZQo/aKSmidWW3JiUNMeAx/XY+h4CPFDV+b+M+cXYNmTBv9RCofGrFl/ucg1Nv SfFg== MIME-Version: 1.0 X-Received: by 10.140.27.162 with SMTP id 31mr7980908qgx.64.1429865794592; Fri, 24 Apr 2015 01:56:34 -0700 (PDT) Received: by 10.140.84.105 with HTTP; Fri, 24 Apr 2015 01:56:34 -0700 (PDT) In-Reply-To: References: <20150422064506.15307.76274.idtracker@ietfa.amsl.com> Date: Fri, 24 Apr 2015 10:56:34 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c15330c367a905147492e9 Archived-At: Cc: MANET IETF , Fabian Nack Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-05.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 08:57:05 -0000 --001a11c15330c367a905147492e9 Content-Type: text/plain; charset=UTF-8 Hi Henning, Thanks for the update, I think also that it can go for last call, I will try to review in the coming days, but short comments below. 1-I think the draft calls this metric as DAT metric, as you mention in the draft in other sections, so we can mention this in the title or in Abstract or in introduction. 2-suggest to add to the Abstract: The DAT metric document describes a new routing metric for OLSRv2. It takes both the loss rate and the link speed into account to provide additional information of the links within the MANET. 3- The applicability statement is excellent, however, my only comment is that it mentions the word 'metric' (meaning this specification metric) but could we clarify it in this section as DAT metric, or just say the metric specification. Best Regards, AB On Wed, Apr 22, 2015 at 8:48 AM, Henning Rogge wrote: > On Wed, Apr 22, 2015 at 8:45 AM, wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Mobile Ad-hoc Networks Working Group > of the IETF. > > > > Title : Packet Sequence Number based directional > airtime metric for OLSRv2 > > Authors : Henning Rogge > > Emmanuel Baccelli > > Filename : draft-ietf-manet-olsrv2-dat-metric-05.txt > > Pages : 17 > > Date : 2015-04-21 > > Hi, > > I posted a last revision of the DAT metric draft based on a review I > got from Fabian Nack. > > The change is small, I renamed two variables to make their usage more > clear and fixed a mixup between two variable names in the metric > update. > > I think DAT should be ready for last call... > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c15330c367a905147492e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Henning,

Thanks for the update, I think also that it can go fo= r last call, I will try to review in the coming days, but short comments be= low.

1-I think the d= raft=C2=A0calls this metric as DAT metric, as you mention in the draft in o= ther sections, so we can mention this in the title or in Abstract or in int= roduction.

2-suggest= to add to the Abstract:

The DAT metric=C2=A0document describes a=C2=A0new routing metric for
OLSRv2. It takes both the loss rate and the link sp= eed into
account to provide additional information= =C2=A0of the links within the MANET.

3- The applicability statement is excellent, however, my o= nly comment is that it mentions the word 'metric' (meaning this spe= cification metric) but could we clarify it in this section as DAT metric, o= r just say the metric specification.

Best Regards,

AB

On Wed, Apr 22, 2015 at 8:48 AM, Henning Rogge <hrogg= e@gmail.com> wrote:
O= n Wed, Apr 22, 2015 at 8:45 AM,=C2=A0 <internet-drafts@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=C2=A0 This draft is a work item of the Mobile Ad-hoc Networks Working = Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Packet Sequence Number based directional airtime metric for OLS= Rv2
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Henning Rogge
>=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 =C2=A0Emmanuel Baccelli
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-ietf-manet-olsrv2-dat-metric-05.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 17
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2015-04-21

Hi,

I posted a last revision of the DAT metric draft based on a review I
got from Fabian Nack.

The change is small, I renamed two variables to make their usage more
clear and fixed a mixup between two variable names in the metric
update.

I think DAT should be ready for last call...

Henning Rogge

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

--001a11c15330c367a905147492e9-- From nobody Fri Apr 24 03:36:00 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977EC1A87B9 for ; Fri, 24 Apr 2015 03:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8-6YEx4q18sV for ; Fri, 24 Apr 2015 03:35:58 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DD81A87B3 for ; Fri, 24 Apr 2015 03:35:57 -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; Fri, 24 Apr 2015 11:35:27 +0100 From: Rick Taylor To: Henning Rogge , "Lal, Deepak (MTL)" Thread-Topic: [manet] DLEP versus PPPoE Thread-Index: AQHQfeIih+byx+rOIkus48RY8TWffQ== Date: Fri, 24 Apr 2015 10:35:25 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016753B951@tss-server1.home.tropicalstormsoftware.com> References: <98f4940cc70748f3a892a646e546f32f@VAUSDITCHM2.idirect.net> 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: "James A. \(Jim\) Stevens" , MANET IETF Subject: Re: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 10:35:59 -0000 There is also Airbus' reference implementation under a liberal license at:= =0A= =0A= https://github.com/ricktaylor/dlep_router=0A= =0A= This version is still draft-07, but I intend to update it to version 1 =0A= when last call is over.=0A= =0A= The changes to v1 should be trivial.=0A= =0A= Rick=0A= =0A= On 23/04/15 20:39, Henning Rogge wrote:=0A= > On Thu, Apr 23, 2015 at 9:37 PM, Lal, Deepak (MTL)=0A= > wrote:=0A= >> Excellent. Thanks to everyone for clarifications.=0A= >>=0A= >> Other than the dlep_tools, is anyone aware of any other open source impl= ementations?=0A= >=0A= > This one is mine (BSD style licence):=0A= >=0A= > http://www.olsr.org/mediawiki/index.php/DLEP=0A= >=0A= > Henning Rogge=0A= >=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= =0A= From nobody Wed Apr 29 00:16:13 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F06D1AD0B7 for ; Wed, 29 Apr 2015 00:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.785 X-Spam-Level: * X-Spam-Status: No, score=1.785 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Lzm5XJhBxFW2 for ; Wed, 29 Apr 2015 00:16:08 -0700 (PDT) Received: from atcmail.atc.tcs.com (atcmail.atc.tcs.com [203.200.212.145]) (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 C9FF91AD065 for ; Wed, 29 Apr 2015 00:16:07 -0700 (PDT) Received: from localhost.localdomain ([172.20.94.178]) (authenticated bits=0) by atcmail.atc.tcs.com (8.14.4/8.14.4) with ESMTP id t3T7Fxjh019008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 29 Apr 2015 12:46:00 +0530 Message-ID: <5540852F.1060500@atc.tcs.com> Date: Wed, 29 Apr 2015 12:45:59 +0530 From: Vigneswaran R User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: manet@ietf.org References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030108010305050205010500" Archived-At: Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 07:16:12 -0000 This is a multi-part message in MIME format. --------------030108010305050205010500 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Adding my observations inline... On 04/22/2015 04:19 PM, Victoria Mercieca wrote: > Hi Stan, hi all, > > A few comments on DLEP-09: > > When DLEP supplies both MAC and IP address of a destination, would it > create ARP entries? This is mentioned in Section 2 Assumptions and > also in 6.9 Destination Up, where it specifically says "reducing the > need for the receiver to probe for any address". > > Also in Section 2 Assumptions, you have a statement that any signals > not understood should result in session termination, but that data > items that are not understood should be ignored. Compare with Section > 5 DLEP Message Processing, where it says that unrecognized, invalid or > disallowed data items also force termination, and 6.4 which says that > any metric data item which is not expected causes termination. I guess > the Assumptions just needs updating? > > In 3.3 Experimental Signals and Data Items, it becomes clear by the > end of this section that we have an Experimental Definition which is a > set of signals and data items. I would suggest making this clearer > from the start by rewriting the second sentence "The intent is to > allow for experimentation with a set of new signals and/or data > items,"... but maybe I am being too picky! > > In Section 4 Metrics, in the last paragraph, you state that algorithms > for utilizing dual context metrics is out of scope. Then in Section > 4.5 and 6.5 you say that metrics supplied in Peer signals MUST be set > for all destinations. > > In Section 4 which is titled Metrics, you then have subsections 4.2 - > 4.5 which are about session flow. Should these be a separate Section > between 4 and 5? Also, you have subsections for discovery and common > flow but not for termination. If you did, it might be a nice place to > collect the information about termination due to unrecognized/invalid > signals and data items, plus would make this "session flow" section > more complete. > > In 4.5 you have "[Heartbeat signals]#(sig_heartbeat)". > > In 5.1 you have a typo - "bu" instead of "by". > > In 6.5 you say that modems that don't track layer 3 addresses SHOULD > silently parse and ignore the Peer Update, then the final sentence in > the section says a Peer Update MUST be acknowledged by a Peer Update > ACK. Also, if a modem does not support layer 3 address tracking, why > wouldn't it just send back an ACK with a non-zero status code? Then > the router doesnt have to "determine" that it isnt supported, it can > be told. > > In 6.4 you have an extra space between "in- session". > > In 6.10, 6.12, if the ACK shows that the signal was not successfully > processed, what then? > > In 7.1 the first sentence should end after "signals". > > In 7.11 IPv6 Address, one of the sentences says IPv4 instead. Similar is the case with 7.4 (the line above the packet diagram). > In 7.12 and 7.13 for the attached subnet data items, I wondered if > there would be an impact which needs considering, since to withdraw > this subnet you need to send a Destination Down. If this impacts on a > routing process when the destination itself is not down but needs to > be reported down in order to remove the attached subnet information, > is this acceptable? Is it "up to the implementation" to handle this > case gracefully? > > In 7.16, 7.17 and 7.18, I like that you have separated the description > for the data item's use in the Link Characteristic Request signal, > however you now dont have the matching statement that it MAY appear in > Link Characteristic Request, which I think should be there. In 7.18, the words "data item" repeated twice in the first line. In 8.2.3, "If the corresponding Destination Up signal (Section 6.9) for this session did NOT contain a Credit Window Status data item, indicating that credits are to be used on the session, then the Credit Request data item MUST be silently dropped by the receiver." However it seems, only 'Credit Grant' data item is valid in the 'Destination Up' signal (in credit windowing context). So, do we mean, "If the corresponding Destination Up signal (Section 6.9) for this session did NOT contain a *Credit Grant* data item, indicating that credits are *NOT* to be used on the session, then the Credit Request data item MUST be silently dropped by the receiver." Regards, Vignesh > > > > Kind regards, > Victoria. > > On Fri, Apr 17, 2015 at 1:59 PM, Ratliff, Stanley > > wrote: > > Hello Working Group, > > DLEP-09 was posted yesterday, and contains the fixes for issues > brought up in reviews prior to IETF 92. > > With DLEP-09, the authors formally request a 2-week Working Group > Last Call (WGLC). If the 2-week WGLC is granted, Last call > comments would be due by May 1, 2015. > > Regards, > Stan > > ------------------------------------------------------------------------ > > *Stan Ratliff *| Architect, Applied Research > > *VT iDirect *| 13861 Sunrise Valley Drive, Suite 300, Herndon, VA > 20171, USA > > T: +1 703 544-8520 | F: +1 222 123-4567 > > sratliff@idirect.net __| > www.idirect.net > > *Connect with iDirect: *Twitter.com/iDirect > __| Facebook.com/iDirect > ** > > ** > > ** > > *Advancing a Connected World* > > > _______________________________________________ > 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 --------------030108010305050205010500 Content-Type: multipart/related; boundary="------------080304050901080606060407" --------------080304050901080606060407 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Adding my observations inline...

On 04/22/2015 04:19 PM, Victoria Mercieca wrote:
Hi Stan, hi all,

A few comments on DLEP-09:

When DLEP supplies both MAC and IP address of a destination, would it create ARP entries? This is mentioned in Section 2 Assumptions and also in 6.9 Destination Up, where it specifically says "reducing the need for the receiver to probe for any address".

Also in Section 2 Assumptions, you have a statement that any signals not understood should result in session termination, but that data items that are not understood should be ignored. Compare with Section 5 DLEP Message Processing, where it says that unrecognized, invalid or disallowed data items also force termination, and 6.4 which says that any metric data item which is not expected causes termination. I guess the Assumptions just needs updating?

In 3.3 Experimental Signals and Data Items, it becomes clear by the end of this section that we have an Experimental Definition which is a set of signals and data items. I would suggest making this clearer from the start by rewriting the second sentence "The intent is to allow for experimentation with a set of new signals and/or data items,"... but maybe I am being too picky!

In Section 4 Metrics, in the last paragraph, you state that algorithms for utilizing dual context metrics is out of scope. Then in Section 4.5 and 6.5 you say that metrics supplied in Peer signals MUST be set for all destinations.

In Section 4 which is titled Metrics, you then have subsections 4.2 - 4.5 which are about session flow. Should these be a separate Section between 4 and 5? Also, you have subsections for discovery and common flow but not for termination. If you did, it might be a nice place to collect the information about termination due to unrecognized/invalid signals and data items, plus would make this "session flow" section more complete.

In 4.5 you have "[Heartbeat signals]#(sig_heartbeat)".

In 5.1 you have a typo - "bu" instead of "by".

In 6.5 you say that modems that don't track layer 3 addresses SHOULD silently parse and ignore the Peer Update, then the final sentence in the section says a Peer Update MUST be acknowledged by a Peer Update ACK. Also, if a modem does not support layer 3 address tracking, why wouldn't it just send back an ACK with a non-zero status code? Then the router doesnt have to "determine" that it isnt supported, it can be told.

In 6.4 you have an extra space between "in- session".

In 6.10, 6.12, if the ACK shows that the signal was not successfully processed, what then?

In 7.1 the first sentence should end after "signals".

In 7.11 IPv6 Address, one of the sentences says IPv4 instead.

Similar is the case with 7.4 (the line above the packet diagram).

In 7.12 and 7.13 for the attached subnet data items, I wondered if there would be an impact which needs considering, since to withdraw this subnet you need to send a Destination Down. If this impacts on a routing process when the destination itself is not down but needs to be reported down in order to remove the attached subnet information, is this acceptable? Is it "up to the implementation" to handle this case gracefully?

In 7.16, 7.17 and 7.18, I like that you have separated the description for the data item's use in the Link Characteristic Request signal, however you now dont have the matching statement that it MAY appear in Link Characteristic Request, which I think should be there.

In 7.18, the words "data item" repeated twice in the first line.

In 8.2.3,

"If the corresponding Destination Up signal (Section 6.9) for this session did NOT contain a Credit Window Status data item, indicating that credits are to be used on the session, then the Credit Request data item MUST be silently dropped by the receiver."

However it seems, only 'Credit Grant' data item is valid in the 'Destination Up' signal (in credit windowing context).

So, do we mean,

"If the corresponding Destination Up signal (Section 6.9) for this session did NOT contain a *Credit Grant* data item, indicating that credits are *NOT* to be used on the session, then the Credit Request data item MUST be silently dropped by the receiver."

Regards,
Vignesh




Kind regards,
Victoria. 

On Fri, Apr 17, 2015 at 1:59 PM, Ratliff, Stanley <sratliff@idirect.net> wrote:

Hello Working Group,

 

DLEP-09 was posted yesterday, and contains the fixes for issues brought up in reviews prior to IETF 92.

 

With DLEP-09, the authors formally request a 2-week Working Group Last Call (WGLC). If the 2-week WGLC is granted, Last call comments would be due by May 1, 2015.

 

Regards,
Stan

 

Stan Ratliff  |  Architect, Applied Research

VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 123-4567

sratliff@idirect.net  |  www.idirect.net

Connect with iDirect: Twitter.com/iDirect  |  Facebook.com/iDirect

 

Advancing a Connected World

 

 


_______________________________________________
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

--------------080304050901080606060407 Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYH BwcGBwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcI DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAAR CAAaAIMDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8AgpJ+2j8YvgF8cfCug+CfD76X4daa G4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeIP24PijYfEbQNH1G2tte0PS4p 4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/EJfBfytqDeJl0NNNjUMD lhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmvAoYf69zSqN8rafK1 a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4k+FP2vtD0D4e +ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbySKryRMQTG SASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtjLhz9 7zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh 0G98M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C 9LOoSTxa99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl +EWQBrSRmPAwIpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBG f+Wdewfma2Fu/wDgr18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+A HxE8SfFH4ZafrPirwfdeA9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9 R/1B7/8Az+NfoeIEH8PU559aTA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNd AyRiJTGNio/3m+9jtmvl3wB/wWR8f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVV jhQfun61uf8ABOP4s+K/G37dn7Qmja34m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBw BXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfD ss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q/C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhV fzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2khie2kW1vyjxsuCrLtQgg5BANUNf /aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37ygwvyk44pcoH6sfak3Yz3x+NAu VLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeHYPsUszQ2oJKhnPlqX2qW xk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk3rHGDtYbmXAyORzT 5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALMyqB1LEAAkgH4 A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn9595Rhav8A 7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRygfeX w+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP 7Dluls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3 D+WLq4lXVJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E /ma8jFYC0nOlNxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi 9rn7Zfh/XPh54wutJ8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SST zGCgFyAGYgYycADnrwBVe3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8 kWopSavvJ7yfT9NXf56/4KB/sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lN u3ceXjBzx2H7HP7MVv8Ask/s9aH4Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVa K7eZnzZ83+I/2CLrxB/wUK0L46DxZDbwaLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4K RGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7u e9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq 5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6tJNNPAYRIYlKqFRTxGCMgfe5NeZ6r /wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ1MhGB0zX2lRSuB4P+0V+wnpH 7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcqDXGfCL/gnN4h0z45+G/H 3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4Hx/49/4Je65F8WPH fiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4JteHdO/Yd1T4JW+ vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gLSvDHh/8A aI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --------------080304050901080606060407-- --------------030108010305050205010500-- From nobody Thu Apr 30 08:51:15 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF96A1B2CF9 for ; Thu, 30 Apr 2015 08:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 5LJ_pUjBLHp5 for ; Thu, 30 Apr 2015 08:51:11 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799B41B2CF0 for ; Thu, 30 Apr 2015 08:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15549; q=dns/txt; s=iport; t=1430409065; x=1431618665; h=from:to:cc:subject:date:message-id:mime-version; bh=5HDY1zISdcg0Mg4HA0u77HUUqwejLVHBMnziyngBzrM=; b=RrMqUZOVP30IUFnblTOXKnTMeMbnSaymewGofJp5puABn4F1GK86tlF8 B+ADl0LMgpTnaHYNwgFOf3MflfMNhAI13DJB5C7b3Pddrm0YC3kzrp/5V HfSdGeiVIfmYwxEprvaqYDRmroSlnWoXoNSe4eLfDqD6TKi+T8y5Ti2sH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ByBACvTkJV/5RdJa1cgkVHgTTFSgmHV4FWOBQBAQEBAQEBgQqEIwR5EgGBACcEDogwyE8BAQEBAQEEAQEBAQEBHJA9hDQFj0aCJIpIgSODS5EPI4N0gjOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.11,677,1422921600"; d="scan'208,217";a="146022542" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP; 30 Apr 2015 15:51:04 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t3UFp4M4016744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Apr 2015 15:51:04 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.76]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 30 Apr 2015 10:51:04 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-manet-olsrv2-multitopology@tools.ietf.org" Thread-Topic: AD Review of draft-ietf-manet-olsrv2-multitopology Thread-Index: AQHQg112wY785zE83UyKabbZ8ayPuA== Date: Thu, 30 Apr 2015 15:51:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_D167C7A3AB649aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: [manet] AD Review of draft-ietf-manet-olsrv2-multitopology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 15:51:14 -0000 --_000_D167C7A3AB649aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! I have some concerns about the operation in a mixed environment of MT-OLSRv= 2 and non-MT-OLSRv2 routers as explained in Sections 4 and 12. In short, = the operation in a mixed environment needs to at least be clarified probabl= y using stronger language in some places, but there may be some parts where= it has to be rethought (see my comments below). It may be beneficial to h= ave a live conversation about this topic as it may be slower through e-mail= (and it may be that I need help seeing things clearer) =97 if you want to,= please give me some options and we=92ll then summarize for the list. I would like to have at least an agreement from the authors about the path = forward before starting the IETF Last Call. Thanks! Alvaro. Major: 1. Section 3. "It is assumed, but outside the scope of this specificatio= n, that the network layer is able to choose which topology to use for each = packet=85This selection of topology must be consistent, =85This is necessar= y to avoid the possibility of a packet "looping" in the network.=94 While = how the selection is done may be out of scope, being a little stronger abou= t the need for consistency (s/must/MUST) would be nice. 2. Sections 4 and 12. 4 reads: =93..the single link metric used by thes= e non-MT-OLSRv2 routers must be included in the set of link metrics for eac= h OLSRv2 interface of an MT-OLSRv2 router that may be heard on an OLSRv2 in= terface of a non-MT-OLSRv2 router in the MANET=94, and then 12 adds "Note t= hat if there is any possibility that there are any routers not implementing= MT-OLSRv2, then the MANET will be connected, to the maximum extent possibl= e, using the link metric type LINK_METRIC_TYPE.=94 I would think that the= re is always a possibility that non-MT-OLSRv2 routers exist..does this then= mean that the only metric type would be LINK_METRIC_TYPE everywhere? I gu= ess that theoretically you can constrain the movement of nodes so that they= only may be present in a subset of the MANET, but their existence in a ne= twork (as characterized: "any possibility that there are any routers not im= plementing MT-OLSRv2=94) would then seem to cause a specific behavior. 3. Section 12: Related to the consistency in making forwarding decisions= , the text in the last bullet implies that different topologies may be used= to forward a packet in some cases. Even though you also wrote that "All = routers must make the same decision for the same packet." * For example, =93..then routing may work if the first router implem= enting MT-OLSRv2 to receive the packet supports the appropriate link metric= type=94. Just saying that =93routing may work=94 doesn=92t provide a lot = of confidence. What about the other routers in the path? Didn=92t you say= before that the topology selection must be consistent? How do you prevent= looping if the topology used in the first couple of hops may not exist els= ewhere? * "If such a router is the destination, then the packet will never r= each its destination, as the source will not have a suitable routing table = entry for the destination. Network management may be required to ensure th= at the MANET still functions in these cases.=94 How would network manageme= nt ensure that the MANET still works? The obvious answer is to ensure that= the =93base topology=94 exist everywhere, which goes back to my question a= bove about using the link metric type LINK_METRIC_TYPE everywhere. 4. Section 4: "If all routers in the MANET implement MT-OLSRv2, then the= re are no restrictions on how these sets of link metrics are selected.=94 = Isn=92t a minimum restriction the fact that they should somehow be consiste= nt across interfaces? If not then the packets will either not reach their = destination or be forwarded using different topologies. Minor: 1. For clarity while others review it, please change =93RFC XXXX=94 to t= he draft-ietf-manet-tlv-naming reference. The RFC Editor should take care = of fixing the references. 2. Section 1.1 "This specification is published to facilitate collecting= such experience, with the intent that in a reasonable period of time after= the acceptance of this specification as an Experimental RFC (as soon as po= ssible after experimental evidence is collected), an OLSRv2 Multi-Topology = Routing Extension will be proposed for advancement onto Standards Track.=94= How long are a =93reasonable period=94 and =93as soon as possible=94? I = understand what the intent is here, defining the experiment in terms of col= lection of experience is fine, but bounding it with ill-defined (and prone = to all kinds of interpretation) terms doesn=92t help anyone. I would rathe= r you focus on what you want to do (collect experience) and then we can thi= nk about changing the status whenever we=92re ready to do so. Nits: 1. Section 1. s/However in some MANETs it would be desirable to be route= packets/However in some MANETs it would be desirable to be able to route p= ackets --_000_D167C7A3AB649aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!

I have some concerns about the operation in a mixed envir= onment of MT-OLSRv2  and non-MT-= OLSRv2 routers as explained in Sections 4=  and 12.  In short, the operation in a mixed environment nee= ds to at least be clarified probably using stronger language in some places, but there may be some parts where it has to be rethought&n= bsp;(see my commen= ts below).  I= t may be beneficial to have a live conversation about this topic as it may be slower through e-mail (and it may be that&nb= sp;I need help seeing things clearer) =97 if you want to, please give me so= me options and we=92ll then summarize for the list.

I would like to have at least an agreement from the authors about= the path forward before starting the IETF Last Call.

Thanks!

Alvaro.


Major:
  1. Section 3. "= It is assumed, but outside the scope of this specification, that the network layer is able to choose which topology to use for each packet=85This selection of topology must be consistent, =85This is neces= sary to avoid the possibility= of a packet "looping" in the network.=94  While how the sel= ection is done may be out of scope, being a little stronger about the need for consistency (s/must/MUST) would be nice.
  2. = Sections 4 and 12.  4 reads: = =93..the single li= nk metric used by these non-MT-OLSRv2 routers must be included in the set of link metrics for each OLSRv2 interface of an MT-OLSRv2 router that may be he= ard on an OLSRv2 interface of= a non-MT-OLSRv2 router in the MANET=94, and then 12 adds "Not= e that if the= re is any possibility that there are any routers not implementing MT-OLSRv2, then the MANET will be connected, to the maximum extent possible, using the = link metric type LINK_METRIC_= TYPE.=94   I would think that there is always a possibility that non-MT-OLSRv2 routers exist..does this then mean that the= only metric type would be LINK_METRIC_TYPE everywhere?  I guess that theoretically you c= an constrain the movement of nodes so that they only may be  present in a subset of the MANET, but their existence in a networ= k (as characterized: "any pos= sibility that there are any routers not implementing MT-OLSRv2=94) would th= en seem to cause a specific behavior.   
  3. Section 12: Related to the consistency in making&n= bsp;forwarding decisions, the text in the last bullet implies that differen= t topologies may be used to forward a packet in some cases.  Even=  though you also wrote  that "All routers must make the same decision for the same packet."
    • For example, =93..then routing may work if the&nbs= p;first router imp= lementing MT-OLSRv2 to receive the packet supports the appropriate link metric type=94.  Just saying that =93routin= g may work=94 doesn=92t provide a lot of confidence.  What about the o= ther routers in the path?  Didn=92t you say before that the topology s= election must be consistent?  How do you prevent looping if the topology used in the first couple of hops may not exist elsewhere?<= /li>
    • "If such a router is the destination, then the= packet will never reach its destination, as the source will not have a suitable routing table entry for the destination.  Network management = may be required to= ensure that the MANET still functions in these cases.=94  How would network management ensure that the MANET still w= orks?  The obvious answer is to ensure that the =93base topology= =94 exist everywhere, which g= oes back to my question above about using the link metric type LINK_METRIC_TYPE= everywhere.
  4. Section 4: "If all routers in the MANET implement MT-OLSRv= 2, then there are no restrictions on how these sets of link metrics are selected.=94  Isn=92t a minimum restriction = the fact that they should somehow be consistent across interfaces?  If= not then the packets will either not reach their destination or be forward= ed using different topologies.

Minor:
  1. For clarity while others review it, please change =93RFC XXXX=94 to the dra= ft-ietf-manet-tlv-naming reference.  The RFC Editor should take care o= f fixing the references.
  2. Section = 1.1 "This spe= cification is published to facilitate collecting such experience, with the intent <= /span>that in a reasonable period of time after the acceptance of this specification as an Experim= ental RFC (as soon as possible after experimental evidence is collected), an OLSRv2 Multi-Topology Routing Extension will be proposed for advancement onto Standar= ds Track.=94  How long are a =93reasonable period=94 and =93= as soon as possible=94?  I understand what the intent is here, definin= g the experiment in terms of collection of experience is fine, but bounding = it with ill-defined (and prone to all kinds of interpretation) terms doesn= =92t help anyone.  I would rather you focus on what you want to do (co= llect experience) and then we can think about changing the status whenever we=92re ready to do so.
    3. Nits:
    1. Section 1. s/However in some MANETs it would be desirable to be route p= ackets/However in some MANETs it would be desirable to be able to route pac= kets
    --_000_D167C7A3AB649aretanaciscocom_--
Hi Stan, hi all,

From Section 4.3 and 4= .5, it's pretty clear that heartbeats begin to flow _after_ a Peer Init= ialization ACK is received with a success status code, so no heartbeat-rela= ted timers would be started on the router until the Peer Initialization ACK= is received. However, the modem receiving the Peer Initialization would st= art up the heartbeat timer when it sends the Peer Initialization ACK.=C2=A0=

In case the ACK was lost, the router should have = some timeout behaviour on the Peer Initialization, like David Wiggins says.= I think your suggested text effectively says this but in a much more compl= icated way?

Also, if the router is not "in-se= ssion", because no=C2=A0Peer Initialization=C2=A0ACK was received, wou= ld the router respond to any other signals from the modem (including Heartb= eat) with a Peer Termination anyway? You mention earlier in section 4.4 tha= t any other signals received when expecting the Peer Offer would be silentl= y dropped, but you dont have a similar comment for the Initialization signa= ls. Sending a Peer Termination would fit with the other comments in the doc= ument that any unexpected/invalid signal should cause a termination, and yo= u have a status code for this too. So the problem would be resolved by Peer= Termination when any other signal is received from the modem. Alternativel= y, but I suppose the delay is undesirable, the modem will terminate the ses= sion after 2 of its own heartbeat intervals anyway, since the router will n= ot send any DLEP signals while waiting for the Peer Initialization ACK.

Kind regards,
Victoria.


On Tue, Ap= r 21, 2015 at 5:51 PM, Ratliff, Stanley <sratliff@idirect.net> wrote:

David, <= /span>

=C2=A0

I=E2=80=99m OK with do= ing it that way as well.

=C2=A0

Are there other opinio= ns out there? Send =E2=80=98em if you got =E2=80=98em =E2=80=93 I=E2=80=99d= like to close on this.

=C2=A0

Regards,=

Stan

=C2=A0

=C2=A0

From: Wiggins, David - 0665 - MITLL [mailto:<= a href=3D"mailto:David.Wiggins@ll.mit.edu" target=3D"_blank">David.Wiggins@= ll.mit.edu]
Sent: Tuesday, April 21, 2015 12:45 PM
To: Ratliff, Stanley; manet@ietf.org
Subject: RE: DLEP-09 Last Call issue

=C2=A0

Several other signals that expect ACKs have words like: =E2=80=9CThe =
sender of the Destination Up signal is free to define its retry heuristics =
in event of a timeout.=E2=80=9D=C2=A0 I see that Peer Initialization does n=
ot say this, but perhaps it should.=C2=A0 Wouldn=E2=80=99t that fix the pro=
blem, and be more in line with the rest of the draft?<=
/pre>

=C2=A0


David


=C2=A0


=C2=A0






From: manet [mailto:manet-bounces@ietf.org]
On Behalf Of Ratliff, Stanley

Sent: Tuesday, April 21, 2015 10:14 AM

To: manet@ietf.o=
rg

Subject: [manet] DLEP-09 Last Call issue






=C2=A0


Working Group Participants, 


=C2=A0


It was noted during a private discussion that there =
could be an issue with DLEP and Heartbeats. Specifically, the scenario ment=
ioned was:



=C2=A0


1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Peer Discovery/Peer Offer processing takes place with no errors or i=
ssues.


2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Router uses information received from Peer Offer, and connects a soc=
ket to the modem. Router sends Peer Initialization, with a Heartbeat TLV.


3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Modem, for whatever reason, *fails* to respond to Peer Initia=
lization.



=C2=A0


The question/issue is that Heartbeats (if used at al=
l) aren=E2=80=99t fully established at that point, since they require the P=
eer Initialization/Peer Initialization ACK sequence. So what to do?



=C2=A0


Here is the proposed fix =E2=80=93 the following tex=
t will be inserted into the Peer Initialization section:



=C2=A0


"It should be noted that Heartbeats (if used) a=
re not fully established until both the Peer Initialization and Peer Initia=
lization ACK messages have been sent and successfully processed by the appr=
opriate recipient. This leaves the possibility
 for timing issues to occur (e.g. a Peer Initialization message is sent fro=
m router to modem, but no Peer Initialization ACK is received). Prior to th=
e establishment of the Heartbeat interval, heuristics for determining the a=
mount of time to wait for a specific
 message, or to declare the session inoperative, are left to implementers. =
However, it is recommended that an implementation select some reasonable mu=
ltiple of its own proposed Heartbeat interval in these cases, in order to m=
inimize the number of inputs to
 the implementation."


=C2=A0


=C2=A0


Other opinions are welcome. 


=C2=A0


Regards,


Stan










Stan Ratliff=C2=A0
|=C2=A0 Architect, Applied Research



VT iDirect=C2=A0
|=C2=A0 13861 Sunrise Valley Drive, Suite 300, Hernd=
on, VA 20171, USA



T: +1 703 544-8520=C2=A0 |=C2=A0 F: +1 222 123-4567<=
/u>



sratliff@idirect.net=C2=A0
|=C2=A0 www.idirect.net



Connect with iDirect:
Twitter.com/iDirect=C2=A0
|=C2=A0
Facebook.com/iDirect=




=C2=A0







Advancing a Connected World


=C2=A0


=C2=A0

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


--047d7b3a85a08e01d305144d7176-- --047d7b3a85a08e01d605144d7177 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 688afd9dccc3dd8f_0.0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --047d7b3a85a08e01d605144d7177-- From nobody Wed Apr 22 03:49:23 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CC31B340B for ; Wed, 22 Apr 2015 03:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 mRNvMb3KMDWy for ; Wed, 22 Apr 2015 03:49:19 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::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 B9DE81B3407 for ; Wed, 22 Apr 2015 03:49:15 -0700 (PDT) Received: by labbd9 with SMTP id bd9so171688574lab.2 for ; Wed, 22 Apr 2015 03:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Ew/jbQAojKIjHOWJpxRIRQBApzNt9oGA+kXLhs0DLkY=; b=puKPbUxfD6kn9epTaCVEnWYitvpvYJV2Ej35O81dqyZaFykqJersm3Quy0mQPuSDgk pHtL+sgYSaFGZpsjXTO2DnMpOZXhs3tjHV1gxedhCUhsW3JSDmEJqdO/az7Ra9QtwlMI 75P9OK/OS/M44LCmyFioLDGsZbQ7Q3H8OFT3J2txtr+irbAKgzmMxVaWLtQyCLKAg4MU bfUj3ikTvN1VepuAzCLN+K/UqWGBaJlcsrWYI4j3HWZ/Jizw4wEC5DXBPJ7zcKiCGBWw 9oyT8JW/o1BrXVjSnkwSM/pT/cNrB1BxKWwdyyFnfKuDKt0HcG0HwGNE/zAzX2aQ423K BiDA== MIME-Version: 1.0 X-Received: by 10.152.36.227 with SMTP id t3mr24536047laj.12.1429699754002; Wed, 22 Apr 2015 03:49:14 -0700 (PDT) Received: by 10.112.252.4 with HTTP; Wed, 22 Apr 2015 03:49:13 -0700 (PDT) In-Reply-To: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> References: <970cf81ffef1443eb2f59f584f0acd6b@VAUSDITCHM2.idirect.net> Date: Wed, 22 Apr 2015 11:49:13 +0100 Message-ID: From: Victoria Mercieca To: "Ratliff, Stanley" , manet@ietf.org Content-Type: multipart/related; boundary=089e0158aefef95e0805144de979 Archived-At: Subject: Re: [manet] DLEP-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 10:49:21 -0000 --089e0158aefef95e0805144de979 Content-Type: multipart/alternative; boundary=089e0158aefef95e0505144de978 --089e0158aefef95e0505144de978 Content-Type: text/plain; charset=UTF-8 Hi Stan, hi all, A few comments on DLEP-09: When DLEP supplies both MAC and IP address of a destination, would it create ARP entries? This is mentioned in Section 2 Assumptions and also in 6.9 Destination Up, where it specifically says "reducing the need for the receiver to probe for any address". Also in Section 2 Assumptions, you have a statement that any signals not understood should result in session termination, but that data items that are not understood should be ignored. Compare with Section 5 DLEP Message Processing, where it says that unrecognized, invalid or disallowed data items also force termination, and 6.4 which says that any metric data item which is not expected causes termination. I guess the Assumptions just needs updating? In 3.3 Experimental Signals and Data Items, it becomes clear by the end of this section that we have an Experimental Definition which is a set of signals and data items. I would suggest making this clearer from the start by rewriting the second sentence "The intent is to allow for experimentation with a set of new signals and/or data items,"... but maybe I am being too picky! In Section 4 Metrics, in the last paragraph, you state that algorithms for utilizing dual context metrics is out of scope. Then in Section 4.5 and 6.5 you say that metrics supplied in Peer signals MUST be set for all destinations. In Section 4 which is titled Metrics, you then have subsections 4.2 - 4.5 which are about session flow. Should these be a separate Section between 4 and 5? Also, you have subsections for discovery and common flow but not for termination. If you did, it might be a nice place to collect the information about termination due to unrecognized/invalid signals and data items, plus would make this "session flow" section more complete. In 4.5 you have "[Heartbeat signals]#(sig_heartbeat)". In 5.1 you have a typo - "bu" instead of "by". In 6.5 you say that modems that don't track layer 3 addresses SHOULD silently parse and ignore the Peer Update, then the final sentence in the section says a Peer Update MUST be acknowledged by a Peer Update ACK. Also, if a modem does not support layer 3 address tracking, why wouldn't it just send back an ACK with a non-zero status code? Then the router doesnt have to "determine" that it isnt supported, it can be told. In 6.4 you have an extra space between "in- session". In 6.10, 6.12, if the ACK shows that the signal was not successfully processed, what then? In 7.1 the first sentence should end after "signals". In 7.11 IPv6 Address, one of the sentences says IPv4 instead. In 7.12 and 7.13 for the attached subnet data items, I wondered if there would be an impact which needs considering, since to withdraw this subnet you need to send a Destination Down. If this impacts on a routing process when the destination itself is not down but needs to be reported down in order to remove the attached subnet information, is this acceptable? Is it "up to the implementation" to handle this case gracefully? In 7.16, 7.17 and 7.18, I like that you have separated the description for the data item's use in the Link Characteristic Request signal, however you now dont have the matching statement that it MAY appear in Link Characteristic Request, which I think should be there. Kind regards, Victoria. On Fri, Apr 17, 2015 at 1:59 PM, Ratliff, Stanley wrote: > Hello Working Group, > > > > DLEP-09 was posted yesterday, and contains the fixes for issues brought up > in reviews prior to IETF 92. > > > > With DLEP-09, the authors formally request a 2-week Working Group Last > Call (WGLC). If the 2-week WGLC is granted, Last call comments would be due > by May 1, 2015. > > > > Regards, > Stan > > > ------------------------------ > > *Stan Ratliff *| Architect, Applied Research > > *VT iDirect *| 13861 Sunrise Valley Drive, Suite 300, Herndon, VA > 20171, USA > > T: +1 703 544-8520 | F: +1 222 123-4567 > > sratliff@idirect.net | www.idirect.net > > *Connect with iDirect: *Twitter.com/iDirect > | Facebook.com/iDirect > > > > *Advancing a Connected World* > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --089e0158aefef95e0505144de978 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stan, hi all,

A few comments on DLEP= -09:

When DLEP supplies both MAC and IP address of= a destination, would it create ARP entries? This is mentioned in Section 2= Assumptions and also in 6.9 Destination Up, where it specifically says &qu= ot;reducing the need for the receiver to probe for any address".
=

Also in Section 2 Assumptions, you have a statement tha= t any signals not understood should result in session termination, but that= data items that are not understood should be ignored. Compare with Section= 5 DLEP Message Processing, where it says that unrecognized, invalid or dis= allowed data items also force termination, and 6.4 which says that any metr= ic data item which is not expected causes termination. I guess the Assumpti= ons just needs updating?

In 3.3 Experimental Signa= ls and Data Items, it becomes clear by the end of this section that we have= an Experimental Definition which is a set of signals and data items. I wou= ld suggest making this clearer from the start by rewriting the second sente= nce "The intent is to allow for experimentation with a set of new sign= als and/or data items,"... but maybe I am being too picky!
<= br>
In Section 4 Metrics, in the last paragraph, you state that a= lgorithms for utilizing dual context metrics is out of scope. Then in Secti= on 4.5 and 6.5 you say that metrics supplied in Peer signals MUST be set fo= r all destinations.

In Section 4 which is titled M= etrics, you then have subsections 4.2 - 4.5 which are about session flow. S= hould these be a separate Section between 4 and 5? Also, you have subsectio= ns for discovery and common flow but not for termination. If you did, it mi= ght be a nice place to collect the information about termination due to unr= ecognized/invalid signals and data items, plus would make this "sessio= n flow" section more complete.

In 4.5 you hav= e "[Heartbeat signals]#(sig_heartbeat)".

In 5.1 you have a typo - "bu" instead of "by".

In 6.5 you say that modems that don't track layer 3 a= ddresses SHOULD silently parse and ignore the Peer Update, then the final s= entence in the section says a Peer Update MUST be acknowledged by a Peer Up= date ACK. Also, if a modem does not support layer 3 address tracking, why w= ouldn't it just send back an ACK with a non-zero status code? Then the = router doesnt have to "determine" that it isnt supported, it can = be told.

In 6.4 you have an extra space between &q= uot;in- session".

In 6.10, 6.12, if the ACK s= hows that the signal was not successfully processed, what then?
<= br>
In 7.1 the first sentence should end after "signals"= ;.

In 7.11 IPv6 Address, one of the sentences says= IPv4 instead.

In 7.12 and 7.13 for the attached s= ubnet data items, I wondered if there would be an impact which needs consid= ering, since to withdraw this subnet you need to send a Destination Down. I= f this impacts on a routing process when the destination itself is not down= but needs to be reported down in order to remove the attached subnet infor= mation, is this acceptable? Is it "up to the implementation" to h= andle this case gracefully?

In 7.16, 7.17 and 7.18= , I like that you have separated the description for the data item's us= e in the Link Characteristic Request signal, however you now dont have the = matching statement that it MAY appear in Link Characteristic Request, which= I think should be there.



Kind regards,
Victoria.=C2=A0

On Fri, Apr 17, 2015 at 1:59 PM, Ra= tliff, Stanley <sratliff@idirect.net> wrote:

Hello Working Group,

=C2=A0

DLEP-09 was posted yesterday, and contains the fixes= for issues brought up in reviews prior to IETF 92.

=C2=A0

With DLEP-09, the authors formally request a 2-week = Working Group Last Call (WGLC). If the 2-week WGLC is granted, Last call co= mments would be due by May 1, 2015.

=C2=A0

Regards,
Stan

=C2=A0

Stan Ratliff=C2=A0 |=C2=A0 Architect, Applied Research

VT iDirect=C2=A0 |=C2=A0 13861 Sunrise Valley Drive, Suite 300, Hernd= on, VA 20171, USA

T: +1 703 544-8520=C2=A0 |=C2=A0 F: +1 222 123-4567<= /u>

sratliff@idirect.net=C2=A0 |=C2=A0 www.idirect.net

Connect with iDirect: Twitter.com/iDirect=C2=A0 |=C2=A0 Facebook.com/iDirect=

=C2=A0

Advancing a Connected World

=C2=A0

=C2=A0


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


--089e0158aefef95e0505144de978-- --089e0158aefef95e0805144de979 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: c3b76da6ff01d313_0.0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --089e0158aefef95e0805144de979-- From nobody Wed Apr 22 20:58:26 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD261ACEAB for ; Wed, 22 Apr 2015 20:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 pWeWKtDGq_Pq for ; Wed, 22 Apr 2015 20:58:23 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id A4A241ACE7E for ; Wed, 22 Apr 2015 20:58:16 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t3N3wEjR029060 for ; Wed, 22 Apr 2015 23:58:14 -0400 From: "Cheng, Bow-Nan - 0665 - MITLL" To: "manet@ietf.org" Thread-Topic: DLEP and Peer MAC addresses Thread-Index: AQHQfXm48j8EE+e6mUyS4/lDjrru4g== Date: Thu, 23 Apr 2015 03:58:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [172.26.145.231] Content-Type: multipart/alternative; boundary="_000_D15DE60F17C6Fbchengllmitedu_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-23_02:2015-04-22,2015-04-23,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504230048 Archived-At: Subject: [manet] DLEP and Peer MAC addresses X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 03:58:25 -0000 --_000_D15DE60F17C6Fbchengllmitedu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi everyone, I remember a while ago some discussion about whether peer MAC addresses cou= ld be passed from the DLEP router to the DLEP modem/radio and couldn=92t fi= nd/remember what the conclusion was. One of the requirements of DLEP in destination messages is to pass the remo= te router=92s MAC address to the locally connected DLEP router. While defin= ition of how to get this remote router=92s MAC over-the-air is beyond the s= cope of DLEP, I=92m wondering if it makes sense to enable the local DLEP mo= dem peer to know the locally connected DLEP router peer=92s MAC address. Th= is perhaps could be achieved by inclusion as an OPTIONAL field in the Peer = Initialization. I would say that you could ARP on the DLEP TCP session IP, but that would r= equire exposing this externally to the DLEP client and then writing some ex= tra code (outside of DLEP) to do the ARP or check neighbor tables. It seems= like an extra step with additional code when DLEP should very well know th= is information. Any thoughts on this? Thanks -Bow-Nan --_000_D15DE60F17C6Fbchengllmitedu_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi everyone,

I remember a while ago some discussion about whether peer MAC addresse= s could be passed from the DLEP router to the DLEP modem/radio and couldn= =92t find/remember what the conclusion was. 

One of the requirements of DLEP in destination messages is to pass the= remote router=92s MAC address to the locally connected DLEP router. While = definition of how to get this remote router=92s MAC over-the-air is beyond = the scope of DLEP, I=92m wondering if it makes sense to enable the local DLEP modem peer to know the locally con= nected DLEP router peer=92s MAC address. This perhaps could be achieved by = inclusion as an OPTIONAL field in the Peer Initialization. 

I would say that you could ARP on the DLEP TCP session IP, but that wo= uld require exposing this externally to the DLEP client and then writing so= me extra code (outside of DLEP) to do the ARP or check neighbor tables. It = seems like an extra step with additional code when DLEP should very well know this information. 

Any thoughts on this? Thanks

-Bow-Nan
--_000_D15DE60F17C6Fbchengllmitedu_-- From nobody Wed Apr 22 23:43:21 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091701ACEE1 for ; Wed, 22 Apr 2015 23:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 NNGziL5JVZVP for ; Wed, 22 Apr 2015 23:43:18 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::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 8AC981AC43D for ; Wed, 22 Apr 2015 23:43:18 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so5286819wic.1 for ; Wed, 22 Apr 2015 23:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CvIiZpJ3qUSVx/GxgqzrLCswurnBO+Clu8qlhyAmK6Y=; b=WJGGwbyKlCbWdWAALs6kwTgaXAZm1TO23xmYPlKb6LKTuA2/BVQu7JnNuX1xX7frM9 6g/tqr+hXY3zXF5q4CQFd+Q8WilIkci/cEKO9Ht2Y5QUuwfCywkXo+0yI/MTAuXacTnX q0iC6qWuxg2BzIbSaree+aDcOiHgNlR3iNE1+87an/afJa04k2aW7T4QaiVVIQwT8NZF pD4byc5FrLj4jNSWCIAGnVBzcy2ynlaqnfILlF6RdeZzSiVQ5etk7JE/fOG5gwzvMpgB U8IjQYc/EHLOYRMxCrY8CbbAt3GMJLkbLoiuFgmjTtJ4TkgGNVnXIXAP1r5VHSiXM/M4 qFJw== X-Received: by 10.180.103.3 with SMTP id fs3mr12607054wib.14.1429771397319; Wed, 22 Apr 2015 23:43:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Wed, 22 Apr 2015 23:42:57 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Thu, 23 Apr 2015 08:42:57 +0200 Message-ID: To: "Cheng, Bow-Nan - 0665 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP and Peer MAC addresses X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 06:43:20 -0000 On Thu, Apr 23, 2015 at 5:58 AM, Cheng, Bow-Nan - 0665 - MITLL wrote: > Hi everyone, > > I remember a while ago some discussion about whether peer MAC addresses > could be passed from the DLEP router to the DLEP modem/radio and couldn= =E2=80=99t > find/remember what the conclusion was. I think this was me, trying to get Wifi IBSS (adhoc) mode working for DLEP... because IBSS is not really capable of bridging, it would only work if the MAC address of your router is the same as the MAC of your wifi card. Long story short: don't use IBSS mode, use 802.11s with deactivated forwarding! It gives you everything IBSS mode has, it plays nice with your wifi hardware (no global TSF sync) and it supports bridging. > One of the requirements of DLEP in destination messages is to pass the > remote router=E2=80=99s MAC address to the locally connected DLEP router.= While > definition of how to get this remote router=E2=80=99s MAC over-the-air is= beyond the > scope of DLEP, I=E2=80=99m wondering if it makes sense to enable the loca= l DLEP > modem peer to know the locally connected DLEP router peer=E2=80=99s MAC a= ddress. > This perhaps could be achieved by inclusion as an OPTIONAL field in the P= eer > Initialization. You could also just look into the MAC header of the incoming UDP or TCP packets from the router. Or you look into your local ARP table after you established the TCP session... at the point you are unicasting between radio and router, so both know each others MAC address. > I would say that you could ARP on the DLEP TCP session IP, but that would > require exposing this externally to the DLEP client and then writing some > extra code (outside of DLEP) to do the ARP or check neighbor tables. It > seems like an extra step with additional code when DLEP should very well > know this information. Your OS already knows the MAC, otherwise the TCP session will not work. Henning Rogge From Deepak.Lal@ultra-tcs.com Thu Apr 23 07:49:30 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD961A6F33 for ; Thu, 23 Apr 2015 07:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 utdONij4uuSk for ; Thu, 23 Apr 2015 07:49:28 -0700 (PDT) Received: from mail.ultra-tcs.com (mx1.ultra-tcs.com [207.253.158.244]) by ietfa.amsl.com (Postfix) with ESMTP id 196851AC3BE for ; Thu, 23 Apr 2015 07:49:11 -0700 (PDT) X-ASG-Debug-ID: 1429800550-03a3c40f4f161870001-Rp4q3q Received: from SRVEXCH1.ultratcs.ca ([172.20.63.185]) by mail.ultra-tcs.com with ESMTP id oWoh4e5x60OxzEcz for ; Thu, 23 Apr 2015 10:49:10 -0400 (EDT) X-Barracuda-Envelope-From: Deepak.Lal@Ultra-TCS.com Received: from SRVEXCH1.ultratcs.ca ([fe80::6de2:32ff:bbe1:4b9a]) by SRVEXCH1.ultratcs.ca ([fe80::6de2:32ff:bbe1:4b9a%10]) with mapi id 14.02.0387.000; Thu, 23 Apr 2015 10:49:08 -0400 From: "Lal, Deepak (MTL)" To: "manet@ietf.org" Thread-Topic: Require clarification(draft-ietf-manet-dlep-09 vs RFC 4938/RFC5578) X-ASG-Orig-Subj: Require clarification(draft-ietf-manet-dlep-09 vs RFC 4938/RFC5578) Thread-Index: AdB91KaFoYVDinh1SVeY/8oo3fZEZQ== Date: Thu, 23 Apr 2015 14:49:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [200.200.70.21] Content-Type: multipart/alternative; boundary="_000_B86BD0313CB6A14D9566865A2CF36DC371EDC379SRVEXCH1ultratc_" MIME-Version: 1.0 X-Barracuda-Connect: UNKNOWN[172.20.63.185] X-Barracuda-Start-Time: 1429800550 X-Barracuda-URL: http://172.20.128.4:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ultra-tcs.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18268 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [manet] Require clarification(draft-ietf-manet-dlep-09 vs RFC 4938/RFC5578) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 15:05:35 -0000 --_000_B86BD0313CB6A14D9566865A2CF36DC371EDC379SRVEXCH1ultratc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not clear about the distinction. Does MANET-DLEP-09 supersede the PPPo= E based RFC4938/RFC5578 implementations? There is no mention of Credit Flows, etc. on MANET-DLEP-09. Thank you ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------------------=0D This e-mail from Ultra Electronics and any attachments to it are confidenti= al to the intended recipient and may also be privileged.=0D If you have received it in error please notify the sender and delete it fro= m your system.=0D If you are not the intended recipient you must not copy it or use it for an= y purpose nor disclose or distribute its contents to any other person.=0D All communications may be subject to interception or monitoring for operati= onal and/or security purposes.=0D Please rely on your own virus checking as the sender cannot accept any liab= ility for any damage arising from any bug or virus infection.=0D =0D =0D Ce courriel de Ultra Electronics est destine a la personne a laquelle il es= t adresse et peut contenir des renseignements privilegies et confidentiels.= =0D Si vous avez recu ce courriel par erreur, veuillez aviser l'expediteur et l= 'effacer de votre systeme. =0D Si vous n'etes pas le destinataire, vous ne devez ni copier, ni l'utiliser = pour quel qu'usage que ce soit, ni le faire suivre a d'autres.=0D Toutes les communications sont assujetties a une surveillance et/ou interce= ption pour des besoins operationnels et/ou de securite.=0D Vous etes tenu de vous fier a votre anti-virus car l'expediteur n'acceptera= aucune responsabilite des dommages causes par un virus ou un bogue.=0D ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------------------=0D --_000_B86BD0313CB6A14D9566865A2CF36DC371EDC379SRVEXCH1ultratc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not clear about the distinction. Does MANET-DLE= P-09 supersede the PPPoE based RFC4938/RFC5578 implementations?<= /p>

There is no mention of Credit Flows, etc. on MANET-D= LEP-09.

 

Thank you

 


-----------------------------------------------------------------------= ---------------------------------------------------------------------------= -----------------------------------------------------
=0D This e-mail from Ultra Electronics and any attachments to it are confidenti= al to the intended recipient and may also be privileged.=0D If you have received it in error please notify the sender and delete it fro= m your system.=0D If you are not the intended recipient you must not copy it or use it for an= y purpose nor disclose or distribute its contents to any other person.=0D All communications may be subject to interception or monitoring for operati= onal and/or security purposes.=0D Please rely on your own virus checking as the sender cannot accept any liab= ility for any damage arising from any bug or virus infection.=0D
=0D
=0D Ce courriel de Ultra Electronics est destine a la personne a laquelle il es= t adresse et peut contenir des renseignements privilegies et confidentiels.= =0D Si vous avez recu ce courriel par erreur, veuillez aviser l'expediteur et l= 'effacer de votre systeme. =0D Si vous n'etes pas le destinataire, vous ne devez ni copier, ni l'utiliser = pour quel qu'usage que ce soit, ni le faire suivre a d'autres.=0D Toutes les communications sont assujetties a une surveillance et/ou interce= ption pour des besoins operationnels et/ou de securite.=0D Vous etes tenu de vous fier a votre anti-virus car l'expediteur n'acceptera= aucune responsabilite des dommages causes par un virus ou un bogue.=0D
=0D ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------------------=0D   ­­   --_000_B86BD0313CB6A14D9566865A2CF36DC371EDC379SRVEXCH1ultratc_-- From nobody Thu Apr 23 08:19:54 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A281AC418 for ; Thu, 23 Apr 2015 08:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7wf9gm2YxJIc for ; Thu, 23 Apr 2015 08:19:50 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id BEBBF1AC3EC for ; Thu, 23 Apr 2015 08:19:24 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.201 as permitted sender) identity=mailfrom; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.201; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.11,631,1422939600"; d="scan'208,217";a="6920027" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.201]) by ironport2.idirect.net with ESMTP; 23 Apr 2015 11:19:15 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM1.idirect.net (10.250.250.201) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 23 Apr 2015 11:19:14 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Thu, 23 Apr 2015 11:19:14 -0400 From: "Ratliff, Stanley" To: "Lal, Deepak (MTL)" , "manet@ietf.org" Thread-Topic: [manet] Require clarification(draft-ietf-manet-dlep-09 vs RFC 4938/RFC5578) Thread-Index: AdB91KaFoYVDinh1SVeY/8oo3fZEZQAA/CzQ Date: Thu, 23 Apr 2015 15:19:13 +0000 Message-ID: <7c4221d759654ccca4014812ddcc777b@VAUSDITCHM2.idirect.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/alternative; boundary="_000_7c4221d759654ccca4014812ddcc777bVAUSDITCHM2idirectnet_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] Require clarification(draft-ietf-manet-dlep-09 vs RFC 4938/RFC5578) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 15:19:53 -0000 --_000_7c4221d759654ccca4014812ddcc777bVAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Deepak, DLEP doesn't supersede RFC5578. RFC5578 is for PPPoE-based connections betw= een router and radio. DLEP specifies a TCP-based connection, with UDP used = for discovery. And I believe the Credit flows *are* documented in DLEP, as = an extension. Regards, Stan From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lal, Deepak (MTL) Sent: Thursday, April 23, 2015 10:49 AM To: manet@ietf.org Subject: [manet] Require clarification(draft-ietf-manet-dlep-09 vs RFC 4938= /RFC5578) I am not clear about the distinction. Does MANET-DLEP-09 supersede the PPPo= E based RFC4938/RFC5578 implementations? There is no mention of Credit Flows, etc. on MANET-DLEP-09. Thank you ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------------------------------------------- This e-mail from Ultra Electronics and any attachments to it are confidenti= al to the intended recipient and may also be privileged. If you have receiv= ed it in error please notify the sender and delete it from your system. If = you are not the intended recipient you must not copy it or use it for any p= urpose nor disclose or distribute its contents to any other person. All com= munications may be subject to interception or monitoring for operational an= d/or security purposes. Please rely on your own virus checking as the sende= r cannot accept any liability for any damage arising from any bug or virus = infection. Ce courriel de Ultra Electronics est destine a la personne a laquelle il es= t adresse et peut contenir des renseignements privilegies et confidentiels.= Si vous avez recu ce courriel par erreur, veuillez aviser l'expediteur et = l'effacer de votre systeme. Si vous n'etes pas le destinataire, vous ne dev= ez ni copier, ni l'utiliser pour quel qu'usage que ce soit, ni le faire sui= vre a d'autres. Toutes les communications sont assujetties a une surveillan= ce et/ou interception pour des besoins operationnels et/ou de securite. Vou= s etes tenu de vous fier a votre anti-virus car l'expediteur n'acceptera au= cune responsabilite des dommages causes par un virus ou un bogue. ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------------------------------------------- =20 --_000_7c4221d759654ccca4014812ddcc777bVAUSDITCHM2idirectnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Deepak,

 

DLEP doesn’t sup= ersede RFC5578. RFC5578 is for PPPoE-based connections between router and r= adio. DLEP specifies a TCP-based connection, with UDP used for discovery. A= nd I believe the Credit flows *are* documented in DLEP, as an extension.

 

Regards,
Stan

 

From: manet [mailto:manet-bounces@ietf.org] <= b>On Behalf Of Lal, Deepak (MTL)
Sent: Thursday, April 23, 2015 10:49 AM
To: manet@ietf.org
Subject: [manet] Require clarification(draft-ietf-manet-dlep-09 vs R= FC 4938/RFC5578)

 

I am not clear about the distinction. Does MANET-DLE= P-09 supersede the PPPoE based RFC4938/RFC5578 implementations?<= /p>

There is no mention of Credit Flows, etc. on MANET-D= LEP-09.

 

Thank you

 


---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------------------
This e-mail from Ultra Electronics and any attachments to it are confidenti= al to the intended recipient and may also be privileged. If you have receiv= ed it in error please notify the sender and delete it from your system. If = you are not the intended recipient you must not copy it or use it for any purpose nor disclose or distribute = its contents to any other person. All communications may be subject to inte= rception or monitoring for operational and/or security purposes. Please rel= y on your own virus checking as the sender cannot accept any liability for any damage arising from any bug= or virus infection.

Ce courriel de Ultra Electronics est destine a la personne a laquelle il es= t adresse et peut contenir des renseignements privilegies et confidentiels.= Si vous avez recu ce courriel par erreur, veuillez aviser l'expediteur et = l'effacer de votre systeme. Si vous n'etes pas le destinataire, vous ne devez ni copier, ni l'utiliser pour qu= el qu'usage que ce soit, ni le faire suivre a d'autres. Toutes les communic= ations sont assujetties a une surveillance et/ou interception pour des beso= ins operationnels et/ou de securite. Vous etes tenu de vous fier a votre anti-virus car l'expediteur n'accepter= a aucune responsabilite des dommages causes par un virus ou un bogue.
---------------------------------------------------------------------------= ---------------------------------------------------------------------------= -------------------------------------------------   ­­&nb= sp; 

--_000_7c4221d759654ccca4014812ddcc777bVAUSDITCHM2idirectnet_-- From james.a.stevens@rockwellcollins.com Thu Apr 23 08:48:45 2015 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E751B2FE8 for ; Thu, 23 Apr 2015 08:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.288 X-Spam-Level: X-Spam-Status: No, score=-6.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 20K93S5tLkva for ; Thu, 23 Apr 2015 08:48:44 -0700 (PDT) Received: from da1vs01.rockwellcollins.com (da1vs01.rockwellcollins.com [205.175.227.27]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA451B3008 for ; Thu, 23 Apr 2015 08:48:16 -0700 (PDT) X-RC-All-From: , 205.175.227.20, No hostname, james.a.stevens@rockwellcollins.com, "James A. (Jim) Stevens" , , X-RC-Attachments: , , X-RC-RemoteIP: 205.175.227.20 X-RC-RemoteHost: No hostname X-RC-IP-Hostname: da1ip01.rockwellcollins.com X-RC-IP-MID: 9698040 X-RC-IP-Group: GOOGLE_RELAYED X-RC-IP-Policy: $GOOGLE_RELAYED X-RC-IP-SBRS: None Received: from unknown (HELO mail-wg0-f52.google.com) ([205.175.227.20]) by da1vs01.rockwellcollins.com with ESMTP/TLS/RC4-SHA; 23 Apr 2015 10:48:15 -0500 Received: by wgyo15 with SMTP id o15so22918255wgy.2 for ; Thu, 23 Apr 2015 08:48:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=5VCkadRbbXdnO9HQxLTQV+fJxv9avlO1Yl7TtJCBue8=; b=YbopCLvlOBNNPIszNGkuqBszh0p0gwLQBDF3rJQ4SqLKoLUTNxiqJYu+9hXCp9/0mz npimDTADHQ7CdHzquUh8K2AH+88CNhyot9mdyApQv6qLLEwRPnmBQBMsuwZDLOby1Pv8 tsMUmBqImIoEgaV2Ixz5yDlfXsYn4rQbwP5lH0PU6SXRUxWpeItlpEb8UjcDwT8qlzGE V7a6qVZXptPJcrc3WsaDXtK5zTJsk6pwpVKlmcGcmUVwK8l1x1mR7smtYimhoMRV1Ibu 9eAUgk9eSk4wwH4qvJehudR41K3iIjmsNbBtwP1SQME+ITv+BDNQzA5Ew5aYOPpYrtcD FY3g== X-Gm-Message-State: ALoCoQkl5OBD2L5xhRx5bFXSCcksvtSnvMSF3PaW1QhNR/qOMpFVKr7qjnCqot5Y55hzCzkgi4QdnnV7LCjpdzEXj0Vq//vQqthfcMJCIzX/BqzVvwIe8y1K5kzRHz9b1N6XER3sKtcROuiWzmDJ9Q9bwFU8vJ//DA== X-Received: by 10.180.90.236 with SMTP id bz12mr16353843wib.33.1429804094224; Thu, 23 Apr 2015 08:48:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.90.236 with SMTP id bz12mr16353826wib.33.1429804094115; Thu, 23 Apr 2015 08:48:14 -0700 (PDT) Received: by 10.27.177.204 with HTTP; Thu, 23 Apr 2015 08:48:14 -0700 (PDT) Date: Thu, 23 Apr 2015 10:48:14 -0500 Message-ID: From: "James A. (Jim) Stevens" To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d043be09c20f0e20514663580 Archived-At: X-Mailman-Approved-At: Thu, 23 Apr 2015 09:25:23 -0700 Subject: [manet] DLEP versus PPPoE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 15:50:51 -0000 --f46d043be09c20f0e20514663580 Content-Type: text/plain; charset=UTF-8 Stan, I understand your answer, but I presume that Deepak Lal was asking about what is the best/recommended protocol to use for radio to router. (My assumption is why implement PPPoE otherwise.) I would have expected you to say that the ietf manet working group recommends DLEP as the preferred radio to router protocol (or will recommend that once DLEP becomes an RFC). Do you agree? disagree? Jim Date: Thu, 23 Apr 2015 15:19:13 +0000 > From: "Ratliff, Stanley" > To: "Lal, Deepak (MTL)" , "manet@ietf.org" > > Subject: Re: [manet] Require clarification(draft-ietf-manet-dlep-09 vs > RFC 4938/RFC5578) > Message-ID: <7c4221d759654ccca4014812ddcc777b@VAUSDITCHM2.idirect.net> > > Deepak, > > DLEP doesn't supersede RFC5578. RFC5578 is for PPPoE-based connections > between router and radio. DLEP specifies a TCP-based connection, with UDP > used for discovery. And I believe the Credit flows *are* documented in > DLEP, as an extension. > > Regards, > Stan > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lal, Deepak (MTL) > Sent: Thursday, April 23, 2015 10:49 AM > To: manet@ietf.org > Subject: [manet] Require clarification(draft-ietf-manet-dlep-09 vs RFC > 4938/RFC5578) > > I am not clear about the distinction. Does MANET-DLEP-09 supersede the > PPPoE based RFC4938/RFC5578 implementations? > There is no mention of Credit Flows, etc. on MANET-DLEP-09. > > Thank you > > -- James A. (Jim) Stevens, PhD Network Architect / Technical Fellow Rockwell Collins Government Systems james.a.stevens@rockwellcollins.com 972-705-3475 (office) 214-392-2273 (cell) --f46d043be09c20f0e20514663580 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stan,

I understand your answer, but I p= resume that Deepak Lal was asking about what is the best/recommended protoc= ol to use for radio to router. (My assumption is why implement PPPoE otherw= ise.)

I would have expected you to say that the ie= tf manet working group recommends DLEP as the preferred radio to router pro= tocol (or will recommend that once DLEP becomes an RFC).

Do you agree? =C2=A0disagree?

Jim

Date: Thu, 23 Apr 2015 15:19:13 +0000
From: "Ratliff, Stanley" <sratliff@idirect.net>
To: "Lal, Deepak (MTL)" <Deepak.Lal@Ultra-TCS.com>, "<= a href=3D"mailto:manet@ietf.org">manet@ietf.org"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <manet@iet= f.org>
Subject: Re: [manet] Require clarification(draft-ietf-manet-dlep-09 vs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 4938/RFC5578)
Message-ID: <7c4221d759654ccca4014812ddcc777b@VAUSDITCHM2.idirect.net>

Deepak,

DLEP doesn't supersede RFC5578. RFC5578 is for PPPoE-based connections = between router and radio. DLEP specifies a TCP-based connection, with UDP u= sed for discovery. And I believe the Credit flows *are* documented in DLEP,= as an extension.

Regards,
Stan

From: manet [mailto:manet-bounces= @ietf.org] On Behalf Of Lal, Deepak (MTL)
Sent: Thursday, April 23, 2015 10:49 AM
To: manet@ietf.org
Subject: [manet] Require clarification(draft-ietf-manet-dlep-09 vs RFC 4938= /RFC5578)

I am not clear about the distinction. Does MANET-DLEP-09 supersede the PPPo= E based RFC4938/RFC5578 implementations?
There is no mention of Credit Flows, etc. on MANET-DLEP-09.

Thank you

--
<= div dir=3D"ltr">James A. (Jim) Stevens, PhD
Network Architect / Technic= al Fellow
Rockwell Collins Government Systems
972-705-3475 (office)
21= 4-392-2273 (cell)